On 19/05/2011 3:13 PM, Bastien Auneau wrote:
why should I use set_time_next_pps() ? Is it needed to init USRP lock to
GPS time ?
Keep in mind that the PPS support pre-dates the existence of an "in
skin" GPSDO, and the
*primary* purpose of the GPSDO is to provide a stable 10MHz reference
clock for the
PLL synthesizers, ADC clocks, and DSP-chain within the FPGA.
Internal to the FPGA, there's a clock register that runs at 100MHz
(10ns/tick). The purpose of
set_time_next_pps() is to arrange for that register to be set to
whatever you supply, at the next
1PPS input transition. The purpose is to allow synchronization of
multiple USRP2/N210 so that
they all more-or-less agree on sample timing.
Consider the following scenario:
o A number, greater than one, of USRP2/N2xxx
o All seeing the same 1PPS and 10MHz ref-clocks
o They've all just been sent a set_time_next_pps() command from the host
o The 1PPS pulse arrives some time *after* you've done the
set_time_next_pps()
o Once that 1PPS pulse arrives, on a one-shot basis, the master clock
in all of the the USRP2/N2xx to which you've
sent the set_time_next_pps() command all now agree on the current
"time". But this is a sample time, and it only
has meaning within the context of sample synchronization. It
doesn't necessarily have any relationship at all to "real" time.
The USRP-family, internally, neither knows, nor really cares, about
absolute time-of-day.
Now, having said that, the UHD protocol allows you to set the "time at
next PPS" or "time right now please" to anything you want, and
it looks (from the FPGA code, Josh could confirm) that the time is
divided into a 32-bit seconds field, and a 32-bit "ticks" field. The
"ticks" field ticks over at the nominal FPGA clock frequency of 100MHz,
which gives 10ns per tick. So you could set the 32-bit seconds
field to the host TOD clock more-or-less directly, after scaling the
ticks appropriately.
My understanding is that USRP is GPS locked because it has GPSDO. then I
use get_time() to ensure that my PC clock will not get delayed by more
than some millisec (+/-) from USRP clock. Taking into account ethernet
delay, and some more internal delay, I was expecting to get some 10 to
20 millisec accuracy. This way I know that I can send all the burst to
USRP with TX_timestamp around 50 millisec in the future.
Again, the USRP2/N2XXX family use the GPSDO primarily to provide a
high-quality 10MHz reference clock, and the 1PPS
for synchronizing the *sample* timestamping mechanisms. The
USRP2/N2XX does not, at this point, actually parse the
NMEA-0183 GPS sentences and set its internal time-of-day (actually,
sample) clock to GPS time. The "in skin" GPSDO was
primarily regarded (AFAIK) as a convenient substitute for an external
10MHz and 1PPS reference, to simplify packaging.
The "model" is that the host(s) are the primary time-of-day reference.
If you want to make sure the USRP2/N2XXX doesn't drift
relative to the host, I would make sure the host is running NTPD, and
then have your *application* occasionally use the
set_time_next_pps() or set_time_now() functions to cause
synchronization between the hosts time-of-day "view" and that
of the USRP2/N2XX.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
