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_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_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
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
