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...) - 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
