Re: [Discuss-gnuradio] ptime get_time(void) precision down to millisec microsec nanosec ?

[Marcus D. Leech]

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.