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

[Meelis Nõmm]

@Nick No this effect I see after the GPSDO already has a lock and is running (is powered) for more than 30min.

@Andy Interesting. I agree, I also plan to use the hack, but would really like to try to find the root cause. Also, maybe I stumbled on something useful that the Ettus guys can use to improve the USRPs.

@Marcus I'm using both N200 and N210.

I just wonder that could it be that once the program is started, either in the GPSDO oscillator control loop or in the USRP motherboard clock generator a sync process is started that otherwise in standby mode is not running.

I expect that while powered the GPSDO module continuously receives the GPS signals and syncs the 10MHz reference, irrelevant of the FPGA running a program (using the 10MHz) or not . If this is so, then this effect is not related to the GPSDO. Unless, this is not true and the GPSDO is affected by the motherboard starting to use the 10 MHz reference. [Another topic, but I have also witnessed that if a signal is fed to 2 USRPs through a splitter, in the received signals I can see when the other USRP starts its program. In the one that starts before, the received signal level is reduced, once the other starts].

This leaves us the USRP motherboard clock generation circuitry that uses the GPSDO 10MHz reference to derive the 100MHz ADC clock, from where finally we get to the 10 MSps. I do not know the inner behaviour of the clock generation circuitry, but to me it seems that once a program is started in the FPGA, a certain process is started that slightly affects the ADC clock over the first 3-5 minutes. Only after this period the clock is truly stable and synced with the GPSDO. Once the program is stopped the clock is "released" from the GPSDO ref and starts to diverge again, if the program is restarted quickly, the clock is still synced well enough and we don't see the given effect, but if the pause is longer the circuitry starts syncing again and we see the effect in the delays.

If this is true. I wonder if there was a way to keep the USRP motherboard syncing the clock in the clock generation unit all the time?

Meelis

On Tue, May 24, 2016 at 7:34 PM, Andy Walls <address@hidden> wrote:

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