1

For some reason, when a run the GNU Radio flow graph below, I get an overflow ('O'), an Underrun ('U') and late commands ('L') displayed on the console and, soon after, the execution of the signal path that includes the use of the USRP (Ettus B210) ends, freezing the output in the graphical sink.

Depending on the GRC configurations (like the sample rate, samp_rate = 240k works, sometimes) and eliminating other applications on the computer (basically just running GNU Radio) allows for it to actually continue to work. Below there is also the output log on the prompt. I would like to know what is the solution to this problem, an alternative to executing this, or, at least, a meg=thod for me to investigate what is going on.

Some info:

OS: Windows 10;

RAM Memory: 4 GB

CPU processor speed: 1.1 GHz

img_Console

img_Chart

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
Renato A. Schenkel
  • 11
  • 2
  • instead of a screenshot of a console, it's usually more helpful to copy and paste the text. Can't copy a string from a screenshot and look through the UHD source code with it... – Marcus Müller May 07 '21 at 15:53

1 Answers1

1

samp_rate = 240k works, sometimes

That sampling rate, however, is too slow to be useful: You'll see filter rolloffs with that. I'd recommend you use e.g. 1.2e6 as sampling rate and dive down if you need a lower rate.

I get an overflow ('O'), an Underrun ('U') and late commands ('L') displayed on the console

Which means your PC is too slow at getting data from the USRP (O) and to it (U).

At such low sampling rates, this is extremely rare, unless you have an extremely anemic computer.

CPU processor speed: 1.1 GHz

Oh. Yeah, this might really the problem here: this was a slow PC, 18 years ago.
I'm a bit surprised you got Win10 installed on that...

In all honesty, this might really be all there is to it: your CPU is incredibly old and slow, and it just can't keep up with millions of samples per second to be processed. Try with a newer CPU: your USRP costs a multiple of what a PC costs that's faster than that (in fact, I've got 25€ single-board computers that are faster).

Notes on your disabled blocks:

  1. NEVER use Throttle with a hardware (USRP) block in the same flow graph. Your GRC will by the way warn you about that when you generate the flow graph if it has a USRP and a Throttle in it
  2. "Probe Signal" is practically never a block that you'd want to use – it's really just useful if you casually, randomly want to look at a sample every once in a while without any determinism. You probably want to do something else.
Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • Much appreciated for the answer Mr. Müller. I was starting to suspect this possibility but you confirmed it. I will find a better CPU processor and take notes for future questions then. Have a nice day Mr. Müller. – Renato A. Schenkel May 08 '21 at 15:31
  • By the way, do you have any idea of why does the execution of the program stops after the overflow? It seems to be just the path that has some connection with the USRP that stops. – Renato A. Schenkel May 11 '21 at 13:27