Switch from FR24 to Flightaware - benefits and changes?



I am new here so bear in mind with me and if this is in the wrong category please move it for me. Not entirely sure where to put this topic.

Anyhow, today I am feeding data to FR24. I feel happy the way it is and of course I have also heard about FA but never really considered it. I now want to know what benefits there are if I’d switch from feeding to FR24 to feeding to FA?

Currently I am having historical flight data for a year, I have different weather layers such as wind and SIGWX maps with FR and much more. On the statistics part there is not a lot of stuff but I have heard that FA is into much statistics is that true?

I have heard about the fact that you can get notifications and email-alerts with FA and I do in fact get those with FR24 as well but with FR24 there is a small delay of 5-20 minutes every time I get a delay. Is there a big delay with FA or is it instant? Is it possible to setup alerts that are based on when a flight departs and/or enters a specific airspace for instance Sweden or my local airport, ESGG?

Regarding mobile apps, which one do you prefer? How does the FA app stand towards the FR24 application? Does it load layers fast? I know that the FR24 app can be quite slow at times with loading the layers. Is it possible to search for specific tails/flight numbers/callsigns/routes etc?

Last but not least, would it be possible to feed to FA and FR24 at the same time and how does the web interface for FA look when going onto my raspberry pi’s local IP?

That’s it for now, and I would be very grateful if someone could give me some clues as to which one is better in this age and time.



Everyone has different liking & preferences. You are the best person to decide which is best for you. You can do this by adding Flightaware to your setup. You already have Flightradar24 setup. Once you have both setups running on your Pi, you can compare the two.


Please see these threads:

(1) How to Feed Data to Multiple Sites - A Brief Guide

(2) Bake a Pi (Links to “Option-1”, “Option-2”, “Option-3”, and “Additional Data Feeders” are broken due to migration to new forum. Scroll down to next posts to see these).


Ok! Thanks for your reply. I followed the guide in (1) that you posted. FR24 still works but I can’t get MLAT to work with the FR24 but that is no problem, I’ll fix that later. The main problem is that I can’t seem to get access to piaware. I used the workaround since I installed FR24 from their disk image yet I cannot find my pi when I go to claim my receiver.

Do I need to install dump1090-fa?



To feed Flaghtaware, you need to install either dump1090-fa or dump1090-mutability. The Flightradar24’s Pi24 image has integral dump1090 (malcolm robson), which cannot handle Flightaware’s mlat.

Another problem with Pi24 image is that lighttpd fails after reboot.

Using Flightradar24’s Pi24 image to feed Flightaware means unnecessary trouble and workarounds. This I have mentioned clearly in the thread “feeding data to multiple sites - a brief guide”.

Best option is to write either Raspbian image or Piaware image to your micoSD card. Please go to thread “Bake a Pi” , and choose any one of the 3 options ( OPTION-1 or OPTION-2 or OPTION-3 ), and after completing all steps in one of these options, add Flightradar24 Feeder as shown in item (2) of post “ADDITIONAL DATA FEEDERS” of “Bake a Pi” thread.



hi samuel,

in my opinion fr24 website and app are superior to fa. the big advantage of fa is mlat feedback directly to your pi running dump1090, better user-site statistics and last not least better technical support in forum through user obj who is the developer/maintainer of the most advanced dump1090 flavor and mlat-server/client.




  • merging data from any number of ModeS tcp-sources: binBEAST, AVR, AVRMLAT, SBS30006, SBS10001, MSG and/or physical serial devices - COM*-ports in Windows or /dev/tty’s in Linux to merged output stream. This stream, in turn, may be issued to the network in various formats simultaneously. Data format of input tcp-sources is automatically recognized.
    Incoming data may be both inConnect (pull from :) and inServer (listen data on own TCP-port ).
  • decoding/transcoding the input data to different formats to output: binBEAST, AVR, AVRMLAT, SBS30006, SBS10001 and MSG as required by user.
  • splitting output data stream for any number of IP-clients in the following formats: binBEAST, AVR, AVRMLAT, SBS30006, SBS10001 and MSG. The output data can be both outConnect (push :) and outServer (listen request on own TCP-port ).