By clock bias I am referring to the difference between true GPS time and the USRP time.

For example, in my application I am running 2 Separate B210 USRPs each side by side with a split signal coming from a single S band antenna. However, they are both disciplined using separate GPSDOs with separate antennas to simulate being 2 independent devices. They are being synchronized as described in method 2 in this article (https://files.ettus.com/manual/page_sync.html) and then the data collection is being commanded to start at the same GPS time for both devices.

My goal is to try to create as phase coherent of an operation as possible between the 2 USRPs.
When I cross correlate the 2 split S band signals to calculate difference in phase between the 2 signals, there is a significant drift over time. This phase difference converted is about 300 nanoseconds over the course of 1 second (300 PPB).Because of this, I wished to see if I could use the calculated clock bias that I described above to compensate for this drift in phase.

However, now that you have mentioned that I should in fact be getting 1 PPB accuracy when synchronized to GPS time, I am questioning if I am doing the time synchronization process wrong altogether Since I seem to be getting drift around 300 PB after following the instructions in the link above.

Sidd

On 06/05/2020 04:35 PM, Sidd Subramanyam wrote:

It would be useful to see the parts of your source-code that set up your
devices--including clock synch, etc.

Further, I'll note that two randomly chosen GPSDO units, even connected
to the same antenna, will be producing a 1PPS pulse up to several
(possibly 10s) of nanoseconds different from one another--which is
the typical spec on the 1PPS pulse.

In addition to this, two (or more) GPSDOs will not produce a 10MHz
output that precisely track each other, even when connected to the
same antenna.  Their long-term behavior is good, but short-term, they
can disagree with one another, in my experience, so building a
perfectly-coherent system from two separate GPSDO units doesn't work
nearly as well as you might hope, particularly not a lower-cost
unit such as is used in the B2xx (where "lower cost" is kind of a
relative term--the high-end GPSDOs that use a local Rb oscillator are
considerably pricey, but not easily packaged into something like the
USRP B210).

Thank you for this clarification regarding the 10 MHz drift and the 1 PPS
pulse. When you mention that the 10 MHz outputs will not precisely track
each other in the short run but better in the long run, could you provide
an estimate for the duration at which the behavior will track better? My
previous email had stated how in a 1 second interval I was experiencing
around a ~300 nanosecond drift. However, in other samples I had taken
spanning upto 30 seconds, this drift seemed to worsen upto ~15-17
microseconds. From your email regarding how much the 10 MHz deviates during
the short run as well as its long term behavior I’m very sure I must be
doing something wrong in my code setup.

I have provided some code sections of how I am attempting to synchronize
the time. I start this script at roughly the same time (within about a
couple of seconds) on both USRPs, and they begin to initialize settings
such as bandwidth and center frequency. I then have them wait to start
collection at the nearest rounded up 10 second time multiple of GPS time in
seconds, since the initialization can take varying time for both USRPs to
initialize. I also attached the full code to this email.

*1. Setting Center Frequency *

//set the center frequency
usrp->clear_command_time();

usrp->set_command_time(usrp->get_time_now() + uhd::time_spec_t(0.1));

//set cmd time for .1s in the future

uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request);
boost::this_thread::sleep(boost::posix_time::milliseconds(1100));

//sleep 110ms (~10ms after retune occurs) to allow LO to lock

usrp->clear_command_time();

2. Set to GPSDO time

//Set references to GPSDO
usrp->set_clock_source("gpsdo", 0);
usrp->set_time_source("gpsdo", 0);

3. Check for 10 MHz “ref_locked” and for ** GPS “gps_locked” From
Motherboard sensors

4. Set internal time to GPS time at the next PPS

//Set to GPS time
uhd::time_spec_t gps_time =

uhd::time_spec_t(time_t(usrp->get_mboard_sensor("gps_time",
0).to_int()));
usrp->set_time_next_pps(gps_time + 1.0, 0);

//Wait 2 seconds. Known issue
boost::this_thread::sleep(boost::posix_time::seconds(2));

//Check times
gps_time = uhd::time_spec_t(time_t(usrp->get_mboard_sensor("gps_time",

0).to_int()));
uhd::time_spec_t time_last_pps = usrp->get_time_last_pps(0);
//std::cout << "USRP time: " << (boost::format("%0.9f") %
usrp->get_time_last_pps(0).get_real_secs()) << std::endl;
//std::cout << "GPSDO time: " << (boost::format("%0.9f") %
gps_time.get_real_secs()) << std::endl;
if (gps_time.get_real_secs() == time_last_pps.get_real_secs())
std::cout << "USRP time synchronized to GPS time" << std::endl
<< std::endl;
else
std::cerr << "Failed to synchronize USRP time to GPS time" << std::endl
<< std::endl;

5. Command Stream to start at 10 second GPS multiple

cmd.stream_now = (buff_ptrs.size() == 1);
cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS;
cmd.stream_now = false;

//Calculate next 10 second GPS time to start
double timeNow = usrp->get_time_now().get_real_secs();
cmd.time_spec = uhd::time_spec_t(ceil(timeNow / 10.0) * 10.0);

    rx_stream->issue_stream_cmd(cmd);

-Sidd

On Fri, Jun 5, 2020 at 10:38 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:

On 06/06/2020 08:54 AM, Sidd Subramanyam wrote:

I don't immediately see anything wrong with your code, but of course,
this code is just recording samples, which you are presumably
cross-correlating in an "offline" manner post-facto?

Something you might try is to use integer-N tuning, which may result in
a more mutually-coherent LO setting across your two
synthesizers:

tune_req.args = uhd::device_addr_t
https://files.ettus.com/manual/classuhd_1_1device__addr__t.html("mode_n=integer");

Also, you log the time when the recording is expected to take place--are
these values actually the same in the two instances?

What sample rate are you using?  How much data are you recording?

Is this code ever triggered?

     if (time_tmp > 0.000001)
     {
         std::cout << boost::format("XX %d Get Time of USRP %f\n") % 

f % num_dropped_samps;
}

I am cross-correlating post-facto via a MATLAB script. Could you provide some Reading regarding the integer N tuning and how it’s used? I added exactly your command and initially didn’t seem to have too much of an effect. The logged start times do indeed line up exactly. I am sampling at 4 MHz collecting 1 second of data so the listed output is 4 million samples in sc16 format. That code snippet you mentioned never triggers an overflow of dropped samples.

-Sidd

On 06/08/2020 02:24 PM, Sidd Subramanyam wrote:

Here is the documentation of the API related to tune requests:

https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

In terms of what it MEANS, however, has to do with the way RF
synthesizers work.  There are a wide variety of articles "out there" on
both integer-N and fractional-N synthesis:

https://www.analog.com/en/analog-dialogue/articles/pll-synthesizers.html#

https://www.electronics-notes.com/articles/radio/frequency-synthesizer/pll-indirect-digital-fractional-n-synthesis.php

http://www.ti.com/lit/an/swra029/swra029.pdf?ts=1591648395602&ref_url=https://www.google.com

On 06/08/2020 02:24 PM, Sidd Subramanyam wrote:

One thing to note is that with any pair of GPS/GPSDO units, the 1PPS
pulse will happen at slightly different times for each unit (The LC_XO
unit used in the B210 is specced to +/-50NS).  This will inevitably
result in a phase/time offset in the sample streams from each unit, which
you will need to resolve.  However, once this offset is calculated,
the streams SHOULD NOT drift with respect to one another.

Now, a "robustly coherent" receiver system will ALWAYS use a shared LO
(best) or at least a shared 10MHz reference clock (2nd best). In your
case, you're not sharing the 10Mhz reference, but using independent
GPSDO units to provide a reference clock.  The effective mutual
phase noise between the two will be non-zero, and have components at
both low frequencies and high frequencies.

You might want to stick a dual-trace scope on the 10MHz outputs on your
two units to see what the magnitude of the mutual phase-noise
between the two units is.

The schematics are here:

https://files.ettus.com/schematics/b200/b210.pdf