Feeder stopped working

FlightAware ADS-B Flight Tracking
1

Got an email about an 2 hours ago saying my feed had stopped.

I have 2 feeders and the one down is one I built many years ago using The ADS-B Receiver Project scripts, and have mainly just left it running (i.e no recent updates). Checked the pi and it was powered up so went to it’s ip address and got the “map” page, but no data. The page says:

Problem fetching data from dump1090.
AJAX call failed (error: Not Found). Maybe dump1090 is no longer running?
The displayed map data will be out of date.

Logged into the pi ok via SSH, and ran rtl-test and it showed the dongle ok, ran “dump1090-mutability --interactive” and it showed / decoded data.

Did “sudo systemctl status piaware” and it shows:

piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled)
Active: active (running) since Mon 2022-01-31 16:17:11 GMT; 3h 16min ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 792 (piaware)
CGroup: /system.slice/piaware.service
└─792 /usr/bin/piaware -plainlog -statusfile /run/piaware/status.json

Jan 31 19:31:34 raspberrypi sudo[9242]: pam_unix(sudo:session): session closed for user root
Jan 31 19:31:34 raspberrypi piaware[792]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Jan 31 19:32:28 raspberrypi sudo[9292]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wid…numeric
Jan 31 19:32:28 raspberrypi sudo[9292]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 31 19:32:28 raspberrypi sudo[9292]: pam_unix(sudo:session): session closed for user root
Jan 31 19:32:28 raspberrypi piaware[792]: no ADS-B data program seen listening on port 30005 for 190 seconds, next check in 60s
Jan 31 19:32:34 raspberrypi sudo[9302]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wid…numeric
Jan 31 19:32:34 raspberrypi sudo[9302]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 31 19:32:34 raspberrypi sudo[9302]: pam_unix(sudo:session): session closed for user root
Jan 31 19:32:34 raspberrypi piaware[792]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Hint: Some lines were ellipsized, use -l to show in full.

From that thought the issue could be with dump1090-mutability did “sudo /etc/init.d/dump1090-mutability status” and it shows:

● dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
Loaded: loaded (/etc/init.d/dump1090-mutability)
Active: active (exited) since Mon 2022-01-31 19:03:16 GMT; 31min ago
Process: 7513 ExecStop=/etc/init.d/dump1090-mutability stop (code=exited, status=0/SUCCESS)
Process: 7576 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)

Jan 31 19:03:16 raspberrypi dump1090-mutability[7576]: Not starting dump1090-mutability daemon, disabled via /etc/default/dump1…ning).
Jan 31 19:03:16 raspberrypi systemd[1]: Started LSB: dump1090 daemon (mutability variant).
Hint: Some lines were ellipsized, use -l to show in full.

Bit stuck what to do now. Not sure where the problem lies. I have been meaning to upgrade to the latest PiAware version, and see V7 came out a month or so back, so not sure it it’s just going to be easier to re-image the SD card with that then try to trouble shoot.

If I do do a new image, I think there are some instructions on keeping the same feeder ID. Also I like the graphs that the ADS-B Receiver Project provided, I think there are other ways to get those now, any pointers please.

Thanks, Ian.

2

That’s the reason why there is no data flow.

i would recommend to upgrade to dump1090-fa first.
Looks like you’re running a piaware image, right?

Then you could simply use the latest image available and start over from scratch. Shouldn’t take that long.

3

Very strange, the dump1090-mutability file had START_DUMP1090=“no”, so I changed it to Yes, and rebooted. After it rebooted I loaded up the web page, and it showed planes for about a second, and then stopped.

Doing “sudo /etc/init.d/dump1090-mutability status” shows:

dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
Loaded: loaded (/etc/init.d/dump1090-mutability)
Active: inactive (dead) since Mon 2022-01-31 20:06:49 GMT; 4min 32s ago
Process: 847 ExecStop=/etc/init.d/dump1090-mutability stop (code=exited, status=0/SUCCESS)
Process: 421 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)

Jan 31 20:06:41 raspberrypi systemd[1]: Started LSB: dump1090 daemon (mutabi…
Jan 31 20:06:48 raspberrypi systemd[1]: Stopping LSB: dump1090 daemon (mutab…
Jan 31 20:06:49 raspberrypi systemd[1]: Stopped LSB: dump1090 daemon (mutabi…
Hint: Some lines were ellipsized, use -l to show in full.

so it looks like its crashed out. Checked the dump1090-mutability file and the line had chnaged back to START_DUMP1090=“no”

4

power supply or SDR is done with.
hard to tell which.

If this is doesn’t show voltage issues (no output), it’s likely the SDR:

sudo dmesg --ctime | grep voltage

Or the sd-card is done with.

You can start new with piaware image or go this route:

Raspbian Lite: ADS B receiver · wiedehopf/adsb-wiki Wiki · GitHub

5

Yep, could be any number of things, and I’m more a PC man then linux, so (as I was planning on doing it anyway) I have just re-imaged the SD card with the latest PiAware 7 image, and it seems to be back up and working (though without graphs etc).

Is this the best (only) way to get graphs etc, or can they be added onto the PiAware image?

Thanks for your help.

6

The install the graphs linked in my link.
They don’t care.

7

Is it crazy that I had the exact same error today? My setup has been running 24/7 for over a year. I’m running dump1090-mutability 1.15dev on a raspberry pi 3b+, with the FR24 an FA feeders running side-by-side.

The pi does seem to be having some power delivery issues, so I think that’s what the root cause is. Crazy coincidence though.

8

Culprit seems to be FR24 feeder. In the latest update they have done something to chnage back START_DUMP1090=“yes” to START_DUMP1090=“no” when RPi is booted

 

image

9

Good spot. I have blatted my card now with the new PiAware 7 image, so cant check any settings, however I was also running a FR24 feed from the pi (however I didn’t upgrade anything, so not sure if it auto updates). Maybe something for aesoprrp to check if he is also still having issues.

10

Should be verified instead of assuming it. We had these cases here already in the past.

11

Yes, FR24 push updates, so fr24feed updates without user knowing it.

This piece of code in their file /usr/lib/fr24/install_dump1090.sh causes the change of autostart from yes to no:

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

 

To prevent fr24feed from repeatedly changing autostart from “yes” to “no”, get rid of this file

sudo rm /usr/lib/fr24/install_dump1090.sh

 

 

12

Thanks for the link, I started adding things to the PiAware image, and it seemed to be working, but when I was trying the autogain script I’, not sure it was working correctly (also the gain graph was showing 38 all the time), so I blatted the card again, installing Pi OS Lite, and then ran your scripts.

Have to say, was well impressed, everything went ok, and think I have got all working ok. The tar1090 web page, graphs1090, and the upload to Flight Aware.

The only thing I’m not sure about is the area: readsb wiedehopf fork --heatmap feature
What does that do.

13

Yeah that’s not really user friendly and off by default.
No plans currently to make it user friendly, sorry.

Basically you add parameters to the readsb configuration, create that directory and make the owner readsb.
Then you can look at /?heatmap with some more options … and at /?replay.

But again, sorry i don’t have plans to make that simple because that requires lots more code to automatically delete old data.
Also it writes data to the sd-card … and and and.
Maybe i’ll script it some day, not today.

So in the meantime: If you can’t figure it out, i can’t help you (more than the above explanation).

14

Amazing, thank you! I had no idea that FR24 pushes updates like that. I followed your install guide a few years ago, and it’s been running great up until yesterday.

I did have some undervolt errors, so I initially thought the issue was due to the power supply. I switched the power supply, manually changed the “autostart” flag to “yes”, and rebooted, and it’s working now. The same pi is also running as a GPS stratum-1 time server just for fun, so it uses a bit more power than the average feeder I think.

I’ll remove that file as well just to be sure.

FYI you can view my feeder here (exact location obfuscated): planes.7aux.net

Hosted directly on the pi itself :slight_smile:

1 Like
15

You can run my script to install fr24feed, it disables their autoupdate.
(it uses a service file and a binary, no autoupdate and other stuff that ships with their package)
They’ve broken configurations before …

https://github.com/wiedehopf/adsb-wiki/wiki/Raspbian-Lite:-ADS-B-receiver

Or switch to the piaware image, it’s unlikely FR24 will interact with dump1090-fa …
Well they could always start up the dump1090 binary directly or install and enable dump1090-mutability and grab the SDR while not providing data on the usual ports.

16

Nice, thanks! I think I’ve installed your heatmap scripts before. Do you think it’s worth it to run your scripts on top of the existing configuration? Don’t really want to rock the boat too much, but if it does get rid of the auto-updating without changing much else about the configs I already have, I’m open to it.

17

Thanks abcd567. To the rescue again!

18

Instead of deleting or renaming file /usr/lib/fr24/install_dump1090.sh, 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

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

 

I fail to understand how FR24 programmers ignored :rage: the fact that a lot of users dont use setting receiver=“dvbt” (which runs dump1090-mutability in a walled garden). Instead they use setting receiver=“beast-tcp” host=“127.0.0.1:30005” and run dump1090-mutability EB_VER as a stand-alone app.

 

19

Ok, so my original code in the file is (lines 10-14 here):

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

And you’re saying to make it:

if grep -q "^receiver.*dvbt" /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; 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
    echo "dump1090 is not found, downloading dump1090-mutability..."

    # to skip any questions from APT
    export DEBIAN_FRONTEND=noninteractive

Correct?

20

No
Scroll down to bottom of file and copy paste last 5 lines here to let me see if you have old file or updated file