You're probably seeing the "site survey" phase of the GPSDO's acquisition.
This only happens immediately after applying power, right? The GPSDO needs
time to settle in.
--n
On Tue, May 24, 2016, 8:10 AM Meelis Nõmm <meelisn...@gmail.com> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
