Thanks for the tip Ron! It got me (almost) all the way home. I can now interface with the USRP via the C++ API, which I couldn't do previously.
Unfortunately there's still a niggling problem with the Python API (a different one than before), but I will start a new thread to cover that issue. Cheers, Brendan. On Sun, Apr 4, 2021 at 11:53 AM Ron Economos <w...@comcast.net> wrote: > This is just a guess, but you could try: > > -DCMAKE_SHARED_LINKER_FLAGS="-latomic" > > in addition. > > Ron > On 4/3/21 18:34, Brendan Horsfield wrote: > > 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
