search

pothosware / SoapyUHD

Soapy SDR plugins for UHD supported SDR devices
https://github.com/pothosware/SoapyUHD/wiki
GNU General Public License v3.0
54 stars 28 forks source link

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

Open alexFab opened 3 years ago

alexFab commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 isuhd::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.