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.nel...@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!
