RE: USRP B210 Dual-Channel 30.72 Msps: Underflows in GRC, but benchmark_rate works fine

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

>>  

>  

>  

 

 

NEWSDR 2026 — June 4 & 5 — WPI in Worcester, Massachusetts, USA

The 16th annual New England Workshop on Software Defined Radio (NEWSDR) event will be held at Worcester Polytechnic Institute (WPI), in Worcester, Massachusetts, USA.  The event will take place on Friday June 5, and there will be evening tutorials on Thursday June 4.

Please see the event webpage for details.

https://newsdr.org/workshops/newsdr-2026/

Advance registration is free but required so that we can get a headcount.

https://forms.gle/VvUVnhZtBPZRsxsT6

We are looking for poster presentations! Please use the link below to submit a poster for the event:

https://forms.gle/hobTwXv5cKN8gxhK7

If you are interested in exhibiting or sponsoring the workshop, please email us at "gr-newsdr-info@wpi.edu".

We look forward to seeing you at the event!!

GRCon26 Call for Participation and Registration Info

We’re excited to announce that GNU Radio Conference 2026 (GRCon26) will take place September 21–24 in Raleigh, North Carolina, at the Talley Student Union. 

GRCon26 is generously hosted by NC State, which is home to one of the four NSF PAWR platforms, the AERPAW wireless research platform.

---

Call for Participation – Now Open

We invite you to submit talks, papers, workshops, tutorials, and demos for GRCon25. Whether you're advancing research, deploying SDR systems in the field, building open-source tools, or experimenting at home, we want to hear from you.

• Abstract submissions are due by June 13, 2026 - https://events.gnuradio.org/e/grcon26 

• We look forward to a broad range of topics to be submitted including SDR development, wireless systems, education, AI/ML, 5G/6G and beyond, radio astronomy, hardware integration, community projects, and more

---

Monday Workshop Day – A Great Place to Start

GRCon26 will kick off with a special Workshop Day on Monday, September 21, focused on a combination of of both beginner and advanced workshop topics

---

Registration Now Open

We’ve worked to make the conference as accessible as possible:

• Students: $100

• Student Presenters: Free

• Standard registration: $850

• Discounted registration for unaffiliated individuals: $400
  
  

Register Now - https://tickets.gnuradio.org/grcon26/ 

Registering early helps us plan and keeps costs as low as possible.  

---

Becoming a GRCon Sponsor

We invite your organization to consider sponsoring this year’s conference!

If your organization uses GNU Radio - or your customers do - sponsoring GRCon is a meaningful way to give back to the project and gain visibility in a passionate, highly technical community.

See our sponsorship packages or email us sponsor@gnuradio.org

---

GRCon is where the SDR community gathers - from industry professionals to academics to hobbyists. We look forward to learning from each other and celebrating the work being done across the GNU Radio ecosystem.

If you have any questions, always feel free to contact us at grcon@gnuradio.org.

See you in Raleigh,
The GRCon26 Organizing Team

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

>>  

>  

>  

 

 

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 >> > >

Re: USRP B210 Dual-Channel 30.72 Msps: Underflows in GRC, but benchmark_rate works fine

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 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 >

USRP B210 Dual-Channel 30.72 Msps: Underflows in GRC, but benchmark_rate works fine

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