Latency, txBufferLength and scheduled transmit

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.


1 Like

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…

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.

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.