Timestamping support

[staticfloat]

We need a way to receive buffers with sample-accurate timestamp. SoapySDR has a way to surface timestamps if supported by hardware (the timeNs method) so we mostly just need a way to synchronize a sample clock among the various XTRXs in a XYNC carrier, then transmit buffers along with their starting sample clock time.

It would be nice if each buffer transmitted by each XTRX started at the same time, but that is not strictly necessary; it's fine for each buffer to be offset and require the host to shift them relative to eachother to get a coherent matrix of samples.

Florent suggests using the PPS signal as a synchronization signal to the XTRXs:

For the timestamp, the best is probably to share a common clock + PPS (or synchro), this is what I'm doing on other projects and works well. This allows the boards to have synchronized timestamps and avoid too much post processing of the received samples on the host. Is it possible with the Octo Carrier?

Concrete TODOs

• [ ] Determine the XTRX synchronization method
  • Ensure the synchronization method also works when XTRXs are run solo, we don't want to break that
• [ ] Build synchronization gateware and firmware
• [ ] Surface timestamps in SoapySDR driver (we can make use of information that tells us how much data we lost in an overflow event, for example)

[staticfloat]

Steve took some pictures of the reference clock and PPS distribution buffers:

The clock buffers appear to be TI CDCLVC1108's.

[staticfloat]

Florent suggests eschewing timestamps at first, and simply ensuring that all DMA engines are sample-synchronized. This ensures that the starting sample of each DMA buffer is sample-synchronized, and as long as you read the DMA buffers from each device in lockstep, you should naturally get a synchronized multichannel matrix.

This has the benefit of simplicity, but it does not solve the issue of knowing the absolute value of time lost in an underflow event. If our hw_count and sw_count buffer values are valid across overflows however, this could be determined in software by analyzing the handle values, so there is perhaps no need for actual timestamps transmitted by the hardware.

[enjoy-digital]

@staticfloat: Ensuring proper synchronization at startup is a prerequisite for timestamp support, so we can already do this and see if we are able to recover in case of underflow with hw_count/sw_count. If not, we'll add the timestamps :)