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) 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]
