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]
