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 message has been scanned for viruses and
dangerous content by MailScanner, 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

Reply via email to