Thanks — that context makes the problem clear. Below I’ll explain why your computer crashes, show the data-rate math with ASCII equations, and give straight, actionable fixes you can try right now.

---

Why it crashes (short)

Your USRP → host computer link is getting more data than the host can handle (USB, CPU, or disk I/O). With wide bandwidth you generate huge I/Q sample streams; at the sample format you’re using that becomes many MB/s and overwhelms the bus or the software buffers, causing failures after a few samples.

---

Data-rate math (ASCII)

Assume complex samples are encoded as either:

• complex64 (CF32) = two 32-bit floats = 32 + 32 = 64 bits = 8 bytes per complex sample
• complex16 (CS16 / SC16) = two 16-bit ints = 16 + 16 = 32 bits = 4 bytes per complex sample

Data rate (bytes/sec) = SampleRate * BytesPerSample * NumChannels

Examples:

1. If you use complex64 and single channel:

BytesPerSample = 8

SampleRate = 10e6  (10 MHz)

DataRate = 10e6 * 8 = 80e6 bytes/sec ≈ 80 MB/s

2. If you try to capture a 56 MHz bandwidth but only run at 10 MHz sample rate you still get the data at 10 MHz; but if you increase Fs toward 56 MHz it explodes:

At Fs = 56e6 with complex64:

DataRate = 56e6 * 8 = 448e6 bytes/sec ≈ 448 MB/s

3. Using complex16 at 10 MHz:

BytesPerSample = 4

DataRate = 10e6 * 4 = 40e6 bytes/sec ≈ 40 MB/s

4. Compare to typical bottlenecks:

USB2 theoretical max ≈ 480 Mbps ≈ 60 MB/s (practical less)

USB3 practical sustained ~ 300–500 MB/s (depends on controller, cable, CPU)

SSD write speed depends on drive (some > 500 MB/s; older HDD << 100 MB/s)

So: 80 MB/s (complex64 @ 10 MHz) will exceed many USB2 links and can overwhelm a slow disk or CPU. That explains the crash if the device is on USB2 or the host can’t keep up.

---

Practical fixes you can try (prioritised)

1. Use complex16 (16-bit I/Q) on the wire
   • That halves the data compared to complex64 (4 bytes/sample vs 8).
   • Data rate at 10 MHz → ~40 MB/s instead of ~80 MB/s.
   • In UHD/GNU Radio set the on-the-wire format (otw_format) to SC16/CS16 (often called sc16/cs16 or complex short) and the CPU format to the one you need (you can convert on the host to floats if needed).
2. Make sure the USRP is on a true USB3 port & good cable
   • Verify it is connected to a USB 3.0 controller (not a USB hub, not a USB2 port).
   • Use a short high-quality USB3 cable and a bus-powered port on the motherboard (avoid front-panel headers and hubs).
3. Drop the sample rate (what you already did)
   • If 2 MHz is stable, calculate the data rate at your chosen format and keep below the host limit. Example: complex64 @ 2 MHz = 16 MB/s; complex16 @ 2 MHz = 8 MB/s.
4. Reduce number of channels / turn off extra RX
   • If you were streaming both channels, stream only the one you need. 2 channels doubles data rate.
5. Increase host buffers / increase transfer sizes
   • Increase the number/size of UHD buffers (configure larger streaming buffers in UHD/GNU Radio). This reduces CPU chattiness and may help under bursts. (Look for set_max_output_buffer / streamer buffer parameters in your front-end).
6. Write to a fast disk or RAM first
   • If disk I/O is the bottleneck, write to a fast NVMe SSD or write into RAM (tmpfs) and flush later.
   • Avoid slow HDDs if you need high sustained throughput.
7. Use host-side decimation / FPGA decimation
   • If you only need a small portion of the 56 MHz, decimate (filter + downsample) so fewer samples are sent to host.
   • Some motherboards / drivers allow configuring decimation on the device; otherwise do it in the FPGA/driver or in GNU Radio with a polyphase decimator (but that still requires receiving the full stream unless done on-device).
8. Lower bit-depth or change formats earlier in the chain
   • If final processing can accept 8-bit or 12-bit samples, explore custom formats — but standard and simplest is SC16.
9. Check CPU load / multithreading
   • High sample rates require demultiplexing, streaming, and possibly conversion work. Ensure CPU/core usage isn’t saturated. Use real-time priorities for the capture threads if your OS allows it.
10. Capture bursts instead of continuous streaming
    • For some experiments, capture short bursts to disk and process offline instead of continuous real-time streaming.

---

Recommended concrete setup to test (step-by-step)

Try this sequence — stop when you reach a stable config:

1. Verify USB: plug USRP B210 straight into a motherboard USB3 port with a good cable.
2. Configure USRP stream to SC16 / complex16 (on-the-wire 16-bit complex).
   • In UHD this is often otw_format=sc16 (and cpu_format=fc32 if you want floats on the host) — if your front end allows selecting wire format pick complex16.
3. Set SampleRate = 10e6 (if you need it) and single RX channel.
4. Measure actual host throughput (use iotop, htop, or nload) while streaming. If stable, proceed; if not, drop SampleRate to 5e6 then 2e6.
5. If still unstable at desired Fs, increase the streaming buffers in your capture application / UHD settings and/or write to SSD or tmpfs.

---

Quick numeric example you can use to judge your system

Decide the maximum sustained bytes/sec you can handle:

• If your USB is actually USB2 (or slow controller): practical max ≈ 50 MB/s
• If you have USB3 + NVMe SSD and good CPU: you might sustain 300+ MB/s

Compute needed bytes/sec:

NeededBytesPerSec = SampleRate * BytesPerSample * NumChannels

If NeededBytesPerSec > your system limit → reduce SampleRate or BytesPerSample.

---

Final notes / troubleshooting checklist

• Confirm the USRP is on a USB3 port (if not, that’s the most likely cause).
• Switch wire format to complex16 (SC16) — large win.
• Try streaming single channel at your required Fs first.
• If you need full 56 MHz of instantaneous bandwidth, be prepared to stream very high data rates (hundreds of MB/s) — that requires a beefy machine and USB3 with a fast SSD and careful buffer tuning. Often it’s easier to decimate on-device or accept a smaller Fs.

---