Can you test 3.7.1, or do you know that works?
maybe i’ll plug a receiver into my server laptop real quick and give it a whirl.
Never tried dump978-fa ver 3.7.1.
The only other version of dump978 I have tried was long ago, installed using Joe Prochazka’s script, and it worked perfectly ok, but it was either Jessie or Stretch, cannot recall correctly. Pi were same (OrangePIPC armv7 and RPi 2 armv7)
root@x230 ~/code/dump978 # ./dump978-fa --sdr driver=rtlsdr --format CS8
Found Rafael Micro R820T tuner
Found Rafael Micro R820T tuner
Exact sample rate is: 2083333.135571 Hz
[R82XX] PLL not locked!
SoapySDR: using maximum manual gain 49.6 dB
SoapySDR: using stream setting buffsize=262144
Working fine for me. I’m on debian unstable, but with soapysdr0.6 as well.
Can you try the same command line without systemd stuff?
The executable should already be in the directory from the last build.
Maybe the build options are different for the deb package, i’ll build that.
abcd@debian10:~$ apt-cache policy soapysdr
N: Unable to locate package soapysdr
It’s different packages for 0.6 and 0.7
This should show the version.
You can also do:
apt show soapysdr0.6-module-rtlsdr
Anyhow, can you show the /etc/default/dump978-fa configuration you used?
abcd@debian10:~$ apt show soapysdr-module-rtlsdr
Package: soapysdr-module-rtlsdr
Version: 0.2.5-1
Priority: optional
Section: hamradio
Source: soapyrtlsdr
Maintainer: Debian Hamradio Maintainers <debian-hams@lists.debian.org>
Installed-Size: 6,144 B
Depends: soapysdr0.6-module-rtlsdr (= 0.2.5-1)
Homepage: https://github.com/pothosware/SoapyRTLSDR/wiki
Download-Size: 1,140 B
APT-Sources: http://deb.debian.org/debian buster/main amd64 Packages
Description: RTL-SDR device support for SoapySDR (default version)
The Soapy RTL-SDR project provides a SoapySDR hardware support module.
Using this, any program using SoapySDR to interface to software
defined radio hardware can make use of low cost DVB-T/DAB+ USB dongles
based on the Realtek RTL2832U chip as receivers.
.
This is an empty dependency package that pulls in the RTL-SDR module
for the default version of libsoapysdr.
.
abcd@debian10:~$ apt show soapysdr0.6-module-rtlsdr
Package: soapysdr0.6-module-rtlsdr
Version: 0.2.5-1
Priority: optional
Section: hamradio
Source: soapyrtlsdr
Maintainer: Debian Hamradio Maintainers <debian-hams@lists.debian.org>
Installed-Size: 115 kB
Provides: soapysdr0.6-module
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), librtlsdr0, libsoapysdr0.6, libstdc++6 (>= 6)
Homepage: https://github.com/pothosware/SoapyRTLSDR/wiki
Download-Size: 35.5 kB
APT-Manual-Installed: no
APT-Sources: http://deb.debian.org/debian buster/main amd64 Packages
Description: RTL-SDR device support for SoapySDR
The Soapy RTL-SDR project provides a SoapySDR hardware support module.
Using this, any program using SoapySDR to interface to software
defined radio hardware can make use of low cost DVB-T/DAB+ USB dongles
based on the Realtek RTL2832U chip as receivers.
EDIT:
Installed following, but no success, dump978-fa still fails:
abcd@debian10:~$ sudo apt install soapysdr-module-rtlsdr
... ... ....
Unpacking soapysdr-module-rtlsdr:amd64 (0.2.5-1) ...
Setting up soapysdr-module-rtlsdr:amd64 (0.2.5-1) ...
No clue why it’s working for me and not for you 
3.8.0 dev working just fine as well.
That should have already been installed …
It’s the same as soapysdr0.6-module-rtlsdr
Can you show the /etc/default/dump978-fa configuration?
.
abcd@debian10:~$ cat /etc/default/dump978-fa
# dump978-fa configuration
# This is sourced by /usr/share/dump978-fa/start-dump978-fa as a
# shellscript fragment.
# If you are using a PiAware sdcard image, this config file is regenerated
# on boot based on the contents of piaware-config.txt; any changes made to this
# file will be lost.
# dump978-fa won't automatically start unless ENABLED=yes
ENABLED=yes
RECEIVER_OPTIONS="--sdr driver=rtlsdr,serial=00000101 --format CS8"
DECODER_OPTIONS=""
NET_OPTIONS="--raw-port 30978 --json-port 30979"
Hmm … yeah no clue.
All i can say: it’s working for me.
LUCKY 
Got fedup with soapysdr problem.
It occured to me that as I am NOT using any fancy dongles like AirSpy or Stratux, etc, but using a simple good old DVB-T/ProStick, why do I need Soapysdr?
(@obj is it not possible to have two versions of dump978-fa, one “basic” without Soapysdr for DVB-T, other “professional” with Soapysdr for fancy dongles?)
I decided to install dump978 by J Prochazka’s script which does NOT use Soapysdr.
Had also to install its Web Portal to display dump978 map.
It initially got stuck, but I could manage to make it go by a little change in PHP version from php7.0-cgi to php7.3-cgi as shown below. It is running OK, but UAT planes are rare in Toronto, and this is minimum traffic time (2:30 AM), so will have to wait and see.
Workaround in JProchazka’s script for Debian 10 (Buster) amd64
Changed line
if [[ $RECEIVER_OS_RELEASE -ge "9" ]]; then DISTRO_PHP_VERSION="7.0"; fi
to
if [[ $RECEIVER_OS_RELEASE -ge "10" ]]; then DISTRO_PHP_VERSION="7.3"; fi
in following chunk of code:
abcd@debian10:~$ sudo nano adsb-receiver/bash/portal/install.sh
.... .... ....
## CHECK FOR PREREQUISITE PACKAGES
DISTRO_PHP_VERSION="5"
case $RECEIVER_OS_DISTRIBUTION in
debian|raspbian)
if [[ $RECEIVER_OS_RELEASE -ge "9" ]]; then DISTRO_PHP_VERSION="7.0"; fi
;;
ubuntu)
if [ `bc -l <<< "$RECEIVER_OS_RELEASE >= 16.04"` -eq 1 ]; then DISTRO_PHP_VERSION="7.0"; fi
if [ `bc -l <<< "$RECEIVER_OS_RELEASE >= 17.10"` -eq 1 ]; then DISTRO_PHP_VERSION="7.1"; fi
if [ `bc -l <<< "$RECEIVER_OS_RELEASE >= 18.04"` -eq 1 ]; then DISTRO_PHP_VERSION="7.2"; fi
;;
esac
# Install PHP.
CheckPackage php${DISTRO_PHP_VERSION}-cgi
CheckPackage php${DISTRO_PHP_VERSION}-json
.
.
Possible? Sure. But the whole point of using soapysdr is so that the SDR code only has to be written once. It is an abstraction layer.
2 Likes
I am planning to do one more experiment: Using skyaware978 to display map for dump978 installed by JProchazka’s script. This way I will no longer need Web Portal to display dump978 map, and can get rid of it
I have disable dump978-fa & skyaware978 before I installed dump978 by JP’s script. I will now do following:
(1) Enable skyaware978, but keep dump978-fa disabled
(2) In file /home/abcd/adsb-receiver/build/dump978/dump978-maint.sh,
Change:
tee >(/home/abcd/adsb-receiver/build/dump978/dump978/uat2json /var/www/html/dump978/data)
To:
tee >(/home/abcd/adsb-receiver/build/dump978/dump978/uat2json /run/skyaware978)
I may face write permission issue, as folder /run/skyaware978 is owned by user skyaware.
Let us see how it goes.
Why don’t you diagnose what’s going wrong with soapysdr?
As I said, soapysdr is a layer; under the covers it is still just calling librtlsdr. So it’s not that there’s different code actually talking to the dongle.
I tried to diagnose, but failed, and that is why I resorted to JProchazka’s script.
Dec 25 16:44:56 debian10 dump978-fa[6284]: Found Rafael Micro R820T tuner
Dec 25 16:44:56 debian10 dump978-fa[6284]: Exact sample rate is: 2083333.135571 Hz
Dec 25 16:44:57 debian10 dump978-fa[6284]: [R82XX] PLL not locked!
Dec 25 16:44:57 debian10 dump978-fa[6284]: SoapySDR: using maximum manual gain 49.6 dB
Dec 25 16:44:57 debian10 dump978-fa[6284]: SoapySDR: using stream setting buffsize=262144
Dec 25 16:44:57 debian10 dump978-fa[6284]: [::]:30978: accepted a connection from [::1]:43786
Dec 25 16:44:57 debian10 dump978-fa[6284]: Allocating 15 zero-copy buffers
Dec 25 16:45:03 debian10 dump978-fa[6284]: Message source reports error: TIMEOUT
Dec 25 16:45:05 debian10 dump978-fa[6284]: Reattached kernel driver
Dec 25 16:45:05 debian10 dump978-fa[6284]: Abnormal exit
I’m not sure how i would diagnose that timeout.
(i mean i’m just now looking at some source code, but you are asking someone to diagnose this error who as far as i know has no C or C++ experience)
This code seems to be the relevant code (readStream function being called from soapy_source.cc):
SoapyRTLSDR/Streaming.cpp at master · pothosware/SoapyRTLSDR · GitHub
I’m not even sure where i would find the source code for the debian 0.6 version package of the soapysdr rtlsdr module.
So it seems to be the same code here: Streaming.cpp · master · Debian Hamradio Maintainers / SoapySDR / soapyrtlsdr · GitLab
I’d assume that’s more current than the packaged code but anyhow do you understand lines 484 and following @obj?
//wait for a buffer to become available
if (_buf_count == 0)
{
std::unique_lock <std::mutex> lock(_buf_mutex);
_buf_cond.wait_for(lock, std::chrono::microseconds(timeoutUs), [this]{return _buf_count != 0;});
if (_buf_count == 0) return SOAPY_SDR_TIMEOUT;
}
Now if this were C i would probably understand the pthread logic here, but with C++ i’m not sure what exactly the locking stuff is doing.
Here is the other side of the lock/condition: SoapyRTLSDR/Streaming.cpp at master · pothosware/SoapyRTLSDR · GitHub
So the tl;dr is that it timed out because librtlsdr did not call rx_callback within the timeout. That in turn probably means that libusb didn’t hand a bulk transfer result to librtlsdr.
As to which bit is breaking, I really have no idea, but my first guess would be a USB problem (there’s a VM involved somewhere? many VMs don’t play well with librtlsdr) followed by a build / version skew problem as abcd does like his frankenstein installs.
@abcd567
Why don’t you start with a fresh VM image?
[this]{return _buf_count != 0;});
This means the lock is waited for until either the timeout expires or there is a buffer, correct?
Seems librtlsdr is working fine when not invoked by soapysdr on the system in question.
Maybe the libsoapysdr-dev version is not compatible with the soapysdr version?
apt show libsoapysdr-dev
Seems i’m probably using a more current version compared to @abcd567
Package: libsoapysdr-dev
Version: 0.7.1-2
Priority: optional
Section: libdevel
Source: soapysdr
Maintainer: Debian Hamradio Maintainers <debian-hams@lists.debian.org>
Installed-Size: 209 kB
Provides: libsoapysdr0.7-dev
Depends: libsoapysdr0.7 (= 0.7.1-2)
I’ll do a test with 0.6, installing it now.
(seems to be working as well, maybe it’s the librtlsdr version)
(also it could always be a VM interaction that i won’t see on bare hardware)
Yes, that’s a lambda passed as the predicate arg of wait_for: see std::condition_variable::wait_for - cppreference.com overload (2)
Think of it as implementing what you’d usually do with a loop around pthread_cond_wait, lifting the loop condition to test out into a predicate.
This is why I am suspicious there is a build problem. soapysdr is essentially just doing what rtl_sdr does, or what abcd’s hypothetical “what if dump978-fa used librtlsdr directly” version would do. If one works but the other doesn’t - and dump978-fa works fine on other systems - then it sure smells like it’s something to do with the build.
Whatever the reason, i’ve installed the debian stable packages for librtlsdr and libsoapysdr, it’s still working fine for me.
Looking at the locking code, i’m not sure that “wait for a buffer” is immune to race behaviour.
Wouldn’t it need to lock the mutex before checking for 0?
if (_buf_count == 0)
{
std::unique_lock <std::mutex> lock(_buf_mutex);
It looks like there is a race where it could never get notified.
But i suppose that would produce an overflow.
Edit: Nevermind, should be plenty of notify pings to prevent that.