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 <patchvonbr...@gmail.com>
> 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 <patchvonbr...@gmail.com>
>> 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 <o...@navigicom.com> 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 <patchvonbr...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 31, 2021, at 2:22 PM, Rob Kossler <rkoss...@nd.edu> 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 <rkoss...@nd.edu> 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 <o...@navigicom.com>
>>>>> 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" <patchvonbr...@gmail.com>
>>>>>>> To: usrp-users@lists.ettus.com
>>>>>>> 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 -- usrp-users@lists.ettus.com
>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>>>
>>>>> _______________________________________________
>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>
>>>>
>>> --
>>> 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 -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
