Soapy overflow::SoapySDR::Device::readStream timeout!

[alexFab]

Describe the bug
if use SoapyUHD for openwebrx. works fine for few minutes, than
data stream stops. i opened a issue at openwebrx but it seems to be more of a problem with soapy.

SDR-Hardware
USRP B210

To Reproduce
It happens after 10 - 60 min. At a sample rate of 4Msps and much earlier using 8Msps .

Installation method

• i7, 16GB ram
• Ubuntu 19.10
• everything freshly complied from Source.
  • https://github.com/pothosware/SoapySDR
  • https://github.com/pothosware/SoapyUHD
  • https://github.com/jketterl/owrx_connector

Versions
latest master branch

Log messages
WARNING: Soapy overflow
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!
WARNING: SoapySDR::Device::readStream timeout!

Additional context
I'm not sure where the error is coming from. SoapySDR? SoapyUHD? Or just some miss configuration?

thx a lot!

[guruofquality]

The print is probably in owrx_connector, but the B210 driver in UHD is probably returning uhd::rx_metadata_t::ERROR_CODE_TIMEOUT in stream->recv(): https://github.com/pothosware/SoapyUHD/blob/master/SoapyUHDDevice.cpp#L279

Now either there is a driver problem in B210, or the timeout is just really small and there are no more samples in the allotted time window - for the later, that may be an issue to tweak the timeout in owrx_connector

[alexFab]

thx for your quick reply. i check the timeout but 1e6ns aka 1ms doesn't seem to be that small. but i have no idea,.What do you mean by "realy small". I changed timeoutNs to 1e9ns aka 1 sec. after around 5min the stream breaks again, this time without the log message.

[jketterl]

The variable is named incorrectly, the API actually takes microseconds, so 1e6 should give a timeout of one second. The default for that parameter is 100000 (or 100ms).

[guruofquality]

Probably not the timeout

The USRP buffers samples into packets containing multiple samples. So its possible to have a very small timeout such that there will be not be enough time for a packet of samples to become buffered and available. On the extreme end, a timeout of 0 would also cause something like this. However it looks like the timeout is 1 second long...

Check the UHD library

So I think the issue is that B200 here or its driver in UHD is actually having a problem. You might try to reproduce the streaming issue in some other application with B200 or adding prints in the UHD driver. Again, the SoapyUHD code here is just a micro-thin wrapper on the UHD library, especially for the streaming.

Maybe the stream mode?

One other thought comes to mind is if somehow activateStream put the B200 in burst mode (where it requests a specified number of samples). That would mean that it times out sooner at higher samples rates: https://github.com/pothosware/SoapyUHD/blob/master/SoapyUHDDevice.cpp#L242

When stream->rx->issue_stream_cmd(cmd); is called make sure the mode is uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS;` If not, I guess we have a bisect point for this problem. But I do kind of suspect the UHD library being some kind of issue.