Dump 1090 Errors

When I look at my FlightAware ADS-B receiver, I am getting the following error every minute or so:

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.

A minute or so later, the message goes away and the aircraft list is updated. Then it happens again.

I just updated to 3.7.2. Everything was working fine until about a month or two ago. Then I wasn’t seeing any aircraft. After updating to 3.7.2, I started seeing aircraft again, but now I have this problem.

HELP!!!

It could be a busy CPU or network connectivity issue.

run top or htop to see how busy the device is.

1 Like

Looking at your feeder 93993 I see a lot of hours in the hourly reports with no received reports. Is this site using WiFi for connectivity of the Pi to the network?

I would be suspicious of network connectivity. If you are using a PC running Windows or Linux try running a continuous ping to the ip of your FlightAware ADS-B receiver (ping -t 192.168.0.x) and see if you get any time out or unreachable messages.

If you are using WiFi and you are loosing connectivity I suggest you take a look at this post for possible solutions. PiAware WiFi looses connection randomly - Work-round found

The problem is internal in the Pi system, not in the WiFi connection to my network. I am pinging the feeder continuously and it consistently has ~40ms ping times, without any dropouts. When I am looking at the feeder map, about once a minute, the yellow error box pops up in the bottom left corner of the map and the aircraft list freezes for about 20 seconds. During this time, the clock at the top of the screen is still updating. After about 20 seconds, the aircraft list starts updating again, and the warning box disappears.

I’m not very technically inclined. How do I do that?

If you don’t have anything besides PiAware running on the RPi I think the simplest thing would be to re-image the SD card. The only thing you need to be concerned about if you do that, is keeping your existing feeder id, but how to do that is documented here PiAware - Upgrade PiAware to the latest version - FlightAware. The only caveat is where it says

piaware-config feeder-id 12345678-1234-1234-1234-123456789abc

Be sure to insert sudo in front of it, like this

sudo piaware-config feeder-id 12345678-1234-1234-1234-123456789abc

I doubt it’s gonna be a software issue.

Most likely the power supply or the dongle is dying.
Anyway that’s my guesses.

If you want to further diagnose the issue you’ll need ssh access:
For Beginners - How-to SSH to RPi - Setup Putty in Windows

While configuring that, it doesn’t hurt to reimage the sd-card with a fresh image as you have the sd-card out anyway.
(For Beginners - How to Get Back Existing Station Number in A Fresh Install)

40ms seems really high. I get that ping servers on the West coast from the East coast of the USA.

I have done some more troubleshooting on my Dump 1090 errors. I suspect that this is caused by winter temps in my outdoor enclosure.

I am running a Pi Zero W with the Flight Aware dongle. The system is located outside in a plastic enclosure in Minneapolis. I have swapped all of the hardware. Everything works fine when the equipment is indoors. When I have the system outside, I have the errors. I have tested two separate sets of Pis and dongles, and both have the same issues.

Does anyone have any experience with running this kind of configuration outdoors in MN winters?

There is not much information about the minimum temps a RPi needs (a lot about max temps :slight_smile: ),
but at least an older version has been used to monitor penguins in Antarctica.

Yeah, I know, a different Pi, and other equipment generating heat as well.

Also, maybe it is not the Pi but the RTL-SDR dongle that does not like the cold. There is a tool here somewhere to test wether a dongle is broken or not, I think @abcd567 has written something on how to use it.

Out of curiosity, what does vcgencmd measure_temp say when the receiver is outside? Also, immediately after you put the box outside, it should still work, and as the temp drop, maybe there is a temp point where it stops/starts showing errors.

After months of testing, I think I have finally found the root of the problem causing my Dump 1090 errors. It turns out that the cause was an excessively long USB cable from the power adapter to my Raspberry Pi Zero W. I was using a cable that was about 6’ long. When I replaced the cable with a 1’ cable, all my problems disappeared. I swapped out every component in the system (including antennas, Raspberry Pi, ADS-B Dongle, Power Supply, and Micro SD card). The only thing that affected the problem was the USB Power cable.

I don’t know if the cable length resulted in excessive voltage drop, or if there was noise introduced into the power supply.

1 Like

First of all, thanks for coming back and “bottling the top” on this by sharing your finding!

Based on what you’ve said, I’m not sure that the problem cause can be attributed to the cable length per se. Perhaps there was some sort of physical fault in the cable? Obviously could rule this out by trying another 6’ cable. However, since you’ve already shelled out enough cash replacing other components, maybe not worth finding out :->

Would be curious if a ferrite bead attached to the 6’ USB wire might suppress noise and eliminate the problem.

Congrats on finding the culprit! With the small (26 or 28 gauge) wires used in most USB cables, the wire resistance is significant. 12 ft of 26 gauge copper has .5 ohms, 28 gauge has .78 ohms, not counting the resistance of the USB connectors. Depending on your SDR, this will drop the SDR voltage and might add up to a full volt or more drop. I try to use shielded charging cables only, as these have heavier wire on the power pins. Have fun with this and keep learning and improving. Definitely not getting into how much $$ some of us spend to tweak out the last bit of performance.