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

[Marcus Müller]

Hi Meelis,

what USRP are you using?

This is indeed an interesting plot. So let's look at the clocks and control mechanisms involved (this is assuming you're using something like the N2xx or X3xx with the matching GPSDO):

1. Inside the GPSDO:
• Oven-controlled oscillator
• Temperature drifts severely change the frequency of oscillators, so there's an oven that is temperature controlled (probably by a simple PD controller)
• GPS receiver
• The recovered GPS clock is used as a reference unit of frequency
• GPS reception is not an errorless process, i.e. there's some error mitigation/holdover/carrier synchronization going on before a clock can be derived
  
• oscillator control loop
• The GPS reference is compared to the actual frequency of the oscillator, and the latter is being influenced, usually by changing some control voltage
• this control loop is typically relatively complex and implemented partially in GPSDO firmware
2. Aboard the USRP motherboard:
• Multiplexer IC selects external/internal/GPSDO 10MHz source
• Clock generation circuitry derives with, e.g. X3xx uses the Texas Instruments LM04816 clock generator
• multiple PLLs involved in deriving the ADC, DAC, FPGA and daughterboard clocks from the 10 MHz reference
3. On individual daughterboards:
• Typically, daughterboards have fractional-n synthesizers, which means they have frequency multipliers and dividers, using PLLs themselves

One more thing: Tuning to a given frequency consists of two things, first of all of course the physical setting of the synthesizers mentioned under 3., and secondly on correcting the residual frequency offset (as the name suggests, these synthesizers have a finite set of possible frequencies and can't hit every frequency exactly) by effectively multiplying the Master Clock Rate (X3xx: typically 200 MS/s, alternatively 184.32 or 120 MS/s, N2xx: 100MS/s) sample stream with a complex oscillation (so, in RX, the samples coming from the ADC are first shifted in frequency and then filtered and decimated to your 10MHz sampling rate).

So when watching out for phase synchronous receiption, you do not only have to take care that sampling starts at the same instant, but also that the daughterboard synthesizers were tuned exactly at the same time leading to the same phase (if your daughterboard has that capability at all). Also, you must make sure that the phase accumulator in the FPGA, used for the "digital" part of tuning mentioned above, has the same value on all devices.

Best regards,
Marcus

On 24.05.2016 16:37, Meelis Nõmm wrote:

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.

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?
Meelis

        ##Setup UHD Source##
        self.uhd_src = uhd.usrp_source(
            device_addr=self.uhd_addr,
            stream_args=uhd.stream_args('fc32')
            )

        #Should be redundant for N2xx with internal module, but just to be safe
        self.uhd_src.set_clock_source("gpsdo")
        self.uhd_src.set_time_source("gpsdo")

        print "Checking if GPSDO locked"
        while(not self.uhd_src.get_mboard_sensor("gps_locked").to_bool()):
            time.sleep(0.1)
        time.sleep(0.2)
        print "GPS Locked  , bool = ", self.uhd_src.get_mboard_sensor("gps_locked").to_bool()

        print "Checking if ref locked"
        while(not self.uhd_src.get_mboard_sensor("ref_locked").to_bool()):
            time.sleep(0.1)
        time.sleep(0.2)
        print "10 MHz Locked  , bool = ", self.uhd_src.get_mboard_sensor("ref_locked").to_bool()

        t = self.uhd_src.get_time_last_pps()
        while (t == self.uhd_src.get_time_last_pps()):
            pass
        #Set the time from the GPS time
        gps_time = self.uhd_src.get_mboard_sensor("gps_time").to_int()
        self.uhd_src.set_time_next_pps(uhd.time_spec(gps_time+1))
        #This sleep is recomended to stabilize the clocks
        time.sleep(1)

        ##Initialization and connecting

        #Set the start time
        self.uhd_src.set_start_time(uhd.time_spec(gps_time + 3))

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio