Hello Philip, Thank you for the explanation. What would you suggest? opkg exists. There must be a way to install ntpd without needing to rebuild the image. Maybe use pybombs or other methods? git also works. Maybe download a different package manager and compile it?
It seems that Marcus pointed out a great benefit of E310 units running gpsd, but without ntpd system clock can't sync and it seems that this feature can vastly simplify gps synchronization among E310 units. I would be very grateful if anybody can suggest a solution to install ntpd on E310 units running UHD 3.15 SD-card image. Regards, Ofer Saferman. On Sat, Apr 3, 2021 at 10:30 AM <[email protected]> wrote: > Send USRP-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of USRP-users digest..."Today's Topics: > > 1. Re: Intermittent problem with GPS synchronization for multiple E310 > units > (Philip Balister) > > > > ---------- Forwarded message ---------- > From: Philip Balister <[email protected]> > To: Ofer Saferman <[email protected]>, "Marcus D. Leech" < > [email protected]> > Cc: Rob Kossler <[email protected]>, usrp-users <[email protected]> > Bcc: > Date: Fri, 2 Apr 2021 10:09:43 -0400 > Subject: [USRP-users] Re: Intermittent problem with GPS synchronization > for multiple E310 units > On 4/2/21 7:17 AM, Ofer Saferman 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. > > As far as I know, no image has been setup to use package feeds. > > I know ntpd worked in release4 images, pretty sure the newer image was > redone and things have been left out that used to be there. > > Philip > > > > > 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* <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* <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 -- [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]
