-
PiAware Status shows red on: Radio, 1090 Radio, PiAware, FlightAware, GPS, and MLAT
-
My FlightAware status page has red buttons for PiAware, FlightAware, and MLAT
-
FR24 Feed log in Dozzle shows: [2026-09-06 20:42:11.472][fr24feed] BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][i]Connecting to unknown receiver via (tcp://ultrafeeder:30005)
[2026-09-06 20:42:11.481][fr24feed] [reader][i]Connected to the receiver, configuring
[2026-09-06 20:42:11.482][fr24feed] [reader][i]Configured, processing messages
-
PFClient log in Dozzle shows: [2026-09-06 21:39:37.323][pfclient_log] tail: cannot open ‘/var/log/pfclient/*.log’ for reading: No such file or directory
-
PiAware log in Dozzle shows: grep: /run/piaware/status.json: No such file or directory[2026-09-06 21:48:51.572][watchdog] piaware is not updating /run/piaware/status.json, sending SIGKILL[2026-09-06 21:48:51.870][watchdog] piaware killed (pid 412)
-
PlaneWatch log in Dozzle shows: [pw-feeder] 2026-09-06T21:49:33+01:00 ERR error reading from socket error=EOF conn=server-side dst=feed.push.plane.watch:12345 proto=BEAST src=ultrafeeder:30005[pw-feeder] 2026-09-06T21:49:33+01:00 WRN tunnel to plane.watch has been terminated dst=feed.push.plane.watch:12345 proto=BEAST src=ultrafeeder:30005[pw-feeder] 2026-09-06T21:49:33+01:00 INF retrying in 30s seconds dst=feed.push.plane.watch:12345 proto=BEAST src=ultrafeeder:30005[pw-feeder] 2026-09-06T21:49:44+01:00 INF connection statistics RxLocal=“402 kB” RxRemote=“0 B” TxLocal=“0 B” TxRemote=“402 kB” proto=BEAST
[pw-feeder] 2026-09-06T21:49:44+01:00 INF connection statistics RxLocal=“212 kB” RxRemote=“6.0 kB” TxLocal=“6.0 kB” TxRemote=“212 kB” proto=MLAT[mlat-client] Sun Sep 6 21:49:47 2026 Lost connection to ultrafeeder:30005[mlat-client] Sun Sep 6 21:49:48 2026 Reconnecting in 30.0 seconds
Trying a reboot of the hardware to see if it helps.
Yesterday morning I replaced the FlightAware ProStick Plus and everything has been working fine (apart from the old problem with MLAT going red from time to time). All of the above issues started when I upgraded to the latest stable version of ADSB.IM
Post reboot - Nothing seems to of changed.
Any ideas please?
Now its showing this again:
ADS-B Feeder Homepage for DWCrudgingtonUK
The system has been deemed unhealthy for this reason: 1090 container is down
Position / Message rate: 76 pos / 1410 msg per sec — 70 planes / 2806 today
Mentioned before that the power to the SDR can be the culprit.
In other words it’s likely that the pi3 power delivery has collapsed.
The circuitry on those is kinda known to be less than optimal.
Thus the new SDR is getting dirty power and can’t work properly.
Or the USB chip on the pi3 isn’t working properly.
I replaced the RPi power supply and have left it for the night to see how it looks in the morning
If I still have issues then I do have two other Pi’s so I will try another one Tomorrow and see if things improve
What Iam struggling to understand is that everything was working fine for about 36 hours and this all happened as soon as I upgraded ADSB.IM to the latest stable version. It was literally all working fine right before the software update and then after it rebooted when it had upgraded the problems started.
run in the terminal:
vcgencmd get_throttled (0x50000 or 0x5000, There has already been a voltage drop.), (0x0, never experienced a voltage drop)
Type the command “htop” in the terminal and check CPU usage to see if any core remains at 100% load or if memory is full(htop is good because you can visually see the consumption of these resources).
As soon as this error reappears, type “lsusb” in the terminal and check if the SDR is still being recognized.
If you suspect a USB power issue, do you have an externally powered USB hub to connect the SDR to the RPi and test it?
Coincidence.
Plus, making a system perform tasks increases the chance for hardware issues to show themself.
Quick update. The feeder seems to of “calmed down” overnight and all the aggrerates seems to have a good status. Bizzarely I even have three green indicators on FlightAware which is rare BUT ADSB Feeder Homepage shows this:
ADS-B Feeder Homepage for DWCrudgingtonUK
The system has been deemed unhealthy for this reason: 1090 SDR hung (sample count: 1405419520)
Position / Message rate: 0 pos / 0 msg per sec — 0 planes / 1035 today
Which after a couple of refreshes of the page has gone back to normal.
I will monitor the situation Today and if any further issues swap the microsd card and flightaware dongle into a different Pi to see if it changes anything.
Looks like I spoke too soon. It appears things are OK BUT when I just checked SkyAWare AnyWhere I get 0 aircraft
Checking feeder status for the aggregators I supply and this is the result:
ADS-B Exchange ADS-B Feed OK & MLAT OK
AirNav radar OK but shows no aircraft on map ( Telford and Wrekin - United Kingdom Station - AirNav Radar - Global Flight Tracking Intelligence | Live Flight Tracker and Airport Status )
OpenSky looks OK but shows a current rate of 0/min
SDMap has this warning: “Something seems to be wrong with the ADS-B reception of this station”
FR24 showing as connected but 0 Aircraft Tracked and 0 aircraft Uploaded
PiAware shows 1090 Radio orange, PiAware GREEN, FlightAware Green and MLAT Orange
PlaneFinder flatline no data
1090Mhz UK shows online but no data
In an attempt to fix this as it seems to be pointing to a hardware issue I have replaced the raspberry Pi with another known good unit and will monitor throughout the day to see how things go.
I will report back with progress/lack of but many thanks to everyone who responded and helped with this.
It lasted just under 30 minutes and now shows this:
“The system has been deemed unhealthy for this reason: 1090 SDR hung (sample count: 1665269760)” This is a brand new flight stick and a replacement (KNOWN GOOD) Raspberry Pi
I have no clue what you’re doing to be honest, adsb.im works rather well for a lot of users 
Did you install stuff via the command line or something? adsb.im is not for that, you might install stuff that interferes. (That shouldn’t quite show like this though …)
This looks like terrible power supplies possibly?
Or if the 2nd one is a pi3 too … it’s bad as well?
I don’t know.
No I havent installed anything using command line. I have now replaced the power supply with a brand new one and also replaced the 2nd Pi3 with a brand new still in the packet Pi3 to see where we go with it. There is nothing else I can replace but if I have further problems I will use a brand new MicroSD card and rewrite the ADSB.IM image to it.
Same again! The system has been deemed unhealthy for this reason: 1090 SDR hung (sample count: 3140288512)
I have created a new MicroSD card so will boot that and just add one aggregate and see how long it stays up
I’ll test the current adsb.im image on a pi3 … haven’t tested pi3 in a while.
There was no USB extension or hub was there?
Are you on wifi or ethernet? (might as well try and replicate everything)
Correct no usb extension or hub and I am on Ethernet
Thanks
David
The feeder system kernel detected under-voltage.
lol
That’s what happens when i test the pi3.
MLAT is intermittent, otherwise it works pretty solid.
So can’t replicate the SDR hangs you’re seeing.
Edit:
yeah pi3s are just a pain. since there are pi4s i’ve avoided them.
I’ve spoken too soon …
yeah i don’t mess with pi3s much because they are so unreliable.
[2026-09-07 17:51:55.814][readsb] cb transfer status: 5, canceling...
[2026-09-07 17:51:55.814][readsb] FATAL: rtlsdr_read_async returned unexpectedly, probably lost the USB device, bailing out
If you have a pi4 … or a powered USB hub, that might help.
What can also help: using wifi.
The ethernet is on the USB i believe so … not using ethernet can help for the pi3.
But it’s all very hit and miss with pi3s -.-
So one thing you could try is setting the powersave governor.
echo powersave | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
This method won’t survive a reboot though.
I guess there is /boot/firmware/config.txt to mess with frequencies permanently.