What is the maximum stable sample rate with the lime mini 2 on USB3?
I am trying a TX/RX setup and keep getting overflow warning on tx and packet losses on rx, no matter how low I go with the sampling rate. Well, yes when I set 1 Msps/sec the “warnings” go away.
But is this what I must expect?
Isn’t it possible to use higher sustained rates?
Are the losses something the software must be capable to handle in higher layers?
Thank you for hints in advance.
I am continuing experiments, with surprising results. I wrote a little program that just reads packets via StreamRx and evaluate the timestamp of StreamMeta. The timestamp is said to be pointing to the first sample. I thought I should not need to expect the timestamp of a read be lower than the index of the last sample of the previous read. But I can see exactly that. (Yes I checked the result value of StreamRX also.)
I am using LimeSuiteNG. Possibly this is my problem? Is LimesuiteNG just not ready for use with the LimeMini yet? I also cannot set the receive gains by e.g. gain[lime::eGainTypes::LNA] = 1.0;
Please tell me anyone if I am on the wrong track and I am better off by reverting to LimeSuite (classic).
Thank you.
I have been using LimesuiteNG on 2 LimeSDR minis (v 2.4) for some months now. I am able to reliably do tx and rx at 7.2 MHz. Sample rates higher than that do have usb errors, which increase with sample rate, however they are not too terrible. I am using a Macbook M3 Pro, and it sounds like things work better in the PC world. So, the problem is definitely not LimeSuiteNG.
Hmm, interesting. So I am wondering what I am doing wrong. As I have said in a related post I can use 4MSamples/sec full duplex with Limesuite (classic) when increasing the FIFO size enough.
Btw. I am running on Linux kernel 6.14.
How do you find out if packets are lost?
I am using the values from device→StreamStatus(); the ‘loss’ gives lost packets. I call that every time I do a send or receive. I am using the default FIFO size.
Hi, what is your gateware version for the LimeSDR Mini v2? It seems that the gateware 3.3 currently has issues with the USB transfers.
Also I’ve just fixed a bug in software which should improve stability. Fix USB streaming transfers stuttering at high speeds · myriadrf/LimeSuiteNG@33d5a94 · GitHub
Using older gateware (3.0) LimeSDR_GW/bitstream/LimeSDR_Mini_V2/limesdr_mini_v2.bit at 02b4ae8e570fd1e8af3676b3f58d02ddc9d08262 · myriadrf/LimeSDR_GW · GitHub
For Rx only I can get ~55Msps:
limeConfig --initialize --rxen=1 --txen=1 --rxlo=1e9 --txlo=1.1e9 --samplerate=56e6
limeTRX --log=debug
USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:4, DMA_ReadSize:16384, link:I12, batchSizeInTime:98.9091us FS:55000000.000000, FIFO=10110*1360
USB ep:83 Rx0: 165.642 MB/s | TS:54991600 pkt:40436 o:0(+0) l:0(+0) dma:10109/10110(+1) swFIFO:0
USB ep:83 Rx0: 165.659 MB/s | TS:109995440 pkt:80880 o:0(+0) l:0(+0) dma:20220/20221(+1) swFIFO:0
USB ep:83 Rx0: 165.659 MB/s | TS:164999280 pkt:121324 o:0(+0) l:0(+0) dma:30331/30332(+1) swFIFO:0
For full duplex Rx/Tx I can get ~33Msps
limeConfig --initialize --rxen=1 --txen=1 --rxlo=1e9 --txlo=1.1e9 --samplerate=33e6
limeTRX --log=debug --repeater=32768
USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:2, DMA_ReadSize:8192, link:I12, batchSizeInTime:82.4242us FS:32999999.000000, FIFO=6066*1360
Tx0 Setup: samplesInTxPkt:1360 maxTxPktInBatch:12, batchSizeInTime:494.545us
USB ep:83 Rx0: 99.385 MB/s | TS:32994960 pkt:24262 o:0(+0) l:0(+0) dma:12131/12132(+1) swFIFO:0
USB ep:03 Tx0: 99.238 MB/s | TS:33030144 pkt:24252 u:0(+0) l:0(+0) dma:2019/2021(+2) tsAdvance:+417/+707/+912us, f:0
USB ep:83 Rx0: 99.394 MB/s | TS:65994000 pkt:48526 o:0(+0) l:0(+0) dma:24263/24265(+2) swFIFO:0
USB ep:03 Tx0: 99.434 MB/s | TS:66043904 pkt:48528 u:0(+0) l:0(+0) dma:4042/4044(+2) tsAdvance:+417/+706/+912us, f:0
USB ep:83 Rx0: 99.385 MB/s | TS:98998480 pkt:72794 o:0(+0) l:0(+0) dma:36397/36397(+0) swFIFO:0
USB ep:03 Tx0: 99.434 MB/s | TS:99057664 pkt:72804 u:0(+0) l:0(+0) dma:6065/6067(+2) tsAdvance:+417/+705/+912us, f:0
LNA gain can only be set to specific values [0,3,12], other values will get rounded to one of these.
Correction, 3.3 gateware is fine, the issues were caused by background applications hogging CPU, if the CPU is 100% used, then it’s likely it won’t be able to process USB transactions fast enough and data drops happen. Running the application with elevated privileges allows the processing threads to switch to realtime scheduling and higher priority, that should improve performance when CPU load is high.
By default the Rx streaming is configured to transfer data in ~100us chunks to have low latency, but that results in more CPU overhead for handling those transactions. Number of stream packets in a transfer batch can be increased to lower CPU overhead, but that will increase latency accordingly.
What I have observed from the debug log is that the attempt to elevate priority failed. The CPU usage however is close to idling during the transfer. Not sure about the peak load of a single CPU, but their usage was all pretty low on average. I would have expected that a FIFO exactly does that: covering the peak loads.
I did not try yet to run with elevated privileges and I would prefer if I need not (just as with limesuite classic).
I do understand the tradeoff between throughput and latency. But I also believe this is something that belongs to the application and I would prefer if a library does not enforce policy on the developer (if possible).
Another observation: I was also peeking the state of the FIFO by using the stream status functions. I logged a message if the used count was != 0 and observed the count was 1 at maximum, meaning the FIFO seemingly isn’t used at all. Am I looking at the wrong status?
Yes, that is expected when running without elevated privileges. Same logic is used in legacy limesuite. It is not required to run with elevates privileges for usual use cases.
The software fix I mentioned should be enough to improve your situation.
It’s not enforced, the optional values for transfers performance tweaking are available when setting up the stream config LimeSuiteNG/src/include/limesuiteng/StreamConfig.h at 33d5a94c4e3962b6ea1b5d9677a250f796e1658f · myriadrf/LimeSuiteNG · GitHub
As for the FIFO size 250ms of buffering is plenty for accomodating load peaks, and that’s just the user facing FIFOs with samples already converted into desired format and channels deinterleaved, also there is additional buffering in the form of raw data buffers used for actual data transfering to/from device.
Of course the FIFO sizes can be also made optional and provided by user, the question is how it should be expressed? Bytes, samples count, time duration, memory pages… etc?
If your application is reading data pretty fast, then yes the FIFO can essentially be always empty, or with just couple of packets, which you read out on next iteration.
The stats are as follows:
FIFO usage: how much data is buffered in user facing FIFOs
Rx overrun: data has been received from device, but not placed in the user FIFO because it’s full
Rx loss: data was lost on device side
The bug I fixed in software was causing a delay when accepting data from device, making the LimeSDR Mini gateware to occasionally drop a packet, because it only has about 8K buffer and it was not read out fast enough.
Thank you! The Fix improved my situation, still some warnings are left:
[2025-09-29 16:43:25.809] [warning] lime: USB ep:83 Rx0: 15.708 MB/s | TS:19999140 pkt:19521 o:0(+0) l:56(+56) dma:19521/19522(+1) swFIFO:0
[2025-09-29 16:43:39.810] [warning] lime: USB ep:83 Rx0: 15.995 MB/s | TS:76005300 pkt:74412 o:0(+0) l:69(+13) dma:74412/74413(+1) swFIFO:0
[2025-09-29 16:43:40.810] [warning] lime: USB ep:83 Rx0: 15.999 MB/s | TS:80005740 pkt:78318 o:0(+0) l:83(+14) dma:78318/78319(+1) swFIFO:0
[2025-09-29 16:43:41.810] [warning] lime: USB ep:83 Rx0: 15.987 MB/s | TS:84006180 pkt:82221 o:0(+0) l:98(+15) dma:82221/82222(+1) swFIFO:0
[2025-09-29 16:43:56.812] [warning] lime: USB ep:83 Rx0: 15.950 MB/s | TS:144010740 pkt:141021 o:0(+0) l:112(+14) dma:141021/141022(+1) swFIFO:0
[2025-09-29 16:44:08.813] [warning] lime: USB ep:83 Rx0: 15.802 MB/s | TS:192016020 pkt:188021 o:0(+0) l:152(+40) dma:188021/188022(+1) swFIFO:0
[2025-09-29 16:44:15.813] [warning] lime: USB ep:83 Rx0: 15.417 MB/s | TS:220018080 pkt:215316 o:0(+0) l:244(+92) dma:215316/215316(+0) swFIFO:0
[2025-09-29 16:44:33.814] [warning] lime: USB ep:83 Rx0: 15.880 MB/s | TS:292021920 pkt:285863 o:0(+0) l:274(+30) dma:285863/285864(+1) swFIFO:0
[2025-09-29 16:44:35.815] [warning] lime: USB ep:83 Rx0: 16.060 MB/s | TS:300022800 pkt:293706 o:0(+0) l:275(+1) dma:293706/293707(+1) swFIFO:0
[2025-09-29 16:44:40.815] [warning] lime: USB ep:83 Rx0: 15.794 MB/s | TS:320023980 pkt:313249 o:0(+0) l:324(+49) dma:313249/313250(+1) swFIFO:0
[2025-09-29 16:44:42.815] [warning] lime: USB ep:83 Rx0: 15.974 MB/s | TS:328024860 pkt:321071 o:0(+0) l:333(+9) dma:321071/321072(+1) swFIFO:0
[2025-09-29 16:44:45.815] [warning] lime: USB ep:83 Rx0: 16.044 MB/s | TS:340026180 pkt:332832 o:0(+0) l:338(+5) dma:332832/332833(+1) swFIFO:0
[2025-09-29 16:44:48.816] [warning] lime: USB ep:83 Rx0: 15.987 MB/s | TS:352027500 pkt:344579 o:0(+0) l:357(+19) dma:344579/344580(+1) swFIFO:0
[2025-09-29 16:44:50.816] [warning] lime: USB ep:83 Rx0: 15.823 MB/s | TS:360028380 pkt:352364 o:0(+0) l:396(+39) dma:352364/352365(+1) swFIFO:0
[2025-09-29 16:44:51.816] [warning] lime: USB ep:83 Rx0: 16.052 MB/s | TS:364028820 pkt:356283 o:0(+0) l:399(+3) dma:356283/356284(+1) swFIFO:0
[2025-09-29 16:44:52.816] [warning] lime: USB ep:83 Rx0: 15.950 MB/s | TS:368029260 pkt:360178 o:0(+0) l:421(+22) dma:360178/360178(+0) swFIFO:0
[2025-09-29 16:44:53.816] [warning] lime: USB ep:83 Rx0: 15.802 MB/s | TS:372028680 pkt:364035 o:0(+0) l:468(+47) dma:364035/364036(+1) swFIFO:0
The load of the most engaged CPU is no more than 20%.
what is your host system? x86, Arm? Do you plug the device directly into the host, or are you using USB hub?
Is the LimeSDR Mini being recognized as USB 3.0 or USB 2.0 device?
if it would be recognized as USB 2.0 device, then the USB bandwidth would be limited to 40 MB/s half duplex. And also the bandwidth is shared with other USB devices on the same bus.
Also are you running in a virtual machine?
limeConfig --initialize --rxen=1 --txen=1 --rxlo=1e9 --txlo=1.1e9 --samplerate=56e6 --log=debug
limeTRX --log=debug
FPGA: StopStreaming
FPGA: StopWaveformPlayback
FPGA: ResetPacketCounters
FPGA: ResetTimestamp
USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:4, DMA_ReadSize:16384, link:I12, batchSizeInTime:97.1429us FS:55999999.000000, FIFO=10294*1360
SetOSThreadPriority: Failed to set priority(6), sched_prio(99), policy(2), ret(1)
RxSetup wait for Rx worker thread.
Rx worker thread ready.
FPGA: StartStreaming
Rx receive loop start.
Samples received: 16384
Samples received: 28016640
Loss: pkt:24225 exp: 0000000001f6b74f, got: 0000000001f6f1c0, diff: +14961, timeDiff:+267142ns
Loss: pkt:24229 exp: 0000000001f706ff, got: 0000000001f73180, diff: +10881, timeDiff:+194285ns
Loss: pkt:24233 exp: 0000000001f746c0, got: 0000000001f77690, diff: +12240, timeDiff:+218571ns
Loss: pkt:24237 exp: 0000000001f78bcf, got: 0000000001f79670, diff: +2721, timeDiff:+48571ns
Loss: pkt:24241 exp: 0000000001f7abaf, got: 0000000001f7b650, diff: +2721, timeDiff:+48571ns
Loss: pkt:24257 exp: 0000000001f80b50, got: 0000000001f8208f, diff: +5439, timeDiff:+97142ns
Loss: pkt:24261 exp: 0000000001f835cf, got: 0000000001f865a0, diff: +12241, timeDiff:+218571ns
Loss: pkt:24265 exp: 0000000001f87ae0, got: 0000000001f88ad0, diff: +4080, timeDiff:+72857ns
Loss: pkt:24269 exp: 0000000001f8a010, got: 0000000001f8b54f, diff: +5439, timeDiff:+97142ns
Loss: pkt:24273 exp: 0000000001f8ca8f, got: 0000000001f8f510, diff: +10881, timeDiff:+194285ns
...
USB ep:83 Rx0: 157.417 MB/s | TS:55995280 pkt:38428 o:0(+0) l:298(+298) dma:9607/9608(+1) swFIFO:0
Samples received: 52297728
Loss: pkt:42809 exp: 0000000003b15af0, got: 0000000003b16040, diff: +1360, timeDiff:+24285ns
Loss: pkt:42853 exp: 0000000003b24a00, got: 0000000003b24f50, diff: +1360, timeDiff:+24285ns
Loss: pkt:42877 exp: 0000000003b2ced0, got: 0000000003b2d420, diff: +1360, timeDiff:+24285ns
Loss: pkt:42881 exp: 0000000003b2e960, got: 0000000003b2eeaf, diff: +1359, timeDiff:+24285ns
Loss: pkt:42921 exp: 0000000003b3c330, got: 0000000003b3c880, diff: +1360, timeDiff:+24285ns
Loss: pkt:42945 exp: 0000000003b44800, got: 0000000003b452a0, diff: +2720, timeDiff:+48571ns
Loss: pkt:42949 exp: 0000000003b467e0, got: 0000000003b46d30, diff: +1360, timeDiff:+24285ns
Loss: pkt:42957 exp: 0000000003b497b0, got: 0000000003b49d00, diff: +1360, timeDiff:+24285ns
Loss: pkt:42965 exp: 0000000003b4c780, got: 0000000003b4ccd0, diff: +1360, timeDiff:+24285ns
Loss: pkt:42981 exp: 0000000003b521d0, got: 0000000003b531c0, diff: +4080, timeDiff:+72857ns
Loss: pkt:42989 exp: 0000000003b55c40, got: 0000000003b566e0, diff: +2720, timeDiff:+48571ns
Loss: pkt:42997 exp: 0000000003b59160, got: 0000000003b5a14f, diff: +4079, timeDiff:+72857ns
Loss: pkt:43005 exp: 0000000003b5cbd0, got: 0000000003b5d670, diff: +2720, timeDiff:+48571ns
Loss: pkt:43013 exp: 0000000003b600f0, got: 0000000003b60640, diff: +1360, timeDiff:+24285ns
Loss: pkt:43017 exp: 0000000003b61b80, got: 0000000003b620d0, diff: +1360, timeDiff:+24285ns
Loss: pkt:43021 exp: 0000000003b63610, got: 0000000003b63b60, diff: +1360, timeDiff:+24285ns
Loss: pkt:43025 exp: 0000000003b650a0, got: 0000000003b655f0, diff: +1360, timeDiff:+24285ns
Loss: pkt:43033 exp: 0000000003b68070, got: 0000000003b685c0, diff: +1360, timeDiff:+24285ns
Loss: pkt:43037 exp: 0000000003b69b00, got: 0000000003b6a050, diff: +1360, timeDiff:+24285ns
Loss: pkt:43049 exp: 0000000003b6e010, got: 0000000003b6e560, diff: +1360, timeDiff:+24285ns
Loss: pkt:43061 exp: 0000000003b72520, got: 0000000003b72a70, diff: +1360, timeDiff:+24285ns
Loss: pkt:43069 exp: 0000000003b754f0, got: 0000000003b75a40, diff: +1360, timeDiff:+24285ns
Loss: pkt:43081 exp: 0000000003b79a00, got: 0000000003b79f50, diff: +1360, timeDiff:+24285ns
^CTRXLooper::Stop()
TRXLooper: wait for Rx loop end.
Rx receive loop end.
Rx0 stop: packetsIn: 47640
FPGA: StopStreaming
FPGA: ResetPacketCounters
FPGA: ResetTimestamp
RxTeardown wait for Rx worker shutdown.
Rx worker thread shutdown.
DeviceRegistry Removed: FTDI
DeviceRegistry Removed: FX3
I tried also with sudo:
sudo -E /home/roland/.local/bin/limeTRX --log=debug
FPGA: StopStreaming
FPGA: StopWaveformPlayback
FPGA: ResetPacketCounters
FPGA: ResetTimestamp
USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:4, DMA_ReadSize:16384, link:I12, batchSizeInTime:97.1429us FS:55999999.000000, FIFO=10294*1360
Rx worker thread ready.
RxSetup wait for Rx worker thread.
FPGA: StartStreaming
Rx receive loop start.
Samples received: 16384
Loss: pkt:5833 exp: 0000000000790bd0, got: 0000000000792bb0, diff: +8160, timeDiff:+145714ns
Loss: pkt:5841 exp: 0000000000795630, got: 00000000007980af, diff: +10879, timeDiff:+194285ns
Loss: pkt:5845 exp: 00000000007995ef, got: 000000000079b5cf, diff: +8160, timeDiff:+145714ns
Loss: pkt:5849 exp: 000000000079cb0f, got: 000000000079fae0, diff: +12241, timeDiff:+218571ns
Loss: pkt:5853 exp: 00000000007a1020, got: 00000000007a3aa0, diff: +10880, timeDiff:+194285ns
Loss: pkt:5901 exp: 00000000007b399f, got: 00000000007b5430, diff: +6801, timeDiff:+121428ns
Loss: pkt:5905 exp: 00000000007b6970, got: 00000000007b993f, diff: +12239, timeDiff:+218571ns
Loss: pkt:5909 exp: 00000000007bae7f, got: 00000000007bd3b0, diff: +9521, timeDiff:+170000ns
Loss: pkt:5913 exp: 00000000007be8f0, got: 00000000007c0380, diff: +6800, timeDiff:+121428ns
Loss: pkt:5917 exp: 00000000007c18bf, got: 00000000007c3350, diff: +6801, timeDiff:+121428ns
Loss: pkt:5921 exp: 00000000007c4890, got: 00000000007c5880, diff: +4080, timeDiff:+72857ns
...
Loss: pkt:7853 exp: 0000000000cb3950, got: 0000000000cb53e0, diff: +6800, timeDiff:+121428ns
Loss: pkt:7857 exp: 0000000000cb6920, got: 0000000000cb7910, diff: +4080, timeDiff:+72857ns
Samples received: 25378816
^CTRXLooper::Stop()
TRXLooper: wait for Rx loop end.
Rx receive loop end.
Rx0 stop: packetsIn: 27928
FPGA: StopStreaming
FPGA: ResetPacketCounters
FPGA: ResetTimestamp
RxTeardown wait for Rx worker shutdown.
Rx worker thread shutdown.
DeviceRegistry Removed: FTDI
DeviceRegistry Removed: FX3
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 06cb:0078 Synaptics, Inc.
Bus 001 Device 003: ID 12d1:15bb Huawei Technologies Co., Ltd. ME936 LTE/HSDPA+ 4G modem
Bus 001 Device 006: ID 04f2:b5a7 Chicony Electronics Co., Ltd Chicony USB 2.0 Camera
Bus 001 Device 007: ID 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
Bus 001 Device 008: ID 076b:5022 OmniKey AG CardMan 5022
Bus 001 Device 010: ID 056a:0357 Wacom Co., Ltd PTH-660 [Intuos Pro (M)]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 0403:601f Future Technology Devices International, Ltd FT601 32-bit FIFO IC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
lsusb --tree
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 002: Dev 002, If 0, Class=Vendor Specific Class, Driver=[none], 12M
|__ Port 003: Dev 003, If 0, Class=Communications, Driver=cdc_mbim, 480M
|__ Port 003: Dev 003, If 1, Class=CDC Data, Driver=cdc_mbim, 480M
|__ Port 003: Dev 003, If 2, Class=Vendor Specific Class, Driver=usbserial_generic, 480M
|__ Port 004: Dev 008, If 0, Class=Chip/SmartCard, Driver=usbfs, 12M
|__ Port 005: Dev 010, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 005: Dev 010, If 1, Class=Vendor Specific Class, Driver=[none], 12M
|__ Port 005: Dev 010, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 005: Dev 010, If 3, Class=Mass Storage, Driver=usb-storage, 12M
|__ Port 010: Dev 006, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 010: Dev 006, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 011: Dev 007, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 011: Dev 007, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 5000M
|__ Port 001: Dev 003, If 0, Class=Vendor Specific Class, Driver=[none], 5000M
|__ Port 001: Dev 003, If 1, Class=Vendor Specific Class, Driver=[none], 5000M
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 001: Dev 002, If 1, Class=Human Interface Device, Driver=usbhid, 12M
/: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
I tried this also with a sample rate of 4 Msps, with similar result.
I finally found the root of the problems on my machine: LimeSuiteNG choose a very low batch size, amounting to
mRx.packetsToBatch == 1
causing packet losses. As a “work around” I manually force the extra config to
strcfg.extraConfig.rx.packetsInBatch = 8;
This results in smooth operation with very low CPU utilisation and no data losses. (Tested with 4Msps over a period of 10 minutes, while doing email and internet surfing and no escalated privileges, i.e. as a normal user.)
I also tried with lower values, (e.g. 5) but then USB bulk errors started to be thrown which made it hard to even abort my test program.
I do understand that a higher value will increase latency, but possibly 100usec is a bit too optimistic. In my case the 8 packets are an equivalent of approx 3ms.
Interesting, thank you for the info.
100usec was chosen arbitrarily, because same logic has to deal with different devices whose sampling rates vary up to 122.88Msps and I haven’t observed any issues with the USB transactions when transfering one packet at a time with such low samle rates. Perhaps I’ll have to adjust the default latency for USB devices.
Could you try using sample rate of 15Msps, and strcfg.extraConfig.rx.packetsInBatch = 16;
Also you should be able to see now with the limeDevice what is the USB connectivity version is:
limeDevice
Found 1 device(s) :
0: LimeSDR Mini, media=USB3.0, addr=0403:601f
If I remember correctly 5G applications require that the latency would be <2ms realtime, subtracting the time necessary for processing data leaves even less time, so 100us data transfers were chosen based on that.
packetsInBatch = 16
runs fine with 15Msps without root privileges.
By becoming root I was able to increase to 40Msps, still running fine.
Yes, I tried the new feature, and as expected do see that the lime mini is correctly reported as USB3.0 device.