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
