discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Syncronization issues, using a GPSDO


From: Meelis Nõmm
Subject: [Discuss-gnuradio] Syncronization issues, using a GPSDO
Date: Tue, 24 May 2016 17:37:35 +0300

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))



Attachment: delays_result64_8_bias.png
Description: PNG image

Attachment: delays_result64_9_bias_in_seconds.png
Description: PNG image

Attachment: delays_result65_1_bias_in_seconds.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]