Point taken. To be honest I wasn't really expecting to be able to capture large volumes of data with my Raspberry Pi (or high-end laptop for that matter) using Python. I was just curious about other users' claimed results, and wanted to know if there was something I was missing.
For small data captures (a few hundred microseconds max), the Python API seems pretty solid, even at high sampling rates. I've still got some questions on that subject, but I will save these for a new discussion thread. Brendan. On Tue, Apr 13, 2021 at 1:35 AM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > On 04/11/2021 09:16 PM, Brendan Horsfield wrote: > > Ken, > > Are you using a USRP B210, or something different? If I try to record one > second's worth of samples on my Raspberry Pi / B210 combo, I can barely > achieve 8 Msps on one channel. Changing the over-the-wire parameter from > sc16 to sc8 allows me to achieve 15 Msps, but that's about it. > > I can think of a few possible explanations: > > - I am using the Python API, while you are using the C++ API > (shouldn't make a big difference according to the Ettus Knowledge Base, but > still...) > > Even when you're using a lot of underlying libraries written in C++ from > Python, you still have to pay the Python-is-an-interpreter and > data-marshalling costs of Python. If all you're doing is wanting to > record a bit of data, you might consider one of the > "canned" example applications like "rx_samples_to_file". > > If you want to proceed with a more full-blown Python app development, you > cannot get around the fact that is doesn't do well for > sustained processing of high-speed sample streams. Granted, science and > engineering have long-used Python for fairly-intense > data-analysis tasks, but NOT IN REAL TIME at HIGH SAMPLE RATES. > > I completely understand the allure of using Python--I moved 99% of my dev > "life" to Python from C many years ago and I haven't looked > back. But for some tasks, it's not the answer. > > > - You are using different transport parameters to me > (e.g. recv_frame_size, num_recv_frames) > - Your Linux buffer size settings are different to mine > > Note that if I reduce my recording time to 1 - 2 milliseconds (approx > 80,000 samples), I can achieve 50 Msps with almost zero dropped samples. > This is more than enough for my application, but it would still be nice to > know why I am not seeing the same performance as other users! :) > > Cheers, > Brendan. > > > On Mon, Apr 12, 2021 at 10:17 AM Clark (US), Kenneth C < > kenneth.c.cla...@boeing.com> wrote: > >> Brendan, >> >> >> >> Most of my work has been done at 15 Msamp/sec, my observation at higher >> rates was not based on a lot of testing. I was just happy it worked at all >> above 20 Msamp/sec (aka it was really using USB-3). >> >> >> >> Running some quick tests here, for one second long recordings, 40 >> Msamp/sec always drops something. 35 Msamp/sec mostly drops something. 30 >> Msamp/sec mostly works, but does drop something a noticeable number of >> times. >> >> >> >> Playing with the recording duration, things are better with shorter >> durations. Which I guess if each samples has a 0.00001% of getting >> dropped, then the longer the recording, the greater the chance for >> something getting dropped. And I suppose there is some operating system >> file flush threshold that also kicks in? >> >> >> >> I was probably a little optimistic in my performance report. Again, I >> was just happy it worked at all at USB-3 rates. >> >> >> >> I think there is also an option to record as 12-bit values, which as you >> approach the rates of the A-to-D (which I think is in the 12-bit range?) >> you are not really giving up anything, as there is not much DDC ‘averaging’ >> to give you more bits of resolution. I have not looked at that (12 bit >> wire values), and I might be making that up. I do see a “sc8” wirefmt >> option for the rx_samples_to_file, which runs at higher rates without >> overflow. >> >> >> >> Ken >> >> >> >> *From:* Brendan Horsfield [mailto:brendan.horsfi...@vectalabs.com] >> *Sent:* Sunday, April 11, 2021 23:16 >> *To:* Clark (US), Kenneth C <kenneth.c.cla...@boeing.com> >> *Cc:* usrp-users@lists.ettus.com >> *Subject:* [EXTERNAL] Re: Problem with interfacing Raspberry Pi 4 to >> USRP B210 with Python API >> >> >> >> EXT email: be mindful of links/attachments. >> >> >> >> >> Hi Ken, >> >> >> >> When you say "I am able to reliably record above 20 Msps with the ‘wire >> format’ at 16-bit complex I&Q", do you mean that you can do this >> indefinitely (or at least, up to the size of your RAM disk)? Or is there a >> limit to how much data you can capture before you get an overrun? >> >> >> >> I find I can reliably capture around 1MB of data at 50 Msps on one >> channel, or 25 Msps on two channels. However, if I try to capture more >> than 1MB of data in one go, I get a stream of error messages. >> >> >> >> Brendan. >> >> >> >> >> >> On Tue, Apr 6, 2021 at 12:40 AM Clark (US), Kenneth C < >> kenneth.c.cla...@boeing.com> wrote: >> >> Brendan, >> >> >> >> I am just using the ‘examples’ C/C++ builds. I have not used the python >> modules. >> >> >> >> I would think editing the CMake file would remove the need for the –D >> flag. >> >> >> >> I have had very good luck running a B205 USB-3 on a RPi-4-8GB. Only a >> couple of dependencies to install, which were documented on the Ettus UHD >> website. >> >> >> >> I did create a RAM-Drive, since the 8 GByte RAM has room for that. And I >> am able to reliably record above 20 Msps with the ‘wire format’ at 16-bit >> complex I&Q. (No real reason to do 32-float, since the native samples are >> 16-bit I&Q in the FPGA on the B205, right?) >> >> >> >> I use the ‘host examples’ in the latest 4.x version of UHD. And they are >> pretty easy to modify. I have adapted for things like using the 1-PPS, and >> doing times receive and transmit. >> >> >> >> Ken >> >> >> >> *From:* Brendan Horsfield [mailto:brendan.horsfi...@vectalabs.com] >> *Sent:* Sunday, April 4, 2021 01:35 >> *To:* Clark (US), Kenneth C <kenneth.c.cla...@boeing.com> >> *Cc:* usrp-users@lists.ettus.com; patchvonbr...@gmail.com >> *Subject:* [EXTERNAL] Re: [USRP-users] Re: Problem with interfacing >> Raspberry Pi 4 to USRP B210 with Python API >> >> >> >> EXT email: be mindful of links/attachments. >> >> >> >> >> Thanks Ken. As you suggested, I added >> -DCMAKE_EXE_LINKER_FLAGS="-latomic" to the CMake call. >> >> >> >> The good news is that the UHD build & installation process completed >> successfully. >> >> >> >> The bad news is that when I try to import the uhd module in Python3, I >> get the following error: >> >> >> >> pi@raspberrypi:~ $ python3 >> Python 3.7.3 (default, Jan 22 2021, 20:04:44) >> [GCC 8.3.0] on linux >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import uhd >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File "/usr/local/lib/python3/dist-packages/uhd/__init__.py", line 10, >> in <module> >> from . import types >> File "/usr/local/lib/python3/dist-packages/uhd/types.py", line 10, in >> <module> >> from . import libpyuhd as lib >> ImportError: /usr/local/lib/libuhd.so.4.0.0: undefined symbol: >> __atomic_fetch_add_8 >> >>> >> >> >> >> Did you encounter this problem too? >> >> >> >> I guess the next step is to hack the "CMakeLists.txt" files as per the >> link you sent me. Just to clarify one point first: If I modify the >> CMakeLists.txt files, do I still need to include >> -DCMAKE_EXE_LINKER_FLAGS="-latomic" in the CMake call? >> >> >> >> Thanks, >> >> Brendan. >> >> >> >> >> >> >> >> On Sat, Apr 3, 2021 at 10:29 PM Clark (US), Kenneth C < >> kenneth.c.cla...@boeing.com> wrote: >> >> >> I had the same problem build UHD on RPi4 >> >> Answer here: >> https://gitlab.kitware.com/cmake/cmake/-/issues/21174 >> >> Add to CMake call: >> -DCMAKE_EXE_LINKER_FLAGS="-latomic" >> >> Regards, >> >> Ken >> >> >> -----Original Message----- >> From: usrp-users-requ...@lists.ettus.com [mailto: >> usrp-users-requ...@lists.ettus.com] >> Sent: Saturday, April 3, 2021 11:13 >> To: usrp-users@lists.ettus.com >> Subject: [EXTERNAL] USRP-users Digest, Vol 128, Issue 7 >> >> EXT email: be mindful of links/attachments. >> >> >> >> Send USRP-users mailing list submissions to >> usrp-users@lists.ettus.com >> >> To subscribe or unsubscribe via email, send a message with subject or >> body 'help' to >> usrp-users-requ...@lists.ettus.com >> >> You can reach the person managing the list at >> usrp-users-ow...@lists.ettus.com >> >> When replying, please edit your Subject line so it is more specific than >> "Re: Contents of USRP-users digest..." >> >> Today's Topics: >> >> 1. Re: Problem with interfacing Raspberry Pi 4 to USRP B210 with >> Python API >> (Brendan Horsfield) >> 2. Re: Intermittent problem with GPS synchronization for multiple E310 >> units >> (Ofer Saferman) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 3 Apr 2021 21:07:59 +1000 >> From: Brendan Horsfield <brendan.horsfi...@vectalabs.com> >> Subject: [USRP-users] Re: Problem with interfacing Raspberry Pi 4 to >> USRP B210 with Python API >> To: Marcus D Leech <patchvonbr...@gmail.com> >> Cc: USRP-users@lists.ettus.com >> Message-ID: >> < >> calnmz8wg3gqnkaomrhhcbpagttfubm3fkmzjhcwhuaghrlu...@mail.gmail.com> >> Content-Type: multipart/alternative; >> boundary="000000000000dc3aeb05bf0f7ace" >> >> Hi Marcus, >> >> I have tried your suggestion, but unfortunately without success: >> >> Per your advice, I have edited the file "cmake.lwt" in the folder >> /usr/local/lib/python3.7/dist-packages/pybombs/templates to include the >> option "-DENABLE_PYTHON_API=ON" in the calls to cmake. The modified >> commands are as follows: >> >> configure: cmake .. -DENABLE_PYTHON_API=ON >> -DCMAKE_BUILD_TYPE=$cmakebuildtype -DCMAKE_INSTALL_PREFIX=$prefix >> $config_opt -Wno-dev >> configure_static: cmake .. -DENABLE_PYTHON_API=ON >> -DCMAKE_BUILD_TYPE=$cmakebuildtype -DCMAKE_INSTALL_PREFIX=$prefix >> -DENABLE_STATIC_LIBS=True $config_opt >> >> I removed the previous UHD installation and re-ran "pybombs install uhd", >> but the end result was much the same: the installation process completed >> without errors, but the Python API was not included in the installation. >> >> QUESTION 1: Can you tell me if PyBOMBS actually builds the UHD driver >> from source, or does it simply copy a pre-compiled binary onto my system? >> The reason I ask is that PyBOMBS is quite quick to install the UHD driver, >> whereas the non-PyBOMBS approach is VERY slow (i.e. around 60 minutes to >> get to 53%, at which point it crashes out with an error). >> >> QUESTION 2: This whole process feels more difficult than it should be. >> Why isn't the Python API installed with the UHD driver by default? Would >> I be better off using another language (like C++) to control the USRP? >> >> Thanks, >> Brendan. >> >> >> >> On Fri, Apr 2, 2021 at 11:25 PM Marcus D Leech <patchvonbr...@gmail.com> >> wrote: >> >> > Perhaps look at the PyBombs recipe for your platform—there’s probably >> > a compiler flag that needs to be set that you’re missing, but I don’t >> > know what that is. >> > >> > Also, in general, you don’t need to become root to compile and build >> > code—only needed during the “make install” >> > >> > >> > >> > Sent from my iPhone >> > >> > On Apr 2, 2021, at 7:19 AM, Brendan Horsfield < >> > brendan.horsfi...@vectalabs.com> wrote: >> > >> > >> > Hi Folks, >> > >> > I would like to interface my Raspberry Pi 4 to a USRP B210 via the >> > Python API. This requires the UHD driver to be built from source. >> > Unfortunately, whenever I try this I encounter some errors that stop >> > the build process in its tracks. >> > >> > Details of the error are as follows: >> > >> > [ 53%] Linking CXX executable test_clock_synch >> > /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to >> > `__atomic_compare_exchange_8' >> > /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to >> > `__atomic_load_8' >> > /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to >> > `__atomic_store_8' >> > /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to >> > `__atomic_fetch_add_8' >> > collect2: error: ld returned 1 exit status >> > make[2]: *** [examples/CMakeFiles/test_clock_synch.dir/build.make:95: >> > examples/test_clock_synch] Error 1 >> > make[1]: *** [CMakeFiles/Makefile2:1039: >> > examples/CMakeFiles/test_clock_synch.dir/all] Error 2 >> > make: *** [Makefile:163: all] Error 2 >> > >> > The process I have been using is as follows: >> > >> > STEP 1: INSTALL DEPENDENCIES >> > sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen >> > python3-docutils python3-mako python3-numpy python3-requests >> > python3-ruamel.yaml python3-setuptools cmake build-essential >> > >> > STEP 2: BUILD UHD DRIVER FROM SOURCE >> > cd /home/pi >> > mkdir workarea-uhd >> > cd workarea-uhd >> > git clone https://github.com/EttusResearch/uhd >> > cd uhd >> > git checkout v4.0.0.0 >> > cd host >> > mkdir build >> > cd build >> > sudo cmake -DNEON_SIMD_ENABLE=OFF -DENABLE_PYTHON_API=ON ../ sudo make >> > ---> (ERRORS OCCUR DURING "MAKE" PROCESS) >> > >> > My system configuration is as follows: >> > Hardware: Raspberry Pi 4 Model B Rev 1.4 >> > OS: Raspbian GNU/Linux 10 (buster) (32-bit, armv7l) Ettus USRP B210 >> > >> > Does anyone know what the problem could be, and how I can resolve it? >> > >> > One final note: Using PyBOMBS, I was able to successfully build & >> > install the UHD driver and connect to the USRP. Unfortunately the >> > PyBOMBS build does not include the Python API, which is what I really >> > want. Is there a different version of the PyBOMBS build that includes >> the Python API? >> > >> > Thanks & Regards, >> > Brendan. >> > >> > >> > >> > _______________________________________________ >> > USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe >> > send an email to usrp-users-le...@lists.ettus.com >> > >> > >> -------------- next part -------------- >> A message part incompatible with plain text digests has been removed ... >> Name: not available >> Type: text/html >> Size: 5624 bytes >> Desc: not available >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 3 Apr 2021 14:12:35 +0300 >> From: Ofer Saferman <o...@navigicom.com> >> Subject: [USRP-users] Re: Intermittent problem with GPS >> synchronization for multiple E310 units >> To: usrp-users <usrp-users@lists.ettus.com> >> Message-ID: >> <CACDReSwXUvJ8_LimfVOn4StHQEGhNntY-nCSv0aYdBsX= >> at...@mail.gmail.com> >> Content-Type: multipart/alternative; >> boundary="000000000000566d1705bf0f8b0e" >> >> Hello Philip, >> >> Thank you for the explanation. >> What would you suggest? >> opkg exists. There must be a way to install ntpd without needing to >> rebuild the image. >> Maybe use pybombs or other methods? >> git also works. Maybe download a different package manager and compile it? >> >> It seems that Marcus pointed out a great benefit of E310 units running >> gpsd, but without ntpd system clock can't sync and it seems that this >> feature can vastly simplify gps synchronization among E310 units. >> >> I would be very grateful if anybody can suggest a solution to install >> ntpd on E310 units running UHD 3.15 SD-card image. >> >> Regards, >> Ofer Saferman. >> >> On Sat, Apr 3, 2021 at 10:30 AM <usrp-users-requ...@lists.ettus.com> >> wrote: >> >> > Send USRP-users mailing list submissions to >> > usrp-users@lists.ettus.com >> > >> > To subscribe or unsubscribe via email, send a message with subject or >> > body 'help' to >> > usrp-users-requ...@lists.ettus.com >> > >> > You can reach the person managing the list at >> > usrp-users-ow...@lists.ettus.com >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of USRP-users digest..."Today's Topics: >> > >> > 1. Re: Intermittent problem with GPS synchronization for multiple >> > E310 units >> > (Philip Balister) >> > >> > >> > >> > ---------- Forwarded message ---------- >> > From: Philip Balister <phi...@balister.org> >> > To: Ofer Saferman <o...@navigicom.com>, "Marcus D. Leech" < >> > patchvonbr...@gmail.com> >> > Cc: Rob Kossler <rkoss...@nd.edu>, usrp-users >> > <usrp-users@lists.ettus.com> >> > Bcc: >> > Date: Fri, 2 Apr 2021 10:09:43 -0400 >> > Subject: [USRP-users] Re: Intermittent problem with GPS >> > synchronization for multiple E310 units On 4/2/21 7:17 AM, Ofer >> > Saferman wrote: >> > > Marcus Hi, >> > > >> > > Your suggestion below to install ntpd does not work. >> > > The image does not include it. Although the old thread says >> > > otherwise I think it refers to an older UHD release that did include >> ntpd. >> > > Any accurate instructions on how to install it anyway? >> > > Maybe opkg should be configured to access another repository? >> > > Doing: opkg list | grep ntpd, does not yield anything useful so it >> > > is not just a question of typing it correctly. >> > >> > As far as I know, no image has been setup to use package feeds. >> > >> > I know ntpd worked in release4 images, pretty sure the newer image was >> > redone and things have been left out that used to be there. >> > >> > Philip >> > >> > > >> > > Regards, >> > > Ofer Saferman >> > > >> > > On Thu, Apr 1, 2021 at 4:34 PM Marcus D. Leech >> > > <patchvonbr...@gmail.com> >> > > wrote: >> > > >> > >> On 04/01/2021 06:00 AM, Ofer Saferman wrote: >> > >> >> > >> Hello Marcus, >> > >> >> > >> I am working on E310 with the latest UHD-3.15 SD card image. >> > >> It seems not to include ntpd that is required to synchronize system >> > >> time to GPS time. >> > >> Any idea how to install it on the E310? >> > >> >> > >> Regards, >> > >> Ofer Saferman >> > >> >> > >> sudo opkg install ntpd >> > >> >> > >> should work, but it has been a while since I installed any packages >> > >> on >> > my >> > >> E310. >> > >> >> > >> The E310 is based on OpenEmbedded Linux, so all the info about >> > installing >> > >> and managing packages on OpenEmbedded apply. >> > >> >> > >> >> > >> >> > >> On Wed, Mar 31, 2021 at 11:40 PM Marcus D Leech < >> > patchvonbr...@gmail.com> >> > >> wrote: >> > >> >> > >>> Just use gettimeofday() or any of the myriad subtle variants >> > >>> available >> > in >> > >>> boost to get you the Linux system time, and use that in a call to >> > >>> set_time_next_pps(). >> > >>> >> > >>> The fact that all your E310s will be running GPSD means they’ll be >> > >>> adjusting system time appropriately and they’ll all agree on what >> > >>> time >> > it >> > >>> is, depending on the level of precision you need. >> > >>> >> > >>> Sent from my iPhone >> > >>> >> > >>> On Mar 31, 2021, at 3:50 PM, Ofer Saferman <o...@navigicom.com> >> wrote: >> > >>> >> > >>> >> > >>> Thank you Rob. Your suggestions are always helpful. I will look >> > >>> into using gps_gpgga. >> > >>> Thank you Marcus. I am already adding one, per other examples >> > >>> posted >> > here >> > >>> and sync_to_gps example. Can you please comment how I can benefit >> > >>> from >> > the >> > >>> fact that E310 units use gpsd in Linux? >> > >>> >> > >>> Regards, >> > >>> Ofer Saferman >> > >>> >> > >>> On Wed, Mar 31, 2021 at 10:13 PM Marcus D Leech < >> > patchvonbr...@gmail.com> >> > >>> wrote: >> > >>> >> > >>>> >> > >>>> >> > >>>> Sent from my iPhone >> > >>>> >> > >>>> On Mar 31, 2021, at 2:22 PM, Rob Kossler <rkoss...@nd.edu> wrote: >> > >>>> >> > >>>> >> > >>>> Hi Ofer, >> > >>>> Take a look at the Ettus source code gps_ctrl.cpp. In >> > >>>> particular, >> > look >> > >>>> at the get_sentence() usage which in the case of "gps_time" waits >> > >>>> for >> > the >> > >>>> next occurrence (wait=true), but for the others does not wait. >> > >>>> But >> > this >> > >>>> doesn't fully explain the behavior you are seeing. If you do the >> > following: >> > >>>> 1) wait for PPS time to change >> > >>>> 2) read the "gps_time" sensor >> > >>>> 3) set_time_next_pps (use the value you just read) >> > >>>> >> > >>>> Add 1 to the time you just read before calling set_time_next_pps. >> > >>>> >> > >>>> >> > >>>> It should still work because the "gps_time" command should just >> > >>>> wait until the next PPS. I guess it depends upon how >> > >>>> "synchronized" are >> > the >> > >>>> received NMEA string with the PPS edge. Step 1 above waits for >> > >>>> the >> > PPS >> > >>>> edge, but maybe the NMEA string arrives 0.1 secs before or after >> > that. I >> > >>>> don't really know. Perhaps you need to switch to using "gps_gpgga" >> > such >> > >>>> that there is no additional wait added and also perhaps you >> > >>>> should >> > add step >> > >>>> 1B which would be just a fixed delay of perhaps 0.4 secs so that >> > >>>> you >> > will >> > >>>> read the NMEA string in between the PPS edges. >> > >>>> Rob >> > >>>> >> > >>>> On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler <rkoss...@nd.edu> >> wrote: >> > >>>> >> > >>>>> Hi Ofer, >> > >>>>> I don't know why the "gps_time" sensor takes long to read. But, >> > >>>>> can >> > you >> > >>>>> try the other sensors (perhaps there is a "gps_gpgga" sensor?)? >> > >>>>> The >> > time >> > >>>>> is embedded in these as well. >> > >>>>> Rob >> > >>>>> >> > >>>>> >> > >>>>> On Wed, Mar 31, 2021 at 12:21 PM Ofer Saferman >> > >>>>> <o...@navigicom.com> >> > >>>>> wrote: >> > >>>>> >> > >>>>>> Marcus Hi, >> > >>>>>> >> > >>>>>> If the gps_time "sensor" returns a value only once per second >> > >>>>>> how >> > come >> > >>>>>> I manage to read it sometimes in less than 1 second? >> > >>>>>> In my code the situation is worse than the simple example >> > >>>>>> below. It usually takes more than 1 sec. to read it and >> > >>>>>> sometimes even 1.7 or >> > 1.8 >> > >>>>>> seconds. I don't understand how the size or complexity of the >> > >>>>>> code >> > affects >> > >>>>>> the time it takes to read gps_time. >> > >>>>>> >> > >>>>>> How to treat your comment about the use of GPSD and good >> > >>>>>> synchronization as it relates to code? >> > >>>>>> Should I not change the time source in code and go through the >> > >>>>>> whole process of synchronization using gps_time? >> > >>>>>> Can I "assume" the systems are synced just by the effect they >> > >>>>>> were connected enough time to a GPS antenna? and then just >> > >>>>>> access their >> > time - >> > >>>>>> radio_ctrl->get_time_last_pps()? >> > >>>>>> How to use this information programmatically? >> > >>>>>> >> > >>>>>> Regards, >> > >>>>>> Ofer Saferman >> > >>>>>> >> > >>>>>> >> > >>>>>> ---------- Forwarded message ---------- >> > >>>>>>> From: "Marcus D. Leech" <patchvonbr...@gmail.com> >> > >>>>>>> To: usrp-users@lists.ettus.com >> > >>>>>>> Cc: >> > >>>>>>> Bcc: >> > >>>>>>> Date: Wed, 31 Mar 2021 09:19:20 -0400 >> > >>>>>>> Subject: [USRP-users] Re: Intermittent problem with GPS >> > >>>>>>> synchronization for multiple E310 units On 03/31/2021 06:49 >> > >>>>>>> AM, Ofer Saferman wrote: >> > >>>>>>>> Hello, >> > >>>>>>>> >> > >>>>>>>> I have a system that uses 4 USRP E310 units. >> > >>>>>>>> Each unit is connected to a GPS antenna. >> > >>>>>>>> Time source is set to gpsdo. >> > >>>>>>>> >> > >>>>>>>> I run the same software remotely on all 4 units from a PC. >> > Software >> > >>>>>>>> runs on the units themselves. >> > >>>>>>>> I print out messages to show if the reference is locked and >> > >>>>>>>> the >> > GPS >> > >>>>>>> is >> > >>>>>>>> locked and also what is the GPS time that each unit was >> > >>>>>>> synchronized to. >> > >>>>>>>> In some cases the units synchronize to the same GPS time and >> > >>>>>>>> in >> > >>>>>>> other >> > >>>>>>>> cases there is 1 second difference between GPS time of >> > >>>>>>>> different >> > >>>>>>> units >> > >>>>>>>> thus causing the units to be unsynchronized. >> > >>>>>>>> >> > >>>>>>>> I was wondering how this was possible. >> > >>>>>>>> The synchronization process (documented by others in the past >> > >>>>>>>> on >> > >>>>>>> the >> > >>>>>>>> mailing list) is: >> > >>>>>>>> * Wait for ref and GPS lock >> > >>>>>>>> * Wait for a pps edge (get_time_last_pps) >> > >>>>>>>> * Read gps_time value >> > >>>>>>>> * Sync system clock to GPS clock on next PPS edge >> > >>>>>>> (set_time_next_pps + >> > >>>>>>>> 1.0 sec) >> > >>>>>>>> >> > >>>>>>>> Something similar is also implemented in the sync_to_gps >> example. >> > >>>>>>>> >> > >>>>>>>> In order to debug the problem I decided to time the reading >> > >>>>>>>> of the gps_time sensor to see if there is a clue why >> > >>>>>>>> different units miss >> > >>>>>>> the >> > >>>>>>>> PPS edge and lock to a time of the next second. >> > >>>>>>>> >> > >>>>>>>> I was very surprised to find out that it takes between 0.9 to >> > >>>>>>>> 1.2 seconds to read the gps_time sensor. >> > >>>>>>>> This explains exactly why it is difficult to synchronize >> > >>>>>>>> multiple units to the same time instance because if one unit >> > >>>>>>>> takes 0.9 >> > >>>>>>> seconds >> > >>>>>>>> to read the sensor and the other unit takes 1.2 seconds to >> > >>>>>>>> read >> > the >> > >>>>>>>> sensor then each unit will lock on a different GPS time 1 >> > >>>>>>>> second >> > >>>>>>> apart. >> > >>>>>>>> >> > >>>>>>>> Here is a short software I wrote to time the gps_time sensor >> > >>>>>>> reading: >> > >>>>>>>> --------------------------------------------------------- >> > >>>>>>>> #include <uhd/utils/safe_main.hpp> #include <uhd/device3.hpp> >> > >>>>>>>> //#include <uhd/usrp/multi_usrp.hpp> #include >> > >>>>>>>> <uhd/types/sensors.hpp> #include <boost/program_options.hpp> >> > >>>>>>>> #include <boost/format.hpp> #include <chrono> #include >> > >>>>>>>> <iostream> >> > >>>>>>>> >> > >>>>>>>> namespace po = boost::program_options; >> > >>>>>>>> >> > >>>>>>>> int UHD_SAFE_MAIN(int argc, char *argv[]){ >> > >>>>>>>> >> > >>>>>>>> std::string args; >> > >>>>>>>> >> > >>>>>>>> po::options_description desc("Allowed options"); >> > >>>>>>>> desc.add_options() >> > >>>>>>>> ("help", "help message") ("args", >> > >>>>>>>> po::value<std::string>(&args)->default_value(""), "device >> > >>>>>>>> address args") >> > >>>>>>>> ; >> > >>>>>>>> >> > >>>>>>>> po::variables_map vm; >> > >>>>>>>> po::store(po::parse_command_line(argc, argv, desc), vm); >> > >>>>>>>> po::notify(vm); >> > >>>>>>>> >> > >>>>>>>> //print the help message >> > >>>>>>>> if (vm.count("help")){ >> > >>>>>>>> std::cout << boost::format("Timinig of gps_time: %s") >> > >>>>>>>> % >> > >>>>>>> desc >> > >>>>>>>> << std::endl; >> > >>>>>>>> return ~0; >> > >>>>>>>> } >> > >>>>>>>> >> > >>>>>>>> uhd::device3::sptr usrp = uhd::device3::make(args); >> > >>>>>>>> //uhd::usrp::multi_usrp::sptr usrp = >> > >>>>>>> uhd::usrp::multi_usrp::make(args); >> > >>>>>>>> >> > >>>>>>>> uhd::sensor_value_t gps_time = >> > >>>>>>>> >> > >>>>>>> >> > usrp->get_tree()->access<uhd::sensor_value_t>("/mboards/0/sensors/gps_ >> > usrp->time").get(); >> > >>>>>>>> //uhd::sensor_value_t gps_time = >> > >>>>>>> usrp->get_mboard_sensor("gps_time", 0); >> > >>>>>>>> >> > >>>>>>>> std::chrono::steady_clock::time_point start_time, end_time; >> > >>>>>>>> std::chrono::duration<double> time_diff; // Default unit for >> > >>>>>>> duration >> > >>>>>>>> is seconds. >> > >>>>>>>> >> > >>>>>>>> for(int ii=0 ; ii<20 ; ii++) >> > >>>>>>>> { >> > >>>>>>>> start_time = std::chrono::steady_clock::now(); gps_time = >> > >>>>>>>> >> > >>>>>>> >> > usrp->get_tree()->access<uhd::sensor_value_t>("/mboards/0/sensors/gps_ >> > usrp->time").get(); >> > >>>>>>>> //gps_time = usrp->get_mboard_sensor("gps_time", 0); end_time >> > >>>>>>>> = std::chrono::steady_clock::now(); time_diff = end_time - >> > >>>>>>>> start_time; >> > >>>>>>>> >> > >>>>>>>> std::cout << "gps_time[" << (boost::format("%02d") % ii) << >> "]: " >> > >>>>>>> << >> > >>>>>>>> int64_t(gps_time.to_int()) << ". Time to read \"gps_time\": " >> > >>>>>>>> << >> > >>>>>>>> (boost::format("%0.9f") % time_diff.count()) << " seconds" << >> > >>>>>>> std::endl; >> > >>>>>>>> } >> > >>>>>>>> >> > >>>>>>>> return 0; >> > >>>>>>>> } >> > >>>>>>>> >> > >>>>>>> >> > ---------------------------------------------------------------------- >> > ---------- >> > >>>>>>>> Here are the results of one typical run: >> > >>>>>>>> gps_time[00]: 1617183840. Time to read "gps_time": >> > >>>>>>>> 0.884164380 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[01]: 1617183841. Time to read "gps_time": >> > >>>>>>>> 0.877966469 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[02]: 1617183842. Time to read "gps_time": >> > >>>>>>>> 1.170869661 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[03]: 1617183843. Time to read "gps_time": >> > >>>>>>>> 0.882917987 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[04]: 1617183844. Time to read "gps_time": >> > >>>>>>>> 1.172120154 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[05]: 1617183845. Time to read "gps_time": >> > >>>>>>>> 0.879271985 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[06]: 1617183846. Time to read "gps_time": >> > >>>>>>>> 0.878609099 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[07]: 1617183847. Time to read "gps_time": >> > >>>>>>>> 1.115639282 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[08]: 1617183848. Time to read "gps_time": >> > >>>>>>>> 1.125365551 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[09]: 1617183849. Time to read "gps_time": >> > >>>>>>>> 0.843803231 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[10]: 1617183850. Time to read "gps_time": >> > >>>>>>>> 1.125065740 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[11]: 1617183851. Time to read "gps_time": >> > >>>>>>>> 0.847519817 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[12]: 1617183852. Time to read "gps_time": >> > >>>>>>>> 1.121398945 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[13]: 1617183853. Time to read "gps_time": >> > >>>>>>>> 0.844371533 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[14]: 1617183854. Time to read "gps_time": >> > >>>>>>>> 1.124722726 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[15]: 1617183855. Time to read "gps_time": >> > >>>>>>>> 0.845688380 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[16]: 1617183856. Time to read "gps_time": >> > >>>>>>>> 1.129568096 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[17]: 1617183857. Time to read "gps_time": >> > >>>>>>>> 0.882436229 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[18]: 1617183858. Time to read "gps_time": >> > >>>>>>>> 1.168227593 >> > >>>>>>> seconds >> > >>>>>>>> gps_time[19]: 1617183859. Time to read "gps_time": >> > >>>>>>>> 0.881948247 >> > >>>>>>> seconds >> > >>>>>>>> >> > >>>>>>> >> > ---------------------------------------------------------------------- >> > ------------- >> > >>>>>>>> In the code you can find commented out the usual way to >> > >>>>>>>> access the sensor using multi_usrp and get_mboard_sensor. The >> > >>>>>>>> results are >> > >>>>>>> quite >> > >>>>>>>> similar. >> > >>>>>>>> >> > >>>>>>>> I wonder if anybody encountered this issue before or >> > >>>>>>>> addressed it >> > >>>>>>> in >> > >>>>>>>> any way. >> > >>>>>>>> I wonder why it takes so much time to get the value of GPS >> > >>>>>>>> time >> > >>>>>>> when >> > >>>>>>>> it is a simple parsing of an NMEA message coming from the GPS >> > >>>>>>> receiver. >> > >>>>>>>> >> > >>>>>>>> I am trying now various tricks to make the software robust >> > >>>>>>>> and >> > >>>>>>> immune >> > >>>>>>>> to this phenomenon. I can report my findings further if I >> > >>>>>>>> succeed >> > >>>>>>> to >> > >>>>>>>> find a workaround if there is any interest. >> > >>>>>>>> >> > >>>>>>>> Can anyone comment on this? Can this be resolved so that the >> > >>>>>>> reading >> > >>>>>>>> of gps_time will be much faster? >> > >>>>>>>> Is there another way to get GPS time faster indirectly? Maybe >> > >>>>>>>> from parsing NMEA messages ourselves? >> > >>>>>>>> >> > >>>>>>>> Regards, >> > >>>>>>>> Ofer Saferman >> > >>>>>>>> >> > >>>>>>> This probably has to do with the way that particular "sensor" >> > >>>>>>> works--the >> > >>>>>>> NMEA time value is only emitted once per second, and the >> > >>>>>>> code for that sensor has some heuristic for determining >> > >>>>>>> "freshness" >> > >>>>>>> of the value. >> > >>>>>>> >> > >>>>>>> I'll point out that on E310, the system is configured to use >> > >>>>>>> GPSD, >> > so >> > >>>>>>> that the Linux system time across several systems that have >> > >>>>>>> all >> > been >> > >>>>>>> "listening" to GPS for a while will all be synchronized >> > >>>>>>> quite >> > well. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>> -- >> > >>>>>> This message has been scanned for viruses and dangerous content >> > >>>>>> by *MailScanner* <http://www.mailscanner.info/>, and is >> > >>>>>> believed to be clean. >> > _______________________________________________ >> > >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com To >> > >>>>>> unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > >>>>>> >> > >>>>> _______________________________________________ >> > >>>> USRP-users mailing list -- usrp-users@lists.ettus.com To >> > >>>> unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > >>>> >> > >>>> >> > >>> -- >> > >>> This message has been scanned for viruses and dangerous content by >> > >>> *MailScanner* <http://www.mailscanner.info/>, and is believed to >> > >>> be clean. >> > >>> >> > >>> >> > >> -- >> > >> This message has been scanned for viruses and dangerous content by >> > >> *MailScanner* <http://www.mailscanner.info/>, and >> > is >> > >> believed to be clean. >> > >> >> > >> >> > >> >> > > >> > > >> > > _______________________________________________ >> > > USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe >> > > send an email to usrp-users-le...@lists.ettus.com >> > > _______________________________________________ >> > USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe >> > send an email to usrp-users-le...@lists.ettus.com >> > >> >> -- >> This message has been scanned for viruses and dangerous content by >> MailScanner, and is believed to be clean. >> >> -------------- next part -------------- >> A message part incompatible with plain text digests has been removed ... >> Name: not available >> Type: text/html >> Size: 27834 bytes >> Desc: not available >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe >> send an email to usrp-users-le...@lists.ettus.com >> >> >> ------------------------------ >> >> End of USRP-users Digest, Vol 128, Issue 7 >> ****************************************** >> >> > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
