[UHD/USRP] Crashing when high sample rate waterfall

[XavierTolza]

trafficstars

Hi everyone. I'm experiencing issues when trying to run a very simple UHD script:

local radio = require('radio')

local source = radio.UHDSource("device=b210",868e6,250e3)
local sink = radio.GnuplotWaterfallSink()

local top = radio.CompositeBlock()
top:connect(source, 'out', sink, 'in')
top:run()

Lua radio cannot follow the 250e3 Hz sample rate, which is quite low and I get a crash with the following error after one second only:

O[UHDSource] Block runtime error: [string "radio.blocks.sources.uhd"]:0: uhd_rx_streamer_recv(): UHD_RX_METADATA_ERROR_CODE_OVERFLOW
stack traceback:
	[C]: in function 'error'
	[string "radio.blocks.sources.uhd"]: in function 'process'
	[string "radio.core.block"]: in function 'run'
	[string "radio.core.composite"]: in function <[string "radio.core.composite"]:0>
	[C]: in function 'xpcall'
	[string "radio.core.composite"]: in function 'start'
	[string "radio.core.composite"]: in function 'run'
	/tmp/luaradio/examples/uhd.lua:8: in main chunk
	[C]: in function 'dofile'
	/usr/local/bin/luaradio:105: in main chunk
	[C]: at 0x5569fe0e51d0

I am using an USRP b210 connected on USB3.0, luaradio 0.5.0 compiled from the devel branch of github (master branch did the same), liquid-dsp and volk both installed as shown by the output of luaradio --platform:

$ luaradio --platform
luajit          LuaJIT 2.1.0-beta3
os              Linux
arch            x64
page size       4096
cpu count       4
cpu model       Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
features
    fftw3f      true
    volk        true
    liquid      true

I could find any documentation or issue on throughput using UHD. Is it normal that it crashed? Prabably due to the waterfall sink?

Thanks!

[vsergeev]

I was able to reproduce your example with a USRP B200mini. The problem does appear to be the GnuplotWaterfallSink. The most I'm able to put through it is 50 kHz, after a decimator:

radio.CompositeBlock():connect(
    radio.UHDSource("device=b200",868e6,250e3),
    radio.DecimatorBlock(5),
    radio.GnuplotWaterfallSink()
):run()

The sink appears to run under other sources (e.g. RtlSdrSource, SignalSource) at higher sample rates, but I suspect there is some intermittent buffering involved and the UHDSource is much less forgiving on sample deadlines. Perhaps there is some way of tuning this with the UHDSource, but it would require some investigation on the current amount of backpressure.

Long term plan is definitely to migrate to a more performant plotting solution.