There isn’t a single “safe” set of parameters for the USRP B210 that guarantees no crashes (it depends a lot on your host PC, USB link, FPGA image, and what you’re doing), but there are common patterns and combinations that are known to be more stable. Below are key parameters and trade-offs, plus what users typically find works without causing underflows/overflows or crashes.

---

Key Parameters That Matter for Stability on B210

1. Sample Rate (SR)
2. Master Clock Rate (MCR)
3. Number of Frames / Buffering (num_recv_frames, recv_frame_size)
4. Gain Settings
5. USB Bus Performance
6. Operating Mode (single- vs dual-channel)

---

Known Good / Stable Combinations & Guidelines

Here are some combinations / guidelines that people use to avoid crashes or streaming issues:

1. Master Clock Rate vs Sample Rate
   • The B210 has a configurable master clock rate. According to the UHD manual, you can set the master clock rate in a fairly wide range. (in.mathworks.com)
   • In practice, some users recommend aligning your sample rate with the master clock rate so that the FPGA doesn’t have to do fractional resampling. For example, if you set MCR = 32 MHz and SR = 32 Msps, that can be a “clean” combination. (usrp-users.ettus.narkive.com)
   • If you pick a sample rate that isn’t a simple fraction of the master clock, UHD / FPGA may quantize or round, which can lead to unexpected behavior or warnings. (usrp-users.ettus.narkive.com)
2. Buffer / Frame Settings
   • Increase num_recv_frames. On B200/B210, the USB streaming buffer is critical; by default the number of frames might be too low for high data rates. (usrp-users.ettus.narkive.com)
   • The UHD manual explicitly suggests adjusting recv_frame_size if you see performance issues. For example, setting recv_frame_size=1024 in the device args may help. (files.ettus.com)
   • Larger buffers help absorb jitter or occasional scheduling delays on the host.
3. Sample Rate Limits
   • Many users report trouble (overruns, USB errors) when going above ~28–30 Msps in dual-channel mode. (lists.ettus.com)
   • For very high sample rates, the host must sustain a very high data throughput over USB 3; if the host or USB subsystem can’t keep up, you’ll get overflows (“O”) or even crashes.
4. USB Connection
   • Make sure your B210 is connected over USB 3.0 (not USB 2). Some crashes / instability come purely from insufficient bus bandwidth. (lists.ettus.com)
   • On the host side, tune VM / OS parameters (e.g., Linux vm.swappiness or dirty writeback settings) if you’re writing to disk. In one thread, changing these helped avoid buffer stalls that caused overflows. (usrp-users.ettus.narkive.com)
5. Gain / Processing Load
   • Very high gain can saturate the front-end, but in terms of crashes it’s more often host-side processing that is too slow.
   • If you’re doing a lot of DSP (filtering, GUI sinks, resampling) in your flowgraph, try reducing sample rate or offloading heavy processing, so that your host doesn’t become the bottleneck.
6. Single vs Dual Channel
   • In single-channel mode, you can generally push sample rates higher than in dual-channel.
   • In dual-channel mode, because you’re streaming twice as much data, the USB and host must handle more, which increases the risk of overruns.

---

Example “Safe-ish” Parameter Sets (for Typical Use)

Here are a few example combinations that users have used with good stability:

Use-case	Master Clock Rate	Sample Rate	Buffer / Frames	Notes
Moderate RX (single-channel)	32 MHz	20–28 Msps	num_recv_frames = 256–512 / recv_frame_size = 1024	Good for high-throughput receive when host is reasonably powerful.
Dual-channel RX	32 MHz	~28 Msps (or less)	large frame buffer	Avoid pushing beyond ~30 Msps in dual mode.
TX + RX	30–40 MHz MCR (depending)	Match SR to MCR / sub-multiple	buffer tuning as above	Aligning SR & MCR helps simplify FPGA resampling.
Low-rate / non-critical	lower SR (e.g., < 10 Msps)	buffer minimal	–	Easier on USB, host, and more robust against overflows.

---

Pitfalls That Can Lead to Crashes / Overruns

• Using too high a sample rate relative to what your USB bus / host can sustain → buffer overflows / underflows.
• Not having enough frames / buffer space (num_recv_frames too low).
• Mis-configured master clock rate leading to unsupported sample rates.
• Using USB 2.0 or a bad / slow USB cable, which throttles your throughput.
• Host disk I/O being too slow (if writing to disk), so data can’t be flushed in time.
• Using very aggressive DSP / GUI blocks in the flowgraph, overloading the CPU.

---

My Recommendations Based on Crashing Risk

1. Start Conservatively: Use a moderate sample rate (e.g., 20 Msps), set MCR to a clean number (like 32 MHz), and up your num_recv_frames.
2. Benchmark: Run benchmark_rate (part of UHD) to test what your host + USB + disk system can handle.
3. Tune Buffers: Adjust recv frame size and number of frames until you minimize “O” or “U” in your logs.
4. Monitor Your System: While running, watch CPU, USB bus usage, disk throughput.
5. Incrementally Push: Once stable, try bumping up the sample rate or reducing buffers, but do it in small steps and watch for instability.

---

If you like, I can pull together a matrix of “stable parameter combinations” for B210 (based on more recent UHD versions, common host hardware, and real-world user data) — do you want me to do that?

Nice — I pulled together a practical, source-backed matrix of “stable” parameter combinations for the Ettus USRP B210, plus commands you can run, buffer tuning tips, and a short troubleshooting checklist. I cite the most relevant Ettus/UHD docs and a few well-used community notes so you can verify and tweak for your machine.

---

Quick takeaways

• Always use USB 3.0 for high throughput — USB 2.0 is limited (~8 MS/s). (kb.ettus.com)
• The B210’s master clock rate is adjustable; for single-channel you can set up to ~61.44 MHz, but in dual-channel MIMO modes the practical max is lower (commonly 30.72 MHz recommended). Picking MCR values that make decimation/interpolation integer helps stability. (files.ettus.com)
• Increase UHD stream buffers (num_recv_frames, recv_frame_size) when pushing high rates or dual channels. Default frames are small (default num_recv_frames=32), and raising this reduces overruns. (files.ettus.com)
• Use benchmark_rate / uhd_usrp_probe to test what your host+USB can actually sustain. Example benchmarks commonly show ~26–61 Msps depending on host/USB 3.0. (doc.ilabt.imec.be)

---

Stable parameter matrix (practical starting points)

Notes: “Msps” = mega samples per second. recv_frame_size numeric values are typical; experiment if your host differs. These are starting combinations that many users find stable.

Low-spec laptop (integrated USB controller, limited CPU/disk)

• Channels: Single RX (channel 0)
• Sample rate: 2–8 Msps
• Master clock rate: 16e6 (16 MHz) — lower MCR reduces resampling burden.
• UHD device args: type=b200,recv_frame_size=1024,num_recv_frames=64
• Why: keeps USB load and CPU low; USB 2.0 fallback will restrict rates to ~8 Msps. (kb.ettus.com)

Mid-range desktop (USB 3.0, good CPU, SSD)

• Channels: Single RX or Dual RX (if writing to RAM / fast disk)
• Sample rate: 20–28 Msps (single), <= 28–30 Msps (dual)
• Master clock rate: 32e6 (32 MHz) or 61.44e6 if you need larger integer ratios (pick MCR to make interpolation integer).
• UHD device args: type=b200,recv_frame_size=4096,num_recv_frames=128
• Why: With USB 3.0 and decent CPU, you can approach mid/high rates; dual channel doubles throughput so keep SR ≤ ~30 Msps to avoid USB/host bottleneck. (kb.ettus.com)

High-end workstation (NVMe, dedicated USB 3 host controller)

• Channels: Dual RX / TX+RX supported more reliably
• Sample rate: 30–61.44 Msps (single), ~30 Msps practical (dual) — pushing toward 61.44 Msps is possible but depends on the host and UHD version.
• Master clock rate: 61.44e6 (if you need integer decimation to common sample rates such as 30.72e6)
• UHD device args: type=b200,recv_frame_size=8192,num_recv_frames=256
• Why: High I/O and a dedicated, modern USB 3 controller can sustain the B210’s top rates in single channel; dual-channel often requires lowering SR or using very large buffers. (doc.ilabt.imec.be)

---

Commands & examples

1. Probe device and check USB mode

uhd_usrp_probe
# look for "Operating over USB 3"

(If it reports USB 2, move to a USB3 port or different host controller.) (sdrstore.eu)

2. Run benchmark_rate

# example (adjust args to your desired rates)
benchmark_rate --args="type=b200,master_clock_rate=61.44e6" --rx_rate 30.72e6 --duration 15

This reports what your host+USB sustain rate is for RX/TX. (doc.ilabt.imec.be)

3. Example UHD device args (GNU Radio / Python)

• In GNU Radio USRP Source device arguments:

type=b200,recv_frame_size=4096,num_recv_frames=128,master_clock_rate=32e6

• In Python (pyuhd / UHD args):

dev = uhd.usrp.MultiUSRP("type=b200,recv_frame_size=4096,num_recv_frames=128,master_clock_rate=32e6")

Adjust numbers to suit your host. (files.ettus.com)

---

Buffer tuning tips (reduce overruns / crashes)

• Raise num_recv_frames above default (32 → 128 or 256) when streaming high rates or dual channels. This increases host buffer depth. (files.ettus.com)
• Increase recv_frame_size for fewer, larger transfers (e.g., 4096–8192) if your OS/USB controller accepts larger MTU. Some systems cap this at the USB transfer size; experiment. (files.ettus.com)
• If you see O/U (overrun/underrun) messages: smooth your pipeline (reduce GUI sinks, offload heavy DSP, write to RAM disk first). Monitor dmesg for USB errors. (files.ettus.com)

---

Practical troubleshooting checklist

1. Verify USB 3.0 (uhd_usrp_probe). If only USB 2.0, expect ≤ ~8 Msps. (kb.ettus.com)
2. Run benchmark_rate to learn your host limits. (doc.ilabt.imec.be)
3. If using dual-channel, try the same parameters in single channel first — if that’s stable, double-check USB and increase buffers for dual. (files.ettus.com)
4. Increase num_recv_frames and recv_frame_size progressively; test for stability after each change. (files.ettus.com)
5. Reduce GUI sinks / heavy Python callbacks — these often create the CPU stalls that lead to overflows. Monitor top/htop.
6. If you must stream very high rates reliably, consider a dedicated host with a native USB 3.0 controller (not grouped with many devices) and fast disk (NVMe) or streaming directly to RAM first. (doc.ilabt.imec.be)

---