SoapySDRUtil probe freeze RSP1

dropdrop20 commented 5 years ago

Running probe multiple times will eventually block the my RSP1. Environment is Raspberry PI3.

The only chance is to reboot the Raspberry.

Library mir: root@xxxxx~ # ls -l /usr/local/lib/libmirsdrapi-rsp.so.2.13 -rw-r--r-- 1 root staff 183188 Mar 15 11:00 /usr/local/lib/libmirsdrapi-rsp.so.2.13

root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay" ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay

-- Device identification

driver=SDRplay hardware=18070ED596 mir_sdr_api_version=2.130000 mir_sdr_hw_version=255

-- Peripheral summary

Channels: 1 Rx, 0 Tx Timestamps: NO Other Settings:

RF Gain Select - RF Gain Select [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)]
IF Mode - IF frequency in kHz [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
IQ Correction - IQ Correction Control [key=iqcorr_ctrl, default=true, type=bool]
AGC Setpoint - AGC Setpoint (dBfs) [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
BiasT Enable - BiasT Control [key=biasT_ctrl, default=true, type=bool]
RfNotch Enable - RF Notch Filter Control [key=rfnotch_ctrl, default=true, type=bool]
DabNotch Enable - DAB Notch Filter Control [key=dabnotch_ctrl, default=true, type=bool]

-- RX Channel 0

Full-duplex: YES Supports AGC: YES Stream formats: CS16, CF32 Native format: CS16 [full-scale=32767] Antennas: RX Corrections: DC removal Full gain range: [0, 48] dB IFGR gain range: [20, 59] dB RFGR gain range: [0, 9] dB Full freq range: [0.01, 2000] MHz RF freq range: [0.01, 2000] MHz CORR freq range: MHz Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

root@xxxxx~ # root@xxxxxx:~ # SoapySDRUtil --probe="driver=sdrplay" ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay Error probing device: map::at root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay" ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay

^C root@xxxx:~ #

guruofquality commented 5 years ago

Looks like one of those runs actually caused a crash before it got into this lock up state. FWIW, I didnt see this on my PC, so it might be something related to the driver on ARM specifically.

I know this is terribly annoying, but can you comment out the exception handling here: https://github.com/pothosware/SoapySDR/blob/master/apps/SoapySDRUtil.cpp#L192 and get a traceback from when it throws the first Error probing device: map::at?

Alternatively for the freeze up, throw in a tone of prints into SoapySDRPlay: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp and lets find out what mirics API call is locked up, that should help @SDRplay look at the problem closer.

dropdrop20 commented 5 years ago

I've open a support case to SDRPlay website. Changing Raspberry was a good option. From RPI3 to my old RPI2. Anyway the rtl_airband is still stopping after few minutes.

Which is not happpening with my 8 euro junk RTL-SDR. I'll do experiments and keep you informed. Indeed incredible anoying.

SoapySDR: device 'driver=sdrplay': using native sample format 'CS16' (fullScale=32767.0) RTLSDR-Airband version v3.0.1 starting SoapySDR: device 'driver=sdrplay': sample rate set to 3000000 sps SoapySDR: device 'driver=sdrplay': gain set to 25.0 dB SoapySDR: device 'driver=sdrplay' initialized [INFO] Using format CS16. SoapySDR: device 'driver=sdrplay' started Writing to /root/audio/fm146.2125_20190318_08.mp3 Writing to /root/audio/fm146.2250_20190318_08.mp3 Writing to /root/audio/fm146.2375_20190318_08.mp3 Writing to /root/audio/fm146.2000_20190318_08.mp3 Writing to /root/audio/fm146.1875_20190318_08.mp3 Writing to /root/audio/fm146.0250_20190318_08.mp3 Writing to /root/audio/fm146.0375_20190318_08.mp3 Writing to /root/audio/fm146.0500_20190318_08.mp3 Writing to /root/audio/fm146.0625_20190318_08.mp3 Writing to /root/audio/fm146.0750_20190318_08.mp3 Writing to /root/audio/fm146.0875_20190318_08.mp3 Writing to /root/audio/fm146.1000_20190318_08.mp3 Writing to /root/audio/fm146.1125_20190318_08.mp3 Writing to /root/audio/fm146.1250_20190318_08.mp3 Writing to /root/audio/fm146.2750_20190318_08.mp3 Writing to /root/audio/fm146.2875_20190318_08.mp3 Writing to /root/audio/fm146.1375_20190318_08.mp3 Writing to /root/audio/fm146.1750_20190318_08.mp3 Writing to /root/audio/fm146.2500_20190318_08.mp3 Writing to /root/audio/fm146.2625_20190318_08.mp3 Writing to /root/audio/fm146.0000_20190318_08.mp3 Writing to /root/audio/fm146.0125_20190318_08.mp3 Writing to /root/audio/fm146.1500_20190318_08.mp3 Writing to /root/audio/fm146.1625_20190318_08.mp3 OSoapySDR device 'driver=sdrplay': readStream failed: OVERFLOW, disabling All receivers failed, exiting Freeing GPU memory Cleaning up Input threads closed

jazzkutya commented 5 years ago

I know this is terribly annoying, but can you comment out the exception handling here: https://github.com/pothosware/SoapySDR/blob/master/apps/SoapySDRUtil.cpp#L192 and get a traceback from when it throws the first Error probing device: map::at?

Hi,

I don't have the freezes, and I am on x86-64 (ubuntu 14.04lts), but I also get "Error probing device: map::at". I always get this, not just ocassionally. I can't use SoapySDR due to this. Here is output with the try and whole catch block uncommented:

Probe device terminate called after throwing an instance of 'std::out_of_range' what(): map::at Aborted (core dumped)

despite what it says about a core dump, I do not have a core dump file because ubuntu. I will post it if I find it or succeed in producing it. How could I get a proper exception with stack traces and stuff?

jazzkutya commented 5 years ago

"Error probing device: map::at" happens when findSDRPlay() does not find any available devices, so this is probably just the side effect of the root problem. The freezing is probably also a side effect as it happens after the device is stuck in an unavailable state (according to the paste in OP).

guruofquality commented 5 years ago

Looks like we resolved the map at issue, it was no devices found, its reported better now. I guess any lock up has to be taken up with SDRPlay drivers. Thanks! Reopen if something comes up

pothosware / SoapySDRPlay2