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!
