Re: B200 clock and pulse timing

[address@hidden]

https://files.ettus.com/schematics/b200/b210.pdf first page U101 is a x4 PLL
that converts the incoming 10 MHz to 40 MHz to feed U2 the AD9361.

JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

April 7, 2021 1:17 AM, "Mike" <mike.nelson@rdss.com> 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?
> 
> 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?
> 
> Thanks!