I have a Raspberry Pi with with a Nooelec antenna feeding data to Flightaware, Flightradar24 and Adsexchange. Last night it stopped sending data to all of the sites. I tried restarting the device but it is still not sending any data.
This is the output of the piaware status
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-02-01 09:18:19 EST; 1h 31min ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 890 (piaware)
Tasks: 2 (limit: 2059)
CGroup: /system.slice/piaware.service
└─890 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
Feb 01 10:48:58 raspberrypi sudo[18286]: pam_unix(sudo:session): session closed for user root
Feb 01 10:48:58 raspberrypi piaware[890]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Feb 01 10:49:32 raspberrypi sudo[18406]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/netstat --program --tcp --wide --all --numeric
Feb 01 10:49:32 raspberrypi sudo[18406]: pam_unix(sudo:session): session opened for user root by (uid=0)
Feb 01 10:49:32 raspberrypi sudo[18406]: pam_unix(sudo:session): session closed for user root
Feb 01 10:49:32 raspberrypi piaware[890]: no ADS-B data program seen listening on port 30005 for 190 seconds, next check in 60s
Feb 01 10:49:58 raspberrypi sudo[18734]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/netstat --program --tcp --wide --all --numeric
Feb 01 10:49:58 raspberrypi sudo[18734]: pam_unix(sudo:session): session opened for user root by (uid=0)
Feb 01 10:49:58 raspberrypi sudo[18734]: pam_unix(sudo:session): session closed for user root
Feb 01 10:49:58 raspberrypi piaware[890]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
This is the output of the dump1090-mutability service status
● dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
Loaded: loaded (/etc/init.d/dump1090-mutability; generated)
Active: active (exited) since Tue 2022-02-01 09:18:10 EST; 1h 33min ago
Docs: man:systemd-sysv-generator(8)
Process: 529 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)
Feb 01 09:18:09 raspberrypi systemd[1]: Starting LSB: dump1090 daemon (mutability variant)…
Feb 01 09:18:10 raspberrypi dump1090-mutability[529]: Not starting dump1090-mutability daemon, disabled via /etc/default/dump1090-mutability … (warn
Feb 01 09:18:10 raspberrypi systemd[1]: Started LSB: dump1090 daemon (mutability variant).
pi@raspberrypi:~ $ sudo journalctl -xe | grep dump1090
Feb 01 10:46:14 raspberrypi piaware[890]: 0 msgs recv’d from dump1090 (0 in last 5m); 0 msgs sent to FlightAware
Feb 01 10:46:22 raspberrypi piaware[890]: attempting to start dump1090…
Feb 01 10:46:22 raspberrypi piaware[890]: can’t start dump1090, no services that look like dump1090 found
Feb 01 10:51:14 raspberrypi piaware[890]: 0 msgs recv’d from dump1090 (0 in last 5m); 0 msgs sent to FlightAware
Feb 01 10:51:23 raspberrypi sudo[19076]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/systemctl status dump1090-mutability.servi
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Any ideas what might be causing this? Nothing has changed to make it break.
#!/bin/bash
# Stop on first error
set -e
LOGFILE=/var/log/fr24feed_install_dump1090.log
exec > >(tee -a $LOGFILE)
exec 2>&1
if grep -q "^receiver.*dvbt" /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then
echo "dump1090 is not found, downloading dump1090-mutability..."
# to skip any questions from APT
export DEBIAN_FRONTEND=noninteractive
echo 'dump1090-mutability dump1090-mutability/auto-start boolean false' | debconf-set-selections -v
apt-get update -y
DUMP1090_IF_PRESENT=`apt-cache search --names-only '^dump1090-mutability.*' | awk '{ print $1 }' | head -n 1`
apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librtlsdr0 libusb-1.0-0 dirmngr lighttpd wget $DUMP1090_IF_PRESENT -y
if [ "$DUMP1090_IF_PRESENT" == "" ]; then
# Download and install dump1090-mutability if not present in repository
wget -O /tmp/dump1090-mutability_1.14_armhf.deb https://github.com/mutability/dump1090/releases/download/v1.14/dump1090-mutability_1.14_armhf.deb
dpkg -i /tmp/dump1090-mutability_1.14_armhf.deb
rm -f /tmp/dump1090-mutability_1.14_armhf.deb
fi
ln -s /usr/bin/dump1090-mutability /usr/lib/fr24/dump1090
lighty-enable-mod dump1090 || true
service lighttpd force-reload || true
systemctl enable lighttpd || true
systemctl start lighttpd || true
echo "dump1090-mutability is installed. You can always override it in /etc/fr24feed.ini with any other supported driver."
echo "Web server (aircraft map) at http://YOUR_DEVICE_IP/dump1090 is enabled by default."
fi
if grep -q 'START_DUMP1090="yes"' /etc/default/dump1090-mutability ; then
sed -i 's/START_DUMP1090="yes"/START_DUMP1090="no"/g' /etc/default/dump1090-mutability
systemctl stop dump1090-mutability || true
fi
The last part disabling dump1090-mutability runs unconditionally. (instead of running only when dvb-t is the receiver type)
This script runs on every time fr24feed is started.
The script even if deleted will be regenerated on the next auto update.
I think they haven’t even understood this breaks people.
FR24 uses a cron job to kick off auto updates. I disabled it months ago because they were rebooting the pi. I was pulling my hair out trying to figure out why the pi was rebooting. You can just run the task manually when you want to update. At least that way if something stops working you might have half a chance of figuring out what changed. For the same reason I only do manual updates of the FA code, but that’s easy to do via their website.
I have added two lines of code, one at top, one at bottom of the problematic chunk of code (which FR24 added with last update in file /usr/lib/fr24/install_dump1090.sh).
With this simple modification, this problematic piece of code will run only if my added code finds setting is receiver=“dvbt” in file /etc/fr24feed.ini
I fail to understand how FR24 programmers ignored the fact that a lot of users dont use setting receiver=“dvbt”
if grep -q 'receiver="dvbt"' /etc/fr24feed.ini ; then
if grep -q 'START_DUMP1090="yes"' /etc/default/dump1090-mutability ; then
sed -i 's/START_DUMP1090="yes"/START_DUMP1090="no"/g' /etc/default/dump1090-mutability
systemctl stop dump1090-mutability || true
fi
fi
