Running dump1090 and the reporting on different machines?


I have some troubles to get my system running stable for a longer period of time. I had a RTL-SDR running on a OrangePi for month and then it failed. I upgraded to the latest revisions of software and it only worked for around 12…24h and then I again get emails from FA about feeder outage.

So last weekend I completely re-installed the system on a RPi zero W, using dump1090-fa, piaware and FR24 according the manuals available. It ran fine for several hours and then again, I got the email about feeder outage…

As I do have a server running 24/7 I wonder if I can separate the receiver - RPi from the feeders. Can I put dump1090-fa on the Pi and run FA and FR24 as docker on my PC based server and have also the website for the local visible flights on that local server? Do I need beast on the RPi?

With that all separated, the RPi stays a bit cooler and I could probably exactly see, what fails when?

Thanks for inspiration and helpful hints

How is it failing when it fails? Moving the feeder software somewhere else is unlikely to help if there’s an underlying problem like bad power, flaky dongle, wifi problems, etc.

If it runs fine for an hour to a day and then fails, it’s a power supply problem in most cases.

Check this log:

sudo journalctl --no-pager -u dump1090-fa

You can also check if the RPi detects undervoltage:

sudo dmesg --ctime | grep voltage

But even if that doesn’t show a problem, it can still be that the power isn’t making it to the dongle, because that’s often where the low voltage creates the problem.

Try a different USB cable if possible.
And a different power supply.

Thanks for that first advice. I am pretty sure, that the 5.1V / 2A power supply is not dropping out, but I will double-check. Until now (it still works) there is no power message appearing in dmesg.

Until now I also do not see any fault in

pi@adsb-pi:~ $ sudo journalctl --no-pager -u dump1090-fa
-- Logs begin at Mon 2019-09-09 07:57:03 CEST, end at Mon 2019-09-09 14:23:16 CEST. --
Sep 09 07:57:32 adsb-pi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Sep 09 07:57:32 adsb-pi dump1090-fa[403]: Mon Sep  9 07:57:32 2019 CEST  dump1090-fa 3.7.1 starting up.
Sep 09 07:57:33 adsb-pi dump1090-fa[403]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Sep 09 07:57:34 adsb-pi dump1090-fa[403]: Detached kernel driver
Sep 09 07:57:34 adsb-pi dump1090-fa[403]: Found Rafael Micro R820T tuner
Sep 09 07:57:34 adsb-pi dump1090-fa[403]: rtlsdr: enabling tuner AGC
Sep 09 07:57:34 adsb-pi dump1090-fa[403]: Allocating 4 zero-copy buffers

But I will keep these commands in mind for probably tomorrow morning.

Thanks, I’ll report back

You should check your router logs for connectivity issues, too.


I did check logs of my network before posting here. I have a quite extensive logging on my network and there is no fault to be seen. The RPi itself has not left the WiFi network for the last 36 hours.

I also could add, that I always could solve the issue for a little while by rebooting the adsb device, never by rebooting any access point or router. And it did not matter, if the Orange Pi ran on WiFi or wired LAN. The RPi zero W does not provide cable.

That’s indeed a proper one.

As i wrote it could still be the case that the USB OTG cable is just bad and drops too much voltage or creates other problems.
If you have a powered USB hub available, that’s a good way to test if the dongle voltage is the problem.

Could also be that the dongle is just shot as you were having problems before with the OrangePi as well which probably used a different power supply.

1 Like

Hehe, the USB cables are sort of special ones… I was a beta-tester for a phone manufacturer who implemented quick charging modes. So these USB cables are of a good quality and can supply enough current to the unit.

Even the unit is still running fine till toady, I checked for voltage messages again. No entry in the logs.

Regarding my initial question:

I thought I could keep the basic system simply by only fetching and decoding the data received from the tuner. The packages that change once in a while, the feeders, could run on a machine, where I can run them in docker container.
My thought was to also reduce the network traffic as the RPi only provides the dump1090 decoded data. But I guess I have to run “beast” somwhere to be able to split the data to the several services?

You can run another dump1090-fa in net-only mode and use socat to supply it with data from the dump1090-fa on the pi0.
(Or use combine1090 on the other computer: GitHub - wiedehopf/combine1090: Combine data from multiple ADS-B receivers into one readsb decoder / tar1090 webinterface
It offers the data on 29005 instead of 30005 using an independent instance of dump1090-fa, but you can change that.)

If you don’t use the local map, network traffic will actually increase if you transmit the beast data instead of the feeders.
That depends on the feeders you are using of course.

But none of that is likely to help with your issue.

Thanks for the idea. Sure that does not solve the issue, I was just thinking. Looks like I keep it as it is and run all software on the Pi. As I am currently also redesign my antenna park, I’ll probably move the Pi to a different position. So I have easy access and only the antenna is outside. That also enables the Option to put the Pi again in a metal shielding that reduces a lot of EMI emissions.

Since I write in this forum, the ADSB unit works fine. It feeds FA and FR24 and also the local site works fine.

Nevertheless I do have questions about the status output of the logs:

pi@adsb-pi:~ $ piaware-status 
PiAware master process (piaware) is running with pid 422.
PiAware ADS-B client (faup1090) is running with pid 538.
PiAware ADS-B UAT client (faup978) is not running.
PiAware mlat client (fa-mlat-client) is running with pid 15746.
Local ADS-B receiver (dump1090-fa) is running with pid 403.

dump1090-fa (pid 403) is listening for connections on port 30005.
no program appears to be listening for connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is NOT connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

got 'couldn't open socket: connection refused'
dump1090 is producing data on localhost:30005.

Your feeder ID is xxxx (from /var/cache/piaware/feeder_id)

Even I get this socket error, I do not see any missing things. And as above everything is looking fine, the error line is missing substantial information to get an idea what might be missing there.

pi@adsb-pi:~ $ fr24feed-status 
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2019-09-11 13:13:18.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-xxx.
[ ok ] FR24 Tracked AC: 18.
[ ok ] Receiver: connected (12450574 MSGS/0 SYNC).
[FAIL] FR24 MLAT: not running ... failed!

I know this might be the wrong forum, but do I have to run two MLAT services to feed two different instances?

It’s checking for dump978 for UAT reception.
I’ve previously asked to only even check for that when the option for UAT is enabled.
Maybe i’ll make a PR on github.

At least flightaware MLAT only works when it’s getting data from only one receiver.
But basically, if you combine data from two receivers, MLAT can’t work.

FR24 MLAT is started by fr24feed and is internal to the program.
Are you saying you are using the same share key for two receivers?
That won’t work, not for FA and not for FR24.
Re-run sudo fr24feed --signup and leave the key blank, you’ll get a second key.

This will be fixed in 3.7.2

1 Like

Nice to see, that my silly questions at least solved somebody else’s questions :slightly_smiling_face:

To answer the open questions around my installation, no, I do not service any duplicates. I do not feed two feeders of the same service from one antenna, nor do I receive at two stations with one key!

I have one receiver unit, that uses beast to be able to feed FA service with one valid FA-key and in parallel it feeds one FR24 feeder with one valid key for that service.

My question was, if MLAT is the same for any feed service and if one instance is running, its data can be used to feed FA and FR24. Or if it is sepcific to the service… But it looks like I have to read more about MLAT, what it is and when I do need it. At least at FA it is running fine.

MLAT is computed on the servers, FA gives you back some results, FR24 does not!
FA asks that you don’t share the MLAT results with other websites, that normally isn’t a problem as the results displayed in SkyView are not available on 30005 from dump1090-fa where the other feeders get their data.

So as you need servers to calculate it, it’s quite obvious that you need a separate client for each MLAT server which is computing MLAT positions.

Don’t know how you configure fr24feed, but it seems it doesn’t like something :wink:

That question was where my confusion came from, you misused the word instance, it has a very specific meaning in regards to software.

No matter the relevant bits in fr24feed.ini are:


AVR transmits no timestamps, so fr24feed can’t do MLAT.
For MLAT it needs to be beast protocol.

1 Like

Fine, that sheds some light!

But it also brings me to another topic (sorry) as I had that question on my list too. I wondered, that in the setup process of FA (piaware) I did not have to enter my geographical position, but only my height. Btw. there is an issue with the question for height, as the question does not tell if it likes feet or meter and if it should be MSL or what else. I found the answer in some older posts of how to set FA up and there was at least an (feet) in the config question and MSL as a comment in the answer.

Checking my receivers status page on FA told me, that MLAT doesn’t work cause it doesn’t have any position information. But a few minutes later it worked and the position is quite exact.

In opposite FR24 requests my position with enough explanations to get it right from the beginning and it also requests my exact GPS position. However, because of my missing knowledge about MLAT I thought, that one service is enough, so I intentionally disabled MLAT for FR24. Now I know better.

And finally: I do have a GPS module on that unit. It provides exact time, PPS, and position. I already wondered, if there is a mechanism to feed this data into the ADSB services automatically? And now that I see that there is an config option for MLAT around GPS, I need to read a bit more about that.

Location: (50.48, 8.27)
Location Set: September 8, 2019 6:50 PM
Location Source: Receiver

FA used the gpsd running to get the GPS coordinates, so it only asked for an altitude.
On my stats page i can select the altitude units and it specifies above ground level as well.
Maybe it’s different when you have gpsd running.

FR24 can’t use gpsd.

That requires a GPS receiver built into the ADS-B receiver, those are purpose built devices.

The rtl-sdr receiver for ADS-B is connected via USB, it’s internal clock can’t be synced to GPS. MLAT still works using syncing via ADS-B aircraft which transmit their position.

I was talking about the initial configuration via command line after first-time installation on a blank device.
And then it only asks sort of “Please enter your antenna height:” helping “(in feet above MSL)” would have been nice.
However, now as you speak of it, I see that you normally should have to configure almost nothing via the command line and I wonder why I was asked about the antenna height. Cause everything could be configured on the webpage. And it also explains, that the location can be set manually, but also is estimated through the position algos automatically.


I’m not aware that piaware or dump1090-fa asks that question on installation.
Maybe it was other software you installed?

Interestingly once it’s set with gpsd (your GPS receiver) as a source, you can’t change it manually no more.
The estimated position is not used for MLAT, that needs a precise position.

wiedehopf, Now I am puzzled…

Earlier I was said, that my GPS connected via UART and PPS signal to the RPi is not valid for MLAT calculations and (I read about MLAT) I see why. I actually saw no config options to configure the UART where the NMEA interfaces is hooked to.

However, I installed gpsd later during the testing of my GPS module and it worked fine. So piaware is now aware of the gpsd and relies on it as a position source? That is quite cool, as I was thinking about building a small hand held unit that shows the flights above your head, wherever you are.