OK, after working with the board for a few days I’m convinced the TX timestamp is just a suggestion.
I have my transmitter and receiver looped with a 1 meter cable through a 20dB attenuator. I’ve made the following observations:
- There is a significant latency between passing a buffer to the TX stream and when the data can come out the spigot: latency is between 10 and 600 uS depending on the sample rate (higher rates = higher latency). If you set your TX time to be earlier than this latency, it will chop off the beginning of the buffer.
I believe there are several issues here. First is the latency of the samples, through the various API layers and the USB buffering down the cable. Then there are numerous FIFOs in the FPGA.
It appears from the FPGA code (VHDL) that they’re using a 120 MHz clock to run the timestamp comparison - there’s a counter that’s reset at time zero, and when the counter matches the timestamp the samples are sent to the SDR chip. This tells me several things (all bad for my radar application): granularity of the TX timestamp is not one nanosecond (which the Soapy API implies), and because the time clock is not necessarily at the same rate as the sample clock it means there will be significant start time jitter because of the clock domain transition.
- Even when you set your TX timestamp to be later than the pipeline latency, the loopback timing is still grossly non-deterministic. For low sample rates the error is low (on the order of a single sample), but at 61.44 MS/sec the TX to RX delay can vary by many thousands of samples.
I’m going to connect my unit to a high speed scope later today to determine if the variation is on the TX or the RX side (or, perhaps, both).
Is anyone else making progress on this issue?