Re: B200 clock and pulse timing

[Nick Foster]

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?

The clock is locked to the 10MHz external reference and uses 1PPS as a trigger to initialize the sample clock to a given time at startup. Accurate timing requires the 1PPS trigger to be synchronous to the 10MHz source. In practice this means they should come from the same GPSDO. The 10MHz reference does not directly increment the sample clock. It is used to lock the main oscillator's PLL and thus makes it also synchronous to the 1PPS trigger.

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?

Yes. Use the timed command functionality to trigger reception of a discrete number of samples at the time you wish to receive them -- in this case, 1.000s, 2.000s, etc. If the sample clock is initialized using external 1PPS, and it is also locked to a synchronous 10MHz source, your samples will be returned to you nicely aligned.

 

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?

Use timed commands to trigger reception. Ignore get_time_last_pps(). Doing sample timing from within a loop on the host computer (behind many buffers, operating on a different clock, nondeterministically interrupted) is asking for lost data and race conditions. If you require very accurate antenna-plane sample time you will need to compensate for front end, ADC, and DSP delays in the AD9361. There are various ways of doing this, none of them particularly convenient.

Nick

 

 

Thanks!