Latency, txBufferLength and scheduled transmit

Projects LimeSDR
1

Hi all,

I’m trying to lower the latency when transmitting at once. It seems that setting latency to 0 or 1 doesn’t change anything. If I set bufferLength to 54400 (ie 1360 * 40, I’m using SC12) and I pass my signal by chunks of 55400 samples, then my signal is sent faster. I gain ~200µs.

The problem is that now when I schedule a transmit, it seems that I can’t pass all the samples at once. Before, passing the samples to the Lime would take maybe 0.3ms, while now it takes ~11ms, knowing that I schedule the signal ~11ms in advance. I guess a fixed number of buffers is available somewhere, and they fill up faster as I set them to have a smaller size. As a result the call to SoapySDRDevice_writeStream ends up blocking.

I don’t know if this is linked to Soapy or Lime, nor if it’s in the C++ or FPGA part. Maybe @joshblum , @Zack or @IgnasJ can shed some light?

I would like to have the smallest latency when transmitting at once, while still being able to schedule signals without blocking as much as possible.

Thanks.

1 Like
2

Have a look here:

  1. Reducing USB3 Latency for RFID reader application
  2. Minimising round-trip latency

This was a colleague of mine who was doing some research that looked at using the LimeSDR for RFID but was having lots of issues with latency. I believe he solved the problem by purchasing a USRP…

3

Thanks, I already read those posts several times. Strangely , changing the latency setting didn’t seem to help on the TX part, changing the buffer size did help, but it impacted scheduled transmission negatively.

4

writeStream() blocks if buffer is full (as I understand, buffer is set 54400 samples in you application). Latency setting affects USB transfer size, however if sample rate is low it may not have effect as single-packet transfer size would be used anyway.