LimeSuiteNG: Transmitting raw I/Q samples from a file with LimeSDR Mini 2.0

Projects Lime Suite
1

I would like to transmit raw I/Q samples from a file using the LimeSDR Mini 2.0 with the LimeSuiteNG library. I modified LimeSuiteNG/src/example/basicTX.cpp to read a raw data file instead of generating samples internally. The code works reliably at a 5 MHz sampling rate, but at higher rates it occasionally drops samples.

Is there any working C++ example that demonstrates streaming I/Q samples from a file using LimeSuiteNG? For my experiment, I need a stable transmit rate of 12 MHz or higher.

Any guidance or sample code would be greatly appreciated.

2

You can use limeTRX command line interface to transmit from file.
limeTRX --input TxSamplesFile.binary --txPacketsInBatch=8
File should be little endian 16bit integers.
The txPacketsInBatch controls size of USB transfers, the default value might be too low depending on host PC, so increasing this value should improve performance and avoid sample drops.

1 Like
3

Thank you for the helpful information. I assume the required file format is sc16, with interleaved signed 16-bit I/Q integers in little-endian order.
First, I configured my LimeSDR Mini 2.0 using limeConfig:

limeConfig --initialize --samplerate=2.6e6 --txen=1 --txlo=1575.42e6 --txlpf=5e6

Then I started transmitting the sample file using limeTRX as suggested:

limeTRX --input gpssim.bin --txPacketsInBatch=8 --log=verbose
USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:1, DMA_ReadSize:4096, link:I12, batchSizeInTime:113.333us FS:11999999.000000, FIFO=2205*1360
Tx0 Setup: samplesInTxPkt:1360 maxTxPktInBatch:8, batchSizeInTime:906.667us
Tx file size : 20232704 bytes.
Samples received: 16384
Samples received: 6029312
Samples received: 12042240
Samples received: 18055168
Samples received: 24068096
Samples received: 30081024
Samples received: 36093952

The actual TX file is larger than 4 GB, but limeTRX reports only about 20 MB, and the transmission finishes very quickly. I also see only a very brief flash of the red TX LED.
Is there a file-size limitation in limeTRX?
How can I properly transmit a large TX file for testing with the LimeSDR device?

4

I checked the limeTRX source code and found that the TX file size is stored in an int, so files larger than about 2 GB cannot be handled correctly. After generating a smaller TX file, limeTRX recognized the file size correctly and the red TX LED illuminated as expected.

However, I still cannot observe any transmitted signal around the specified center frequency on a spectrum analyzer. Is there any additional parameter that must be set in either limeConfig or limeTRX to enable proper RF transmission?

5

Correct.

also set tx antenna and gain --txpath=Band1 --txgain=60

1 Like
6

Thank you very much for the helpful advice. After adding the options --txpath=Band1 and --txgain=60 to the limeConfig command, I was finally able to observe the expected RF signal on the spectrum analyzer. Everything is now working correctly.

I appreciate your support and guidance.

7

By increasing the txPacketsInBatch option in limeTRX to 8 or 16, the number of dropped samples at a 12 MHz sampling rate has been greatly reduced. However, I still occasionally encounter dropped samples when the following message appears:

USB ep:83 Rx0: 35.485 MB/s | TS:888828000 pkt:653248 o:0(+0) l:2(+1) dma:40828/40829(+1) swFIFO:0

What possible reasons could cause the TX data to be dropped? Considering the USB 3.0 bandwidth, I would expect that 12 MHz IQ transmission should still have plenty of margin.

What can I do to achieve stable transmission at higher sampling rates with the LimeSDR Mini 2.0?

8

This is on Rx side, you can also set --rxPacketsInBatch=16, even If you are only transmitting, Rx is still active to provide timestamps data.

USB 3.0 bandwidth yes, but there are nuances that affect it. Data batch sizes, large batches achieve better bandwidth and smaller CPU overhead, but at the cost of latency. Also there is gateware implementation details of how much data it can buffer, and the on board FT601 USB controller even though the data transfer is full-duplex, it’s processing within the controller is half-duplex, it has to switch between Rx/Tx processing reducing available bandwidth

Set both --rxPacketsInBatch and --txPacketsInBatch to same amount, 16 is possibly best, higher values won’t have noticable benefit.

9

I tried setting both --txPacketsInBatch and --rxPacketsInBatch to 16, but unfortunately the issue still persists. I continue to see the same RX message, and TX samples are still dropped each time that RX message appears. It seems that activity on the RX side may be interfering with the TX process. I will try removing all RX-related code from limeTRX to make it a TX-only implementation and see if that improves stability.

10

You can force disable Rx streaming in these source locations:

11

Thank you for the advice. However, even after commenting out all RX-related functionality, I still see occasional TX data drops at a 12 MHz sampling rate.

I am currently running limeTRX on a Windows 11 system. In the following post, oe1rsa reported stable TX at 40 Msps when running as root:

This makes me suspect that the issue may be related to the Windows environment. I will try running limeTRX on Ubuntu, using nice to increase its scheduling priority, and see if that improves the stability.

12

For Windows you can try increasing this value to 4096*16 LimeSuiteNG/src/comms/USB/FT601/FT601.cpp at d24de155eecfd3380b1436b6e277654a378a7a0e · myriadrf/LimeSuiteNG · GitHub

13

Thank you for the tip. I increased the streamBufferSize to 4096*16, but unfortunately this did not resolve the issue on Windows.

14

I built LimeSuiteNG from source on Ubuntu 24.04 and ran limeTRX with the same configuration as on Windows. It now operates smoothly at 12 Msps without any TX data drops. The issue on Windows is still unresolved, but at least the problem seems fully resolved when running on Ubuntu.