Feeding Data Manually



I have an image I am experimenting with to try and get a better understanding of data transfer. I have a Raspian Stretch image with PiAware installed manually.

I think I have found out the following three main components;

  1. piaware runs as a service and appears to control everything
  2. dump1090-fa runs as a service and seems to decode tuner data and display it on Skyview
  3. mlat-client-fa deals with mlat and is run from /usr/lib/piaware/helpers

If I run sudo service piaware stop - skyview continues to display data on map but nothing gets sent to flightaware.

So, with piaware stopped but dump1090-fa still running how would I send data to, for example, adsbexchange? For this example I am not looking to submit to FA and ADSBx - just one. I know there are scripts available to make all this work but I am trying to get an understanding of what happens.

When I fully understand how it is transferred then I will utilise two feeds.



dump1090 offers data in multiple formats on different local port.

For example the “BEAST” format is usuall on port 30005
Check /etc/default/dump1090-fa for the ports used. The options used there are described in the dump1090-fa help which is retrieved with dump1090-fa --help

So basically you could access the data over the network but you can of course also access those ports locally through loopback.
Now multiple clients like piaware or flightradar may connect to those ports and will continously get their data via TCP in the format corresponding to the port.

Now you just need to check if the other feeders normally run their own dump1090 which would be a problem. So you need to configure them to use BEAST format data and point them at localhost:30005

Also the other feeders may do “strange” things on install if you are unlucky. Flightradar24 behaves more or less but previous versions could mess up some stuff.

So if you search the forums their is not only a script but also custom notes on using multiple feeders from abcd that shows the config options you need to make this work.


(1) The source of data is the decoder software. On RPi this can be any one of the following:

  • dump1090 Malcolm Robb
  • dump1090-mutability
  • dump1090-fa
  • modeSDeco2
  • any other decoder software

(2) The Flightaware, Flightradar24, Planefinder, RadarBox24, Opensky-network, etc etc have their own feeder software.

(3) The Adsbexchange works with combination of 3 items:
(i) script for socat to establish and maintain connection to adsbexchange server (adsbexchange-socat_maint.sh).
(ii) mlat-client package
(iii) script to configure and maintain connection of mlat-client with adsbexchange server (adsbexchange-mlat_maint.sh).

(4) The various feeder software connect to decoder software as follows:

  • Flightaware: Beast,
  • Planefinder: Beast,
  • Flightradar24: either of the following two is ok
  • RadarBox24: Network, Beast,
  • Adsbexchange: Beast, localhost:30005

(5) Mlat feedback from Flightaware, as well as from Adsbexchange is at port 30104.

(6) Adsbexchange SOCAT script adsbexchange-socat_maint.sh

! /bin/sh
while true
    sleep 30
    /usr/bin/socat -u TCP:localhost:30005 TCP:feed.adsbexchange.com:30005

(7) Adsbexchange MLAT script adsbexchange-mlat_maint.sh

#! /bin/sh
while true
    sleep 30
    /usr/bin/mlat-client --input-type dump1090 --input-connect --lat $RECEIVER_LATITUDE --lon $RECEIVER_LONGITUDE --alt $RECEIVER_ALTITUDE --user $RECEIVER_NAME --server feed.adsbexchange.com:31090 --no-udp --results beast,connect,


I’m using 30105. I doubt I selected it on my own. Any reason/difference from using 30104?

EDIT 1: I setup port 30104, and I’m not receiving anything, while port 30105 has a steady stream.

EDIT 2: I just noticed that it’s not connecting, although VRS test says it can connect with the used settings/options.


30104 is INPUT to dump1090 for mlat feedback from Flightaware & adsbexchange.

30105 is OUTPUT from dump1090 to VRS or modeSMixer2.


Got it! Thanks for the clarification.


Thank you for excellent in depth explanation. Understanding how things work can help when problems arise.

Earlier this year I had a network problem that persisted for a few weeks., PiAware would drop out of network, Pi still working and able to ssh via serial but not network. Resolved itself and never did find out what the issue was. Appreciate not related to this issue.



The golden rule/s for fault finding.
Something was changed or something broke.
Change only one thing at a time to find the issue.


And the first thing to do after a problem is: reboot.:grin:


That’s no fun :slight_smile:



:grin: Yeah but then unsuccessful troubleshooting tends to lose its appeal pretty quickly, at least for me :wink:


I’ll spend some time trying to resolve an issue purely as a learning curve but often reimage is a quicker option. Certainly don’t take too long for PiAware.