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
