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<mailto: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<mailto:brendan.horsfi...@vectalabs.com>] Sent: Sunday, April 4, 2021 01:35 To: Clark (US), Kenneth C <kenneth.c.cla...@boeing.com<mailto:kenneth.c.cla...@boeing.com>> Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>; patchvonbr...@gmail.com<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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<mailto:usrp-users-requ...@lists.ettus.com> You can reach the person managing the list at usrp-users-ow...@lists.ettus.com<mailto: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<mailto: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<mailto:patchvonbr...@gmail.com>> Cc: USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> Message-ID: <calnmz8wg3gqnkaomrhhcbpagttfubm3fkmzjhcwhuaghrlu...@mail.gmail.com<mailto: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<mailto: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<mailto: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<mailto:usrp-users@lists.ettus.com> To unsubscribe > send an email to usrp-users-le...@lists.ettus.com<mailto: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<mailto:o...@navigicom.com>> Subject: [USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units To: usrp-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Message-ID: <CACDReSwXUvJ8_LimfVOn4StHQEGhNntY-nCSv0aYdBsX=at...@mail.gmail.com<mailto: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<mailto:usrp-users-requ...@lists.ettus.com>> wrote: > Send USRP-users mailing list submissions to > usrp-users@lists.ettus.com<mailto: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<mailto:usrp-users-requ...@lists.ettus.com> > > You can reach the person managing the list at > usrp-users-ow...@lists.ettus.com<mailto: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<mailto:phi...@balister.org>> > To: Ofer Saferman <o...@navigicom.com<mailto:o...@navigicom.com>>, "Marcus D. Leech" < > patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>> > Cc: Rob Kossler <rkoss...@nd.edu<mailto:rkoss...@nd.edu>>, usrp-users > <usrp-users@lists.ettus.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:patchvonbr...@gmail.com>> > >>> wrote: > >>> > >>>> > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Mar 31, 2021, at 2:22 PM, Rob Kossler <rkoss...@nd.edu<mailto: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<mailto: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<mailto: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<mailto:patchvonbr...@gmail.com>> > >>>>>>> To: usrp-users@lists.ettus.com<mailto: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<mailto:usrp-users@lists.ettus.com> To > >>>>>> unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> > >>>>>> > >>>>> _______________________________________________ > >>>> USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To > >>>> unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto: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<mailto:usrp-users@lists.ettus.com> To unsubscribe > > send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe > send an email to usrp-users-le...@lists.ettus.com<mailto: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<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto: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
