I have a LimeSDR Mini connected to a Raspberry Pi over USB 2.0 (unfortunately, I have no option to change it to USB 3.0). I’m trying to download data with the maximum available sampling rate, which I thought was limited by the USB bandwidth (480 Mbps/24 for 12-bit I and Q), so around 20 MSample/s. However, when I go above 9 MSps, I sometimes experience sample drops.
I’m using a FIFO size of 2^24 with the maximum throughput, so the throughputVsLatency is set to 1.
Hi, did you set stream linkFmt, it can be either 12bit, or 16bit. samples? The default is 16bit.
That’s theoretical limit of USB 2.0, it’s half duplex, and is shared among all devices on the same USB bus. So practically you won’t be able to get that much.
So depending on how many other devices are connected to the same bus and how much bandwidth they are using, I’d say you could expect up to ~40 MB/s.
Assuming Rx only 9Msps by default 16bit samples, that’s pretty much what’s you are getting 4*9e6 = 36 MB/s. Additionally the USB data transfer is handled by CPU, so if your CPU is being loaded 100%, then some USB transcations might not be handled fast enough, and data drops would happen.
Also not sure which Raspberry pi model you have, but some of them had a shared bus for USB and Ethernet ports, so in that case network activity can also decrease the USB bandwidth.
Hi, thank you for your response. Of course, the USB 2.0 limit is only theoretical, but I thought it could be approached more closely. I’ve configured the LimeSDR to use 12-bit link format. I’m using a Raspberry Pi 4, which supports USB 3.0 (on a shared PCIe bus), but the USB 2.0 ports are handled by a separate native controller, so I don’t believe the bottleneck comes from anything other than the overhead and limitations of USB 2.0’s half-duplex nature.
I ran trials with lower sampling rates (6–7 MHz), but I experienced 1–2 packet sample drops after a couple of minutes. I checked the FIFO fill ratio, which stayed around 1–2%, and there were no underruns, overruns, or any other obvious issues. Do you think the problem could be related to the USB connection? I’m forwarding the samples over ethernet—I don’t think this affects the Lime-Pi connection, but I can’t figure out what’s going wrong. What’s strange is that this same setup earlier handled 9 MSps without any issues.
If within a packet a singular sample is wrong, then it most likely be a clocking issue, which can appear if the board overheats. Considering that it manifest after couple of minutes, make sure that the board has adequate cooling.
I’ve checked the Lime temperature, which is below 40 °C, and the Raspberry Pi is under 50 °C, but Lime is still dropping. I also verified that the Pi’s CPU frequency remains at 1.5 GHz. This is expected, as the Pi has a soft thermal limit at 60 °C, where the frequency is decreased if the temperature exceeds that threshold.
