Re: [Discuss-gnuradio] Syncronization issues, using a GPSDO

[Andy Walls]

On Tue, 2016-05-24 at 10:37 -0400, address@hidden
wrote:
> Date: Tue, 24 May 2016 17:37:35 +0300
> From: Meelis N?mm <address@hidden>

> Hello everyone,
> 
> 
> I have been working on a positioning implementation and for that I need
> very good time synchronization between the USRPs that are geographically
> not in the same location. Considered a few possibilities, but decided to
> test out the GPSDO modules for the time sync (also provides the needed 10
> MHz). In order to measure the time sync, I?m periodically feeding both
> USRPs with the same frequency sweep signal, storing the interesting
> sections and calculating the delay between them via correlation.
> 
> 
> Overall it seems to work, but I?m witnessing an interesting effect. As I
> start the program, within the first 4-5 minutes the time delay between the
> USRPs increases from (near) 0 to about 4-5 samples (400-500ns, with 10
> MSps). Once this phase is done, the delay between the USRPs stabilizes and
> the two seem to be quite well synchronized. I have attached delay plots
> from 2 different runs (this behavior I can reproduce every time).  If I
> restart the python program after the ?warmup? phase, the delay is very well
> restricted and clocks seem well synchronized (restart is denoted by the
> vertical line). It is also worth pointing out that the pause between the
> restarts is short (around 15 seconds), if I make the pause longer (more
> than 60 seconds or so) the results again exhibit a ?warmup? phase (figure
> "delays_result65_1"), but usually a bit less emphasized.

I've run into a similar effect with a host using NTP and the PPS and
$GPRMC sentence from X310 USRP.

I have a USRP-time vs. Host-time monitoring loop, and I see the USRP
time diverge from NTP time usually twice after startup: once immediately
after the streaming initialization (understandable), and then another
smaller jump some time later (I can't explain).

https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00326.html

> 
> Would like to know what causes this effect? It does not seem to come from
> the USRP clock sync python code (relevant code given below), as after the
> fast restart the effect is not present. Right now to me, it seems that in
> the GPSDO, or in the FPGA clock sync, a certain (lock) ?warmup? phase is
> done, once the FPGA starts to use the 10 MHz output. If the program is
> restarted fast enough, the clocks are still in sync, but if the pause is
> long enough the clock sync process(es) can be seen again?

>Any thoughts?

I was lucky enough to work up a fix with a USRP-time vs. Host-time
tracking loop, without knowing the root cause.

If you can find a solution for your problem without knowing the root
cause, you'll probably be OK.

> Meelis

-Andy