Soapy LimeSDR (LimeSuite Classic plugin): Single-Shot File Transfer Data Loss and Incorrect Reconfiguration When Switching Bands

Projects LimeSDR
1

Hello everyone,

We are implementing packet-based file transfer using LimeSDR Mini 2.4, entirely in GNU Radio with Soapy LimeSDR source and sink blocks (LimeSuite Classic), and are observing severe and consistent data loss when the system is run without repeat enabled in the GNU Radio File Source block. For an 8 KB file, only the first ~1 KB is received correctly and consistently, while the remaining ~7 KB—corresponding exactly to the rest of the file in order—is not transmitted or received at all. This can be because GNU Radio flowgraph execution terminates before the Soapy LimeSDR Sink completes the entire file transfer. When repeat is enabled in the File Source block, the entire file is received reliably after the first iteration of repeat; however, this approach is not suitable for automated file transfer, as it results in repeated appends and requires post-processing.

This behavior is specific to the Soapy LimeSDR source/sink blocks (LimeSuite Classic Soapy plugin) and is not observed when using UHD (USRP) or LimeSuiteNG source/sink blocks, which appear to maintain the stream by may be governing the rate at which other GNU Radio blocks operate, as the entire processes of transmission/ reception happens for a longer time and no data loss occurs.

The issue is reproducible in both single-device wireless loopback and dual-device setups, with gain levels verified to avoid saturation.

Since our development and validation have been based on the Soapy LimeSDR LimeSuite Classic plugin, we do not want to migrate directly to LimeSuiteNG at this stage. Additionally, we have observed other device setup and data transfer inconsistencies when using LimeSuiteNG, making it unsuitable for our current workflow.

In addition to the file transfer issue, we are observing another configuration-related issue with the Soapy LimeSDR source and sink blocks (LimeSuite Classic) related to center frequency reconfiguration. When a GNU Radio Companion flowgraph is first run with the center frequency set to 866 MHz, and then re-run with the center frequency changed to 2.4 GHz, the received signal level at 2.4 GHz is significantly reduced (approximately 43 dB lower) compared to operation at 866 MHz. However, if the LimeSDR is unplugged and replugged, and the flowgraph is started directly at 2.4 GHz, the received signal level is only ~18.5 dB lower than that at 866 MHz. The TX and RX gain settings were kept identical for both frequency bands. This frequency-dependent behavior—triggered specifically by reconfiguring from 866 MHz to 2.4 GHz without a device reset—is not observed when using LimeSuiteNG source and sink blocks, and suggests that the Soapy LimeSDR blocks may not be correctly reconfiguring the device when switching frequency bands. (HW used: LimeSDR mini 2.4)

Has anybody faced similar issues with the Soapy LimeSDR source/sink blocks (LimeSuite Classic plugin)? If so, is there a permanent fix.

Thank you.

2

Why use SoapySDR blocks when there are native blocks which avoid this additional software layer?

3

Hi Andrew,

Thank you for the response, and apologies for the delay — it took me a bit of time to properly test the different configurations and drivers.

I wanted to share a few observations from my side:

  • The reconfiguration issue when switching from 866 MHz to 2.5 GHz is not observed with gr-limesdr 3.10.

  • The inconsistencies I was seeing with LimeSuite NG are also not present when using gr-limesdr 3.10.

However, I am still facing an issue with transmitting the entire file, although there is a significant improvement compared to the SoapyLimeSDR drivers:

  • With SoapyLimeSDR, only about 1 KB out of an 8 KB file is received consistently.

  • With gr-limesdr 3.10, around 7.5 KB out of 8 KB is received when the sampling rate is set to 1.024e6.

A few additional observations:

  • The amount of data received decreases as the sampling rate increases.

  • When using UHD: USRP Sink/Source blocks, the entire file is received with no loss.

  • Similarly, whenever LimeSuite NG works correctly (it has been somewhat inconsistent for me), no data loss is observed.

Given this behavior, I wanted to ask:

  • Why does this partial data loss still occur specifically with LimeSDR in this setup?

  • Is there a known architectural or implementation difference between the Sink/Source blocks in gr-limesdr 3.10, SoapyLimeSDR, and gr-limesuiteNG that could explain this?

  • Is there a recommended or permanent fix for ensuring reliable full-file transmission at higher sampling rates?

Thanks again for your help and insights.

4

Thanks for the additional data points.

Tagging @ricardas