discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: B200 clock and pulse timing


From: Mike
Subject: Re: B200 clock and pulse timing
Date: Wed, 7 Apr 2021 00:58:39 -0400

Marcus,

Yes, I should have been more specific.  I am interested in the timestamp clock that provides values to the uhd_rx_streamer_recv () metadata and to the get_time_last_pps() calls.

I am sampling at 48 MSPS (with sc8 samples).

Your recollection is good; the schematic and wiki show a 40 MHz VCTCXO.

I don't mind buffering as long as the sample buffer metadata timestamp and the last PPS timestamp come from the same clock and that clock has sufficient resolution and stability (low jitter?).  What I'm trying to get to is, how much resolution is available (at 48 MSPS) in these timestamps and how close can I expect the sample and PPS timestamps to be to their respective "actual" signal reception?  I expect there to be more delay in the sampling path than the PPS path, but is there a way to characterize those different delays?

Thanks!


On 4/6/2021 9:34 PM, Marcus D. Leech wrote:
On 04/06/2021 07:14 PM, Mike wrote:

Hello,

I’d like to better understand the clock in the B200/B210.

First, what is the actual resolution of the clock?  Is it any more precise than the 100 nanoseconds a 10 MHz external reference provides?  When the USRP timing is set to external, does the 10 MHz directly increment the clock or is the on-board oscillator still involved somehow?

 

By "resolution of the clock", you presumably mean the Timestamp clock--there are many clocks used in a radio system.  The timestamp
  clock "ticks" at the rate of the master-clock rate at which the AD9361 runs.  Usually, the master clock rate is some multiple of the
  sample-rate.

The clock architecture of the B2xx has an on-board TCXO that provides top-level clock-reference for a number of functions, including
  deriving the master-clock used by the AD9361 RFFE chip.   I recall that TCXO runs at 40MHz, but the schematics can be consulted for
  a definitive answer. 

https://files.ettus.com/schematics/b200/b210.pdf

When you use an external reference, it drives a PLL chip to provide the top-level clock for everything on the board.  It is typically the
  case that you use an external reference because it is better than the on-board TCXO (or because you want synchronization across
  multiple units in some cases).  The on-board TCXO is a +/- 2PPM part. External references such as an OCXO, GPSDO, Rubidium clock
  are very much better than this.


I’d also like to confirm that my approach to using the B200 clock is correct.

I'm using a B200 and UHD 3.15.0 under Ubuntu 20.04 and am employing the PPS port as a trigger, trying to collect a set number of samples as soon after the a pulse is received on the PPS port as possible.  I have an external 10 MHz reference feeding the B200, although my understanding is that it shouldn’t matter since I’m using the same clock for relative comparisons as described below.

My software begins streaming samples from the B200 at a fixed rate.

Inside a loop I call uhd_rx_streamer_recv () and use the associated metadata timestamp to note the time the first sample in the read buffer arrived.  Obviously the read buffer has a fixed length and therefore represents a fixed amount of time at my sample rate; the software uses this value in the processing below.

Also in that loop, the software calls get_time_last_pps() and compares the result to a previous get_time_last_pps() call to determine if a pulse arrived on the PPS port.

Prior to receiving a PPS pulse, this loop continues, discarding the sample buffer after the PPS comparison.

When a pulse arrives, the software compares the sample buffer metadata timestamp to the last PPS timestamp.  The software uses that time difference to determine if the sample buffer should be discarded; the goal is to discard all of the samples that arrived prior to the PPS pulse.  If the difference between the sample buffer timestamp and the PPS timestamp is greater than the buffer length time, the sample buffer is discarded and the uhd_rx_streamer_recv() is called again to read the next set of samples.

When the difference between the most recently read sample buffer timestamp and the PPS timestamp is less than the buffer length time, the software drops the first part of the sample buffer corresponding to that difference, in essence dropping the samples that arrived prior to the exact PPS time.  The software then calls uhd_rx_streamer_recv () repeatedly, appending new samples to the first partial sample buffer until the desired total number of samples are collected.

Does this method make sense to achieve my goal of collecting samples immediately after a PPS trigger pulse?  Is there an easier way to achieve this goal?

Testing this method has shown that the number of sample buffers returned via the recv() call relative to the PPS pulse varies, sometimes significantly.  On average, discarding two or three sample buffers brings the subsequent sample timestamp to within the fixed buffer length (time) of the last PPS pulse.  However, there are circumstances when dozens or even a hundred sample buffers need to be discarded because their metadata timestamps are all prior to the PPS timestamp.

Is it reasonable that the sample buffer timestamp could be so far behind the PPS pulse time on occasion?

 

There can be many many many samples "in flight" when a PPS arrives.   What sample rates are you using?  There is necessarily buffering
  within the systems USB drivers, and within UHD.

You can tune this to a certain extent using the USB transport parameters:

https://files.ettus.com/manual/page_transport.html#transport_usb

But trimming back buffering to reduce average latency risks losing samples (overruns).


Thanks!



reply via email to

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