search

pothosware / SoapySDR

Vendor and platform neutral SDR support library.
https://github.com/pothosware/SoapySDR/wiki
Boost Software License 1.0
1.13k stars 179 forks source link

SoapySDR layer unusable - WARNING: sync read failed - while rtl_tools work #232

Closed metssigadus closed 5 years ago

metssigadus commented 5 years ago

I really apologize if this is not the proper (related to my problem) module.

The background: I have had a working Soapy installation (read: not a complete novice). This week I reinstalled a known to work (from last year) set of utilities (Pothosware modules + OpenWebRX) onto Debian 10 (buster). SDR related packages are compiled fresh from git sources.

Symptoms:

  1. "SoapySDRUtil --find" works properly, all the SDRs (1 RTL-SDR, 2x SDRPlay) with their attributes are recognised (including remotely);
  2. "rtl_test" and rtl_fm work correctly. No errors with an RTL-SDR stick and rtl_tools;
  3. With Soapy tools, the command part works well (SDRs are visible, attributes are OK), but the streaming does never start. Errors are: "WARNING: sync read failed. -1" ; "Failed to activate stream". SoapyRemote server is working and able to transport the "sync read failed" errors to a remote Soapy host, and OpenWebRx (or to be more precise - rx_sdr) there reprints these.

Summary: Looks like some changes in how this mix of software interacts (access rights?). A year ago there was no comparable problem. I am not a developer. Any hint will be valuable about it, where to start dig deeper to find the issue. SDRPlay hardware is fully working (tested elsewhere).

Log excerpts: SoapySDRUtil --info [..] Lib Version: v0.8.0-gfe8dfd18 API Version: v0.8.0 ABI Version: v0.8 Install root: /usr/local Search path: /usr/local/lib/SoapySDR/modules0.8 Module found: /usr/local/lib/SoapySDR/modules0.8/libremoteSupport.so (0.5.2-6d9bd82) Module found: /usr/local/lib/SoapySDR/modules0.8/librtlsdrSupport.so (0.3.1-5c5d950) Module found: /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0-14ec39e) Available factories... remote, rtlsdr, sdrplay Available converters...

[..] Found Rafael Micro R820T tuner Found device 0 available = Yes driver = rtlsdr label = Generic RTL2832U OEM :: 01928374 manufacturer = Realtek product = RTL2838UHIDIR rtl = 0 serial = 01928374 tuner = Rafael Micro R820T Found device 1 driver = sdrplay label = SDRplay Dev0 RSP1A CENSORED serial = CENSORED

rtl_fm -f 107000000 -M 118M:137M:25k -s 12k -g 49.2 -l 280 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 01928374 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Tuner gain set to 49.60 dB. Tuned to 107252000 Hz. Oversampling input by: 84x. Oversampling output by: 1x. Buffer size: 8.13ms Exact sample rate is: 1008000.009613 Hz Sampling at 1008000 S/s. Output at 12000 Hz. ^CSignal caught, exiting! User cancel, exiting...

rx_sdr -d 0 - Found Rafael Micro R820T tuner Using device R820T: origin=https://github.com/pothosware/SoapyRTLSDR remote:version=0.5.2-g6d9bd820 rtl=0 Found 1 channel(s) : Channel 0 : Found 1 antenna(s): RX Found 1 gain(s): TUNER Found 2 frequencies: RF CORR Found 10 sample rates: 250000 1024000 1536000 1792000 1920000 2048000 2160000 2560000 2880000 3200000 Found 0 bandwidths: Using output format: CU8 (input format CS16, 4 bytes per element) Sampling at 2048000 S/s. Tuned to 100000000 Hz. Tuner gain semi-automatically set to 40 dB [INFO] SoapyRemote::setupRxStream(remoteFormat=CS8, localFormat=CS16, scaleFactor=128, mtu=1500, window=44040192) [INFO] Client side stream bound to 10.10.1.211:45328 [INFO] Client side status bound to 10.10.1.211:41525 [INFO] Using format CS8.

[INFO] Configured sender endpoint: dgram=1452 bytes, 714 elements @ 2 bytes, window=43008 KiB [INFO] Client side stream connected to 10.10.1.211:40236 [INFO] Configured receiver endpoint: dgram=1452 bytes, 714 elements @ 2 bytes, window=43008 KiB Reading samples in sync mode... WARNING: sync read failed. -1 WARNING: sync read failed. -1 WARNING: sync read failed. -1 WARNING: sync read failed. -1 ^CSignal caught, exiting! WARNING: sync read failed. -1 User cancel, exiting...

rx_sdr -d "driver=sdrplay" - Using device RSP1A: mir_sdr_api_version=2.130000 mir_sdr_hw_version=255 serial=CENSORED Found 1 channel(s) : Channel 0 : Found 1 antenna(s): RX Found 2 gain(s): IFGR RFGR Found 2 frequencies: RF CORR Found 13 sample rates: 250000 500000 1000000 2000000 2048000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000 Found 8 bandwidths: 200000 300000 600000 1536000 5000000 6000000 7000000 8000000 Using output format: CU8 (input format CS16, 4 bytes per element) Sampling at 2048000 S/s. Tuned to 100000000 Hz. [INFO] Using format CS16. Reading samples in sync mode... Failed to activate stream

guruofquality commented 5 years ago

It could be an ABI incompatibility issue. Make sure that you didnt have multiple copies of the development headers in /usr/local/include and /usr/include (from the package manager). Or more than one copy of runtime libs like in /usr/lib/yourarch/libSoapySDR.so and /usr/local/lib/libSoapySDR

Does the rate tester work in SoapySDRUtil --rate=1e6 --direction=RX --args="your device args"?

metssigadus commented 5 years ago

Really thanks for the hint. As I understand, ABI compatibility is a PhD / chief architect level science. Hopefully fresh Debians and Ubuntus do not contain ABI defects ex-works (otherwise no hope to debug it all). My thoughts: regarding Soapy and these SDRPlay related tools it is much easier, I myself compile these, one after another, in a certain order, b/c they are dependant (see https://github.com/metssigadus/air/tree/master/Ansible). I install the machine from scratch using some naive Ansible playbooks, thus absolutely no remnants from the previous installations. And indeed, I can check dual lib artefacts after each compilation. I will. An alternative I am currently thinking on, is to change the HEADs of git sources to 2018-06-01, this is a known date when things were working with Ubuntu 19.04 LTS server and SDRplay_RSP_API-Linux-2.11.1. I'll give a feedback if either strategy works. There yet is a middle-of-the-road strategy to leave SDRPlay devices off the game and to debug the issue for RTL-SDR as an industry standard.

zuckschwerdt commented 5 years ago

The SoapySDRPlay module was developed with the June 2018 (still current) SDRplay hardware drivers on soapy-sdr-0.7.1. IIRC I also tested on 0.8. Is this specific to SDRplay? Does driver=rtlsdr work?

metssigadus commented 5 years ago

In an essence, rtlsdr and sdrplay fail a little bit differently. rx_sdr -d "driver=sdrplay" - says it very straight - "Failed to activate stream". And ends. rx_sdr -d 0 - tries to sync endlessly but never succeeds (until user cancel). Haven't commanded rx_sdr -d "driver=rtlsdr", did it via -d 0 . According to "SoapySDRUtil --find", it shouldn't be any difference, or should it? What works, is rtl_fm (as much as I understand, it is from another codebase) Otherwise - thanks for a new test scenario.

guruofquality commented 5 years ago

Really thanks for the hint. As I understand, ABI compatibility is a PhD / chief architect level science. Hopefully fresh Debians and Ubuntus do not contain ABI defects ex-works (otherwise no hope to debug it all).

Debian might be fine, but you added source packages. What if rx tools and some of the modules used the master branch of SoapySDR development headers, but rx tools loaded the SoapySDR library from the debian package because that was installed too. Well SoapySDR master branch moved on and had ABI changed since the debian packaged version. Now you have an ABI incompatibility. Arguments passed into functions might get goobered up. This happens all of the time, its the first thing I have people check when there is a cryptic error: https://github.com/pothosware/SoapySDR/wiki/ConfigGuide#avoid-simultaneous-installs

metssigadus commented 5 years ago

Yes, a good link. However: why am I building this package from source? Because this was how it worked last time. Debian-approved packages tend to be old. To avoid the silicon brains to make decisions instead of me. But thnx for the idea, I will certainly try with the official packages next. Unwillingly installed packages? Very unlikely. I have a habit to install Debian from minimalistic netinstall ISO, the only option checked beside the system utilities, is "SSH server". No X/Win or anything else. 25 years of live with Linux makes paranoid. Both apt list --installed | grep -i Soapy and apt list --installed | grep -i rtl yield nil packages. Will test with official packages now.

zuckschwerdt commented 5 years ago

I just wiped /usr/local on a Debian Buster, no SDR packages installed but libusb-dev. Installed current master of rtl-sdr, SoapySDR, SoapyRTLSDR, rx_tools, each with mkdir build ; cd build ; cmake .. && make && sudo make install Then sudo cp rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/99-rtl-sdr.rules, plugged in an RTL-SDR and rx_sdr works just fine. There really must be something different about your system setup. Look through find /usr/local if anything looks suspicious.

metssigadus commented 5 years ago

Thnx Josh. Yes, it occurs possible to use pre-compiled Ubuntu packages. Thnx for the idea. But low satisfaction - much work, compilation is still needed and the result is not very clean. Approximately 1.5h time spent. At least possible. There is a hope now that my otherwise ready OpenWebRX installation can be rescued.

The script: install from ubuntu-18.04.2-live-server-amd64.iso - Why this? After investigating, which Ubuntu has the best and latest support for Soapy. (154 packages can be updated. 71 updates are security updates.) apt install soapysdr-module-all (That was a bit of mistake, b/c audio interfaces were included into Soapy and Jack used (which is a well known tool for musicians, not hams). Details here: https://packages.ubuntu.com/search?keywords=soapy&searchon=names&suite=bionic&section=all I thought the soapysdr-module-mirisdr was for SDRPlay but likely it wasn't. Still needed to compile. b/c SDRPlay modules were missing from the set.. apt install soapyremote-server apt install soapysdr-tools SoapySDRUtil --find - works now but the output is dirty, contains USB and Jack errors. apt install rtl-sdr after that rtl_test started to work apt install libsoapysdr-dev libsoapysdr-doc (just in a hope it will be needed later) bash SDRplay_RSP_API-Linux-2.13.1.run git clone csdr git clone SoapySDRPlay apt install emscripten (which likely was unneccesary) it occurred cmake was missing, and g++ and fftw3-dev to even compile. The result: rx_fm -d "driver=sdrplay" -f 100.7M - linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown Using device RSP1A: mir_sdr_api_version=2.130000 mir_sdr_hw_version=255 serial=CENSORED Found 1 channel(s) : Channel 0 : Found 1 antenna(s): RX Found 2 gain(s): IFGR RFGR Found 2 frequencies: RF CORR Found 13 sample rates: 250000 500000 1000000 2000000 2048000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000 Found 8 bandwidths: 200000 300000 600000 1536000 5000000 6000000 7000000 8000000 [INFO] Using format CS16. Bandwidth set to automatic resulted in 0 Hz. Tuned to 100952000 Hz. Oversampling input by: 42x. Oversampling output by: 1x. Buffer size: 8.13ms Sampling at 1008000 S/s. Output at 24000 Hz.

(a very promising output without any sync errors) With Lenovo the fans reflect the processor load, thus probably OK. Integration tests tomorrow. To zuckschwerdt: test with Debian Buster also tomorrow. I already see my possible mistake - I pre-installed libusb-1.0-0-dev.

zuckschwerdt commented 5 years ago

re: libusb, I did install those from stock Debian packages. Used Buster because I had a spare machine, should work with Stretch too.

guruofquality commented 5 years ago

So the choice to install debian packages or from source or hybrid of both is a personal personal preference thing. I really just wanted to eliminate possibility ABI issues and other incompatible install things.

I often install the soapysdr lib/dev stuff from packages from apt and do the modules from source. Since various modules tend to move more in features and bug fixes and dont forget the driver from the manufacturer changes too.

PS some of the apt packages drag in way to many "recommended" modules and other things, so --no-install-recommends can help here

Don't forget there is a rate tester if you want to check streaming without the rx tools stuff installed; SoapySDRUtil --rate=1e6 --direction=RX --args="your device args"

metssigadus commented 5 years ago

I am especially thankful for these two hints:

To give something back to the community, a test sequence how to make a RTL-SDR stick work remotely:.

A tidy PoC installation script

to positively test a single RTL-SDR stick over SoapyRemote, 2019-08-02.

Two amd64 machines required: a "radio host" and a "sink host", obviously networked (fast). Use a Ubuntu latest enough but still with pre-packaged Soapy: ubuntu-18.04.2-live-server-amd64.iso Make an ABSOLUTE minimal installation - no extra packages, no apt update/upgrade, no bells or whistles. These commands need adm rights (prepend with sudo): apt install soapysdr-module-rtlsdr soapysdr-tools soapysdr-module-remote avahi-daemon apt install soapyremote-server # only on the radio host, not the web host echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE="0666"' > /etc/udev/rules.d/65.rtlsdr.rules # as root on the radio host; to be able to mention the driver by its name ==== a REBOOT ===========

Tests

  1. on radio host, ordinary user: SoapySDRUtil --find # no errors, the device list should be empty
  2. Stick the rtl-sdr into USB.
  3. SoapySDRUtil --find # no errors, the device list should show your stick
  4. on sink host: SoapySDRUtil --find # no errors, your stick is listed now # automagics
  5. on radio host: SoapySDRUtil --rate=2e6 --direction=RX # ctrl-C should work correctly, no core
  6. SoapySDRUtil --rate=2e6 --direction=RX --args="driver=rtlsdr" # fails if no udev rules
  7. on sink host: SoapySDRUtil --rate=2e6 --direction=RX --args="driver=rtlsdr" # starts but no stream
  8. at radio host: apply CTRL-C b/c just one concurrent consumer possible
  9. at sink host: the stream suddenly starts now.

Extra: apt update && apt upgrade && init 6 and reapply the test sequence (khm, for deeper provenance). Consult at https://packages.ubuntu.com/search?keywords=soapy&searchon=names&suite=bionic&section=all about what your pre-packaged options are.

===================== Aside a clean and successful single thread rate test, I am still having problems (incl the --args syntax permitting such combinations that the multiple streams interfere with each other's CS value). SDRPlay is one of the best devices on the market (14 bit at 2MHz width) but worst supported by Soapy while otherwise Soapy is a brilliant idea. Should I happen to dig out the root problem, I'll come and tell. In my opinion, smth else is wrong while ABI is just a surface scratch.