Hi,
I am writing to share some great news. The signal "stuttering" we discussed was actually just a display error in the GNU Radio Waterfall GUI. After analyzing the received data, I confirmed our physical signal transmission is perfectly continuous and successful.
Thank you all for your help!
Best regards,
Yunxi Chen
From: Yunxi Chen
Sent: 2026年4月30日, 星期四 15:14
To: 'Marcus D. Leech' <patchvonbraun@gmail.com>; discuss-gnuradio@gnu.org
Subject: RE: USRP B210 Dual-Channel 30.72 Msps: Underflows in GRC, but benchmark_rate works fine
Hi,
Thank you all very much for your detailed responses and suggestions.
I have carefully followed your advice. I confirmed that "Realtime Scheduling" is enabled in GNU Radio, and I verified that my files in /dev/shm easily fit in the RAM without any swapping to disk. I also experimented with the num_send_frames and other transport parameters mentioned in the Ettus manual. To completely rule out my laptop's specific USB controller as the bottleneck, I even switched to a completely different, high-performance host computer.
Unfortunately, the core issue still persists. While I am able to transmit without immediate crashing, I cannot maintain a continuous signal. As shown in the waterfall plot, the signal transmits solidly for about 4 to 5 seconds, followed by a complete drop-off for another 4 to 5 seconds, before resuming again.
Are there any other GNU Radio-specific buffer settings, or deeper UHD block parameters I could tweak to achieve a smooth, continuous transmission?
Thank you again for your time and help.
Best regards,
Yunxi Chen
-----Original Message-----
From: discuss-gnuradio-bounces+yunxi.chen=tum.de@gnu.org <discuss-gnuradio-bounces+yunxi.chen=tum.de@gnu.org> On Behalf Of Marcus D. Leech
Sent: 2026年4月25日, 星期六 0:28
To: discuss-gnuradio@gnu.org
Subject: Re: USRP B210 Dual-Channel 30.72 Msps: Underflows in GRC, but benchmark_rate works fine
On 2026-04-24 17:27, Marcus Müller wrote:
> Dear Yunxi Chen,
>
> UHD's benchmark rate doesn't try to read data from a file, copy it
> through buffers and put it on the line; it's really a lower CPU load
> problem than what you showed here. Still, what you want typically works.
>
> You would want to make sure you have enabled "realtime scheduling" in
> the "Options" (pseudo-)Block in GRC.
>
> Other than that, hah! I didn't realize that /dev/shm is still a thing
> :) nowadays, it's just a regular tmpfs mount, so make sure your two
> files actually fit fully in your RAM, and you're not "Swapping" RAM to
> disk. 2 files of 10 ms of 30.72 MSam/s with each sample being 8 B,
> that's 2 · 10·10⁻³ s · 30.72·10⁶ Sam/s · 8 B/Sam = 4915200 B = 4.7 MB,
> so that's probably not the problem, unless you have much other things
> in RAM. Check with `free -m` how many megabytes are currently "used"
> in "Swap".
>
> Best regards,
> Marcus
Gah! I should have paid more attention to the filenames.
Another parameter that can be tweaked in the device arguments, num_send_frames, is described here, and MIGHT help (or might not):
https://files.ettus.com/manual/page_transport.html
>
> On 2026-04-24 4:33 PM, Yunxi Chen wrote:
>> Hi,
>>
>> I am working on a 5G PRS localization project and encountering
>> persistent Underflow issues when attempting to transmit at 30.72 Msps
>> using both channels on a USRP B210.
>>
>> *The Setup:*
>>
>> * *Hardware:*USRP B210 connected via USB 3.0.
>> * *Host PC:*Dell G15 Laptop (13th Gen Intel(R) Core(TM) i7-13650HX
>> (20 cores), 64 GB RAM).
>> * *OS:*Ubuntu 22.04.
>> * *Software:*GNU Radio 3.10.7.0, UHD 4.1.0.5.
>>
>> *The Experiment:*I am transmitting a 5G PRS signal (mu=1, 30kHz SCS)
>> with a slot-level TDM pattern (alternating between Ant A and Ant B).
>> The frames are pre-calculated and zero- padded to exactly 307,200
>> samples (10ms @ 30.72 MHz) to ensure perfect timing alignment.
>>
>> *The Flowgraph:*
>>
>> *The Problem:*Despite these optimizations, I get immediate and
>> constant Underflows. However, when I run the official UHD benchmark
>> tool: |benchmark_rate --args="type=b200" -- channels="0,1" --tx_rate
>> 30.72e6 | It completes successfully without a single dropped packet.
>>
>> *My Questions:*Since |benchmark_rate| works, it seems the
>> hardware/USB controller is physically capable of this rate. Why does
>> the GNU Radio flowgraph fail even with a simple File Source -> USRP
>> Sink architecture? Are there specific buffer or scheduler tunings in
>> GRC that I am missing to handle 2x2 MIMO at the 30.72 Msps limit?
>>
>> Any advice or insights would be greatly appreciated.
>>
>> Best regards,
>>
>> Yunxi Chen
>>
>
>
