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 <[email protected]> wrote: > > > Sent from my iPhone > > On Mar 31, 2021, at 2:22 PM, Rob Kossler <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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" <[email protected]> >>>> To: [email protected] >>>> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
