It may be the case that either the current OE image they use chronyd rather than ntpd. I have a query in to Ettus/NI R&D for guidance.
Sent from my iPhone > On Apr 2, 2021, at 7:26 AM, Ofer Saferman <[email protected]> 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. > > Regards, > Ofer Saferman > >> On Thu, Apr 1, 2021 at 4:34 PM Marcus D. Leech <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[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, 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. >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> > > -- > 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]
