A
Member
Hooking a USB SDR to a small ARM Linux board looks simple until the spectrum plot starts showing holes, the constellation tears, or the recorded IQ file is shorter than the wall-clock time. Those symptoms are easy to blame on the front end. On ARM SBCs they are just as often dropped USB isochronous packets, a starved userspace reader, or the CPU governor folding the big cores just as the sample rate goes up.
Check the transport first. dmesg and lsusb -t tell you whether the stick landed on a USB 2 or USB 3 controller and whether the kernel is resetting the device. A 10-bit or 12-bit frontend at tens of MS/s will overrun a USB 2 link or a poorly powered hub. ethtool does not help here; look at the SDR library’s overflow counters (UHD, SoapySDR, or the vendor API) while you raise the sample rate in steps. If overflows start at a sharp threshold and disappear when you move the same dongle to a desktop, the radio is probably fine.
Then look at the reader. A userspace process that does FFT, file I/O and TCP in the same thread will miss buffers even when USB is healthy. Separate capture from processing, pin the capture thread to a core that is not running the desktop or a browser, and keep the sample ring buffer large enough to cover filesystem jitter. If you write raw IQ to an SD card, the card’s periodic flush can stall the writer long enough to drop samples; a tmpfs or a real disk is a fairer test.
Finally check clocks and thermals. Some ARM boards source a noisy or stretched USB clock when they throttle. Watch scaling_cur_freq and the board temperature while you run a long capture. A five-minute recording that only fails after minute three is often thermal, not a bad mixer. Document the sample rate, USB path, overflow count and CPU frequency together — that set of numbers tells the next person whether to reach for a better cable, a better host controller, or a different radio.
Check the transport first. dmesg and lsusb -t tell you whether the stick landed on a USB 2 or USB 3 controller and whether the kernel is resetting the device. A 10-bit or 12-bit frontend at tens of MS/s will overrun a USB 2 link or a poorly powered hub. ethtool does not help here; look at the SDR library’s overflow counters (UHD, SoapySDR, or the vendor API) while you raise the sample rate in steps. If overflows start at a sharp threshold and disappear when you move the same dongle to a desktop, the radio is probably fine.
Then look at the reader. A userspace process that does FFT, file I/O and TCP in the same thread will miss buffers even when USB is healthy. Separate capture from processing, pin the capture thread to a core that is not running the desktop or a browser, and keep the sample ring buffer large enough to cover filesystem jitter. If you write raw IQ to an SD card, the card’s periodic flush can stall the writer long enough to drop samples; a tmpfs or a real disk is a fairer test.
Finally check clocks and thermals. Some ARM boards source a noisy or stretched USB clock when they throttle. Watch scaling_cur_freq and the board temperature while you run a long capture. A five-minute recording that only fails after minute three is often thermal, not a bad mixer. Document the sample rate, USB path, overflow count and CPU frequency together — that set of numbers tells the next person whether to reach for a better cable, a better host controller, or a different radio.
