How to Prevent B210 USB Overflows

[Pavel]

Short answer: B210 overflows occur when the USB or host-processing path cannot consume receive samples continuously. Start with fewer channels and a lower rate, prove the USB 3 controller, then increase load while watching UHD overflow indicators.

Before you start​

• Use UHD discovery and probe utilities before GNU Radio, OpenAirInterface or srsRAN. Save the exact UHD version, FPGA image and device arguments.
• Match the host interface to the requested stream: USB-controller limits matter for B-series radios, while N- and X-series radios require a planned Ethernet path.

Step-by-step method​

1. Step 1: Run a UHD receive-to-null benchmark before GNU Radio. Test one channel at a conservative rate, record stability, then add rate and channels one change at a time.
2. Step 2: Use a direct USB 3 port and short verified cable. Inspect controller topology and move storage, cameras and other SDRs away from the controller used by B210.
3. Step 3: Set a master clock rate compatible with requested sample rates and avoid unnecessary format conversion or GUI sinks. Monitor per-core CPU load and thermal throttling.
4. Step 4: If recording, benchmark the target disk separately and use bounded buffering. Larger buffers absorb scheduling jitter but cannot replace missing sustained throughput.

Concrete example​

If one channel at 10 MSPS is stable but two channels overflow, test two at 5 MSPS, disable recording and compare a second controller. This separates aggregate USB load from application DSP and storage bottlenecks.

How to judge the result​

The configuration is validated by a sustained test at the exact channel count and sample rate with no unaccounted gaps and no persistent O indicators in UHD.

What to record​

• Monitor overflow or underflow indicators during a sustained test, not only during application startup.
• Clock and PPS solve different problems: 10 MHz supplies a frequency reference, while PPS supplies a time-alignment event.
• For coherent work, verify phase behavior and timestamp alignment with a known shared signal rather than only checking that two channels display data.

Common mistakes​

• Changing several hardware, software or RF variables at once, which removes the controlled comparison needed to identify the cause.
• Treating one autoscaled screenshot or one unusually good result as proof without recording the settings and repeating the test.
• Assuming USB 3 branding guarantees a dedicated high-performance controller ignores shared buses, cables, power and host scheduling.

Final check​

Reboot the host and power-cycle the radio, then repeat discovery, probe and the sustained stream. Keep the exact UHD, firmware and FPGA versions with the working result.