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
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