The time stamp clock is the same as that returned by get_time_last_pps. You will necessarily be running with a master clock on the AD9361 of 48Mhz so that’s the resolution of your time stamps. Ideally you’d like the time stamps to be strictly referred to the antenna input plane. But that is not what happens in reality. There will be some fixed latency that is dependent on your setup both in the analog and digital realms. The exact number would have to characterized in your setup.
For example you could have a noise generator that is activated by the same PPS signal as is going into your B2xx Sent from my iPhone > On Apr 7, 2021, at 12:59 AM, Mike <mike.nel...@rdss.com> wrote: > > > Marcus, > > Yes, I should have been more specific. I am interested in the timestamp > clock that provides values to the uhd_rx_streamer_recv () metadata and to the > get_time_last_pps() calls. > > I am sampling at 48 MSPS (with sc8 samples). > > Your recollection is good; the schematic and wiki show a 40 MHz VCTCXO. > > I don't mind buffering as long as the sample buffer metadata timestamp and > the last PPS timestamp come from the same clock and that clock has sufficient > resolution and stability (low jitter?). What I'm trying to get to is, how > much resolution is available (at 48 MSPS) in these timestamps and how close > can I expect the sample and PPS timestamps to be to their respective "actual" > signal reception? I expect there to be more delay in the sampling path than > the PPS path, but is there a way to characterize those different delays? > > Thanks! > > > > On 4/6/2021 9:34 PM, Marcus D. Leech wrote: >> On 04/06/2021 07:14 PM, Mike 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? >>> >>> >>> >> By "resolution of the clock", you presumably mean the Timestamp clock--there >> are many clocks used in a radio system. The timestamp >> clock "ticks" at the rate of the master-clock rate at which the AD9361 >> runs. Usually, the master clock rate is some multiple of the >> sample-rate. >> >> The clock architecture of the B2xx has an on-board TCXO that provides >> top-level clock-reference for a number of functions, including >> deriving the master-clock used by the AD9361 RFFE chip. I recall that >> TCXO runs at 40MHz, but the schematics can be consulted for >> a definitive answer. >> >> https://files.ettus.com/schematics/b200/b210.pdf >> >> When you use an external reference, it drives a PLL chip to provide the >> top-level clock for everything on the board. It is typically the >> case that you use an external reference because it is better than the >> on-board TCXO (or because you want synchronization across >> multiple units in some cases). The on-board TCXO is a +/- 2PPM part. >> External references such as an OCXO, GPSDO, Rubidium clock >> are very much better than this. >> >> >>> 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 >> within the systems USB drivers, and within UHD. >> >> You can tune this to a certain extent using the USB transport parameters: >> >> https://files.ettus.com/manual/page_transport.html#transport_usb >> >> But trimming back buffering to reduce average latency risks losing samples >> (overruns). >> >> >>> Thanks! >>> >>
