discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

B200 clock and pulse timing


From: Mike
Subject: B200 clock and pulse timing
Date: Tue, 6 Apr 2021 19:14:54 -0400

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]