Synchronizing the LimeSDR transmitter and receive using timestamps

Projects LimeSDR
1

Hi all,

I am using the limesuite c++ (I can also use the SoapySDR) library to configure the LimeSDR. I am developing a FMCW radar application and need the transmitter and receiver to be synchronized.

I’ve already read the following forums:
Timestamps support via SoapySDR
Problem using Lime w/Soapy ‘C’ API for full-duplex TX/RX
TX/RX round trip latency and coherence

For testing I use a 1/4 meter coaxial cable to short the transmitter and receiver together. The issue is that even when using the timestamps the receiver appears to be delayed when compared to the transmitter. I print out the timestamps and they match, but when I mix the transmit and receiver frequency to get a difference of a chirp I find that it is not near zero.

Here are the steps I take to transmit and receive.

  1. Start RX and TX streams
  2. Receive the RX stream twice and look at the timestamp
  3. Set the TX timestamp to transmit in the future, offset from the RX timestamp
  4. Transmit the signal (in the future)
  5. Continuously receive and look at the receive signal when the timestamp matches the transmit.

Using this method the RX and TX timestamps match. I capture most of the transmit signal. But there still seems to be a small delay

The delay changes depending if a LPF or calibration is enabled and depends on sample rate.

I don’t set up anything but TX and RX channel 0.

Is this the issue?
"But speaking generally, usually the FPGA handles the timestamps, so anything that happens between the RF and the FPGA potentially adds group delay, such as digital up and down conversion chains, and buffering.

So I would expect to see a timestamp delay for a loopback waveform. That said it should be consistent from run to run for the same sample rate and filter configuration."

Is there a way to accurately account for this delay in the LMS api?

Here is my configuration:
LMS_CLOCK_REF:3.072e+07
LMS_CLOCK_CGEN:1.024e+09
LMS_CLOCK_SXR :1e+08
LMS_CLOCK_SXT:1e+08
float Fs = 8e6;
float Tc = 0.01;
float Fc_start = 100e3;
float B = 3.5e6;
float centerFreqRX = 100.0e6;
float centerFreqTX = 100.0e6;
float gainRX = 0.4; //[0, 1.0],
float gainTX = 0.8; //[0, 1.0],

LMS_FMT_F32 as the sample data type. Right now I am transmitting 80000 samples per SendStream call and receiving 320000 samples per RecvStream call. Is the size the issue?

The fifo buffers are never filled all the way

The throughputVsLatency values do not seem to change anything.

I’ve read that some users have been able to get the TX and RX samples synchronized to each other to within 1 sample. I am currently about 78 samples off.

1 Like
2

As Josh noted, there will be a delay, but it should be consistent across runs for a given configuration. From what I recall things like the transceiver in the Osmocom GSM stack need to be configured with a delay figure, in order for it to work reliably. However, this is hard coded for each type of SDR hardware.

@Garmus, perhaps you could comment further on configuration steps etc.

3

For more details anyone can look at my code here.

4

Hi @kohlsn,

For more details anyone can look at my code here .

As I can see you disable https://github.com/kohlsne/LimeSDR-LFMCW-Radar/blob/master/LimeSuite/main.cpp#L76 TX burst (see for details: LimeSuite/src/lime/LimeSuite.h at master · myriadrf/LimeSuite · GitHub).
Just in case, I propose to enable it on and see if anything changes.

5

Thank you. That was an oversight. I did change it, but it did not have any effect.

I will move forward with my project. Since the delay is consistent across runs for a given configuration, I can take that into account when doing any signal processing. Although I am interested if someone finds an solution.