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

SDRA-2026

** apologies for cross-posting **

Call for Contributions: SDRA-2026 Online and Friedrichshafen

HAMRADIO Friedrichshafen Software Defined Radio Academy 2026 (SDRA-2026)

Date: Friday 26.06.2026, Saturday 27.06.2026

Conference Websites:

• https://www.hamradio-friedrichshafen.de
• https://2026.sdra.io

SDRA-2026 invites radio amateurs and researchers from acadaemia and industry to submit papers for oral and poster presentations on recent research that addresses theoretical aspects, algorithms, applications, hardware and software architectures for applied Software Defined Radio systems and resources and other aspects of SDR, as well as survey and discussion papers. The invitation particularly addresses open source research and projects. We also particularly invite specialists giving introductory talks and tutorials on SDR technologies.

Ulrich L Rohde Award

The Ulrich L Rohde Award was created in 2022 and shall be granted for innovative research in the field of Software Defined Radio. It is a paper award, which requires a written submission by applicants. There is a first, second and third place being awarded with the amount of 500, 300 and 100 Euro.

All submitted papers are eligible for the award.

Award Committee:

• Prof. Dr. Michael Hartje, HS Bremen, DK5HH
• Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM
• Prof. Dr. Hervé Boeglen, Univ. Poitiers, F4JET (European GNURadio Days)
• Prof. Dr. Jean-Michel Friedt, FEMTO-ST, Univ. Besancon (European GNURadio Days)

SDRA Topics:

• Advances in GNURadio related projects and research
• Algorithms, applications, architectures in SDR systems
• Real Time signal processing
• Innovative applications using modern ADC/DAC environments

Submission Information

How to submit: Please send an abstract of approximately 250 words to:

sdra@darc.de

Please include the following information:

• Paper title
• Author's name (and callsign). Names and callsigns of all authors if multiple authors.
• Author's affiliation
• Country
• Email address of the main author

All accepted papers will be published. Publication details will be available at a later point of time.

We ask authors to keep a limit of 6 pages. If there is a reason why the paper should be longer, please contact us.

We also solicit Posters and Demo papers: Poster/Demo papers describe a small focused result, a negative result, or a late-breaking result, or a description of a system that can be demonstrated on-site at the conference.

Papers should be formatted using the IEEE A4 templates: https://www.ieee.org/conferences_events/conferences/publishing/templates.html

Note that applications for the Ulrich L. Rohde Award must be submitted in form of a written paper.

Organization

• Prof. Dr. Michael Hartje, DK5HH
• Markus Heller, M.A., DL8RDS

Senior Programme Committee

• Prof. Dr. Michael Hartje, HS Bremen, DK5HH
• Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM
• Prof. Dr. Michael Mächtel, HTWG Konstanz, DL2SBS

Important Dates:

Please note that we welcome earlier recordings. The earlier you can submit and arrange the recording with our video team, the better.

• Abstract Submission: 15.05.2026
• Presentation Recording: 15.05.2026 - 15.06.2026
• PlayOut Date and Live Event: 26/27.06.2026

Contact

For enquiries and paper submission details please do not hesitate to contact us:

Email: sdra@darc.de Tel.: +49.173.3835315

Re: Does anyone have an automatic Audio IQ Balancer that works for multiple frequencies for GnuRadio?

Hi Rob! Interesting problem. To get the discussion flowing, and because I'm right now thinking out aloud, might as well write things down: I think these are the osmocom gr-iqbal blocks, right? Let's look at what "IQ Bal Optimize" does! It's my understanding [1] that what they do is take an FFT of signal, look every positive frequency j bin, conjugate-multiply it with the opposite negative frequency -j bin; sum up over all positive j. So, assume that the *signal* in the FFT's bin j and bin -j (or fft_size-j, but that's semantics) are uncorrelated. Let's say we observe the signal with an ideal signal chain, Then, the conjugate complex product FFT[j]*FFT'[-j] is 0 on expectation, by definition of "uncorrelated"¹. (Note: this means that one *must not* have a signal that's conj symmetric to f=0, or it would get detected as IQ imbalance!) If, however, there's IQ imbalance, then there's some component in FFT[-j] that contains a (weighted) mirror image of FFT[j], i.e., FFT[-j] = FFT[j]·b + actual_signal_fft[-j], with b being some complex factor. Thus, let us define a function with p as parameter, and the FFT-ed signal as input; here, the expectation operator E{…} is meant to be understood pretty empirically, "across all j": f_p(FFT) := E{FFT[j]·p·FFT'[-j]} = E{FFT[j]·FFT'[j]·p·b + p·FFT[j]·actual_signal_fft'[-j]} = E{|FFT[j]|²·p·b} + p·E{FFT[j]·actual_signal_fft'[-j} = p·b·E{|FFT[j]|²} + 0 What then happens is that a bit of convex optimization is thrown at this f_p(FFT) := p·E{FFT[j]·FFT'[-j]}. Since the signal energy |…|² is constant, the p that is conj(b) maximizes the function. Neat; don't overdo it on iterations on that optimization, because this is all noisy and you can't know how uncorrelated signal at opposite frequencies really is in this instant! Then, that optimization is repeated when there's new input that can be transformed, using the previous p as initialization. Thus, assuming signal fluctuates, and noise is uncorrelated, thus converging against a good estimate of the actual conj(b). Now, your problem is that there's not a single b for all bins, but a different b[j] for each bin j>=0. Huh! That suddenly looks a lot like a frequency-domain equalizer problem, doesn't it? In the presence of enough time (and the absence of intended, f=0-mirrored signals), there's, as far as I can tell, nothing wrong about using numerical optimization to optimize a whole parameter vector p[0…fft_len/2] instead of just a single complex p. You'd only need to understand the "E{…}" in the definion of f_p above as "across time" instead of "across bins". Does that give you a start on how to implement this? Now, you'll notice a peculiarity: What you do with that p is use its inverse to calculate the image of positive frequencies mirrored onto negative frequencies (didn't check, tbh), and subtract that. Huh! That's literally an equalizer. So, LMS equalizer methods, trained on the FFT[j]·FFT'[-j]_{j=0…fft_len/2} vector, should work, too, potentially even better. I bet *someone* has implemented that before, but I didn't find, on short notice, someone in the realm of GNU Radio that did so. Best regards, Marcus ——————————————————————————————————————————————————————————————————————————————————————— ¹ If you're not happy with me saying "by definition of": think about white noise. At any two frequency bins, you should be getting independent random complex numbers, zero mean; if the complex number is not zero mean (attention not magnitude-zero-mean!), then there'd be a "tone" at that frequency, not white noise. Now, multiply a complex number with the conjugate of another one: the result should be zero-mean, because from probability theory we know that E{X·Y} = E{X}·E{Y} if X,Y independent (and correlation is weaker than independence, but says E{X·Y} = 0). Our two variables have E{X}=E{Y}=0. [1] https://gitea.osmocom.org/sdr/libosmo-dsp/src/branch/master/src/iqbal.c#L168 On 2026-04-13 4:02 AM, Rob Frohne wrote: > Hi All, > > I want to help my students fix an annual problem we have because our QSD SDR hardware > designs can never get good enough image rejection.  I want to do that by adding a GnuRadio > flowgraph that uses some kind of LMS or other automatic algorithm (with more than two > parameters) to automatically balance the I and Q signals.  My students are designing QSD > SDR radios that downconvert HF signals to audio for a sound card to digitize often using a > Tayloe mixer.  I want something like this: > My problem with the above flowgraph is that it only optimizes the phase and amplitude at > one frequency.  I want it to optimize over the whole IF, so there are no glaring images in > our spectragrams.  I have seen a number of papers on doing this, but I'm looking for a > quick GnuRadio solution I can put between the soundcard and Quisk. Does anyone have > something like this we could try? > > Thanks, > > Rob > > -- > > Rob Frohne, PhD PE > > School of Engineering > > Walla Walla University > > 100 SW 4th St > > College Place, WA 99324 > > (509) 527-2075<http://voice.google.com/calls?a=nc,%2B15095272075> >

Does anyone have an automatic Audio IQ Balancer that works for multiple frequencies for GnuRadio?

Hi All,

I want to help my students fix an annual problem we have because our QSD SDR hardware designs can never get good enough image rejection.  I want to do that by adding a GnuRadio flowgraph that uses some kind of LMS or other automatic algorithm (with more than two parameters) to automatically balance the I and Q signals.  My students are designing QSD SDR radios that downconvert HF signals to audio for a sound card to digitize often using a Tayloe mixer.  I want something like this:  

My problem with the above flowgraph is that it only optimizes the phase and amplitude at one frequency.  I want it to optimize over the whole IF, so there are no glaring images in our spectragrams.  I have seen a number of papers on doing this, but I'm looking for a quick GnuRadio solution I can put between the soundcard and Quisk.  Does anyone have something like this we could try?

Thanks,

Rob

--

Rob Frohne, PhD PE

School of Engineering

Walla Walla University

100 SW 4th St

College Place, WA 99324

(509) 527-2075