FlightAware Discussions

A couple of dump1090 questions

Hi there,

I currently feed FR24 & RB24 from my Raspberry Pi using dump1090-mutability & MLAT Client and would like to add FA also but before I do so I would like to ask a couple of questions if I may please?

Currently all seems to be working as expected and I can also connect to the dump1090 map interface through a browser.

I decided to dig a little deeper and here is where I am coming unstuck.

  1. typing dump1090 --help or anything beginning with dump1090 returns;
    bash: dump1090: command not found
    I have tried running it after sudo, ./ and as sudo systemctl status dump1090 to no avail.
    How can I check status and run other command line queries please?

  2. As default the gain is set to max in /etc/default/dump1090-mutability so I thought I would set it to auto by replacing the line; GAIN=“max” with GAIN="-10" but every time I go to save it it tells me;
    Error opening file /etc/default/dump1090-mutability. Permission denied.
    The file on disk may now be truncated!
    I assume the file is help open while dump1090 is running but this is where I am stuck so am looking for some advice please.

Thanks & kind regards,

OK…well embarrassingly I solved the issue in 1. above by simply not using the full & proper name of dump1090!

I should have typed dump1090-mutability…

Guess I should be able to stop the service, edit the file to modify the gain and restart the service again?

Thanks & kind regards,

dump1090-mutability is unmaintained, please switch to a maintained version.

Easy ways to switch to either dump1090-fa or readsb:

You need to use sudo in front of your editor to edit most files that aren’t in your home directory.

Which editor says that? … If you don’t have permission … the file can’t be truncated.

Thanks for the replies guys but there is a bit of background here!

I had originally installed rbfeeder with its non-standard implementation of dump1090 which meant there were no maps to be shown locally and dump1090 was nowhere to be seen as it seemed to be wrapped up within rbfeeder. Typical AirNav…

So I only recently reconfigured and installed the standalone dump1090-mutability with some help as I am not familiar with Raspberry Pi/Linux etc. and everything seems to be working OK.

I really don’t want to upset things by changing things around at this point in time unless there is some advantage that makes it worth my while.

But I am curious so it is inevitable that I will dig in and get my hands dirty sooner rather than later based on previous form :grin:

Being curious apart from the former no longer being maintained what exactly is the difference between -mutabiity and -fa?

I will take a look at the link you supplied wiedehopf thanks very much but I would rather not be adding too many things at this moment in time and to be honest most of it went over my head anyway! :blush:

To answer your other question I was trying to use Geany but I managed to open the file with nano so all is well.

I was wondering however what advantage/disadvantage I might see if I changed the Gain from max to -10 but I will have a look round first and maybe open another thread if none of it makes sense!

Thanks & kind regards,

Gain = max sets gain to maximum setting which is 49.6 dB

Gain = -10 sets gain to AGC (autonatic gain cintrol). As the chip in DVB-T is designed for TV. The TV signal has fairly constant signal strength for any station. The AGC works ok. However for ADSB, the signal strength varies continously from plane to plane, and due to a glitch, AGC sets the gain to about 55 dB, about 5 dB more than what can be set by using max or 49.6

This 5 dB extra gain is advantageous for far away planes whose signal is obviously weak due to distance. It is also advantageous if antenna is low gain, or loss in coax is high.

However 55 dB gain can cause overload of dongle by strong signals of nearby planes, and strong mobile phone signals emitted by mobile phone towers.

Try gain -10 and observe results. Then reduce gain in steps, and at each step observe foa a day. You may try following values

-10 49.6 45 43 38 35 32 28 etc etc


Thanks for the info on gain abcd.

Is GAIN=’-10’ the same as GAIN=‘agc’ in the .ini file?

I’ll give that a go when I get my system back up & running to how it was before after my earlier hiccup!

Note to oneself…never tamper with a working system!

Thanks & kind regards,

I know what I just said about not to tamper with a working system but…but…after a hiccup this evening when I had to roll back to my last backed-up SD card I am in the same position now where I was prior to installing dump1090-mutability so using rbfeeder to do the legwork and feeding FR24 from that.

So if I was going to go over to dump1090-fa / readsb as suggested above I suppose now would be as good a time as any IF there is good reason for me to do so.

In favour of my sticking with -mutability not only is it proven to work on my system but I have had great help from abcd on another forum so it should be straightforward for me to re-follow his instructions and get back to where I was.

Unless of course someone can give me good reason(s) I should go with -fa / readsb that is!

But be quick as you can see from the above I am prone to change my mind at the drop of a HAT! :grinning_face_with_smiling_eyes:

Thanks & kind regards,

I would say this is a good reason:

In case you didn’t know @obj wrote both mutability and fa. So if he says change, I would go with his advice.

You follow the steps and it works …

Usually the two decoder install scripts should just reconfigure rbfeeder to use its data.
You get an easy way to change gain with a command … people that aren’t on the fr24 forum actually use dump1090-fa … or readsb.

In terms of core decoder changes:

  • extended Comm-B decoding
  • ADS-B v2 handled properly
  • lots of decoder bugfixes and data quality improvements

The web map is different.
Lots of changes around the edges e.g. to support different SDR types.

But really the “it’s maintained” is the main thing. I archived (made read-only) the -mutability repository on github because fielding bug reports and questions for a version of the code I hadn’t looked at for years wasn’t practical. If you run into problems with -mutability, I can’t provide help beyond “use dump1090-fa and see if the bug still exists there”.


Thanks for taking the time to reply guys;

LawrenceHill: No I didn’t know that dump1090 was written by obj but I do now…thanks!
However with all due respect I wouldn’t normally just do something because somebody says so! :stuck_out_tongue:

wiedehopf: The more I read the more confused I get…must be an age thing :blush: but I will take another look when the dust settles here.

obj: Perfect…exactly what I need! Tangible reasons so much so that I have now installed dump1090-fa thank you very much! :+1:

All seems to be working fine with both RB24 & FR24 MLAT feeds as before so I’m a happy camper once again and the map view in the browser looks much better than the earlier version.

One question for you if you don’t mind though; I use a paid iOS app called OpenADSB that has the ability to connect to my Pi on the LAN and display aircraft that I can ‘see’ from my location. What used to work with dump1090-mutability now doesn’t display aircraft with -fa.

AFAIK OpenADSB supports dump1090’s web interface usually via port 80 although I have the ability to specify a port and path if need be, in particular it polls /data/aircraft.json but this is something I shall take up with the author. Just seems odd that what worked with -mutability seems to have stopped working with -fa but of course it could be something that I have mangled here. Just thought I’d mention it in case you might say; “Oh yeah you just need to do this…” :smiley:

Thanks & kind regards,

UPDATE On the last point it is now sorted. I pointed it towards port 8080 and all is well. So in answer to my own question it was; “Yeah I just need to do this…” :smiley:

Hey obj,

Another advantage of using -fa over -mutability on my Pi 4 anyway seems to be reduced CPU load.

Using the built-in dump1090 within AirNav rbfeeder my CPU previously spent most of its time @18%

Changing to standalone dump1090-mutability dropped the CPU load down to @14%

Now using dmp1090-fa the CPU usage is now down to @8% dipping as low as 5% at times.

Quite a difference I’m sure you’ll agree and an added bonus is the CPU temperature has dropped 3-4°C

This running fr24feeder and MLAT-Client alongside all 3 iterations of dump1090 with the Pi not being used for anything else.



Did you install mlat-client using sudo apt-get install mlat-client AFTER running Radarbox24’s rbfeeder installation script?

If yes then do this check:

First go to your RB24 RPi station’s stats page at

(Replace xxxxxx by your 6-digit station number)

On top-left do you see MLAT active like screenshot below?


If you see Mlat active, give this command

sudo systemctl restart rbfeeder

After say 10 minutes, check station map again. Do you see Mlat active now? If you dont, check again after say another 20 minutes. You may not see it even after wait if you have that version of mlat-client which has a bug. Due to this bug, the mlat-client does not start when rbfeeder is restarted. You will have to reboot RPi to restart mlat-client.

Hello again abcd,

Thinking back I would have installed the mlat-client (from your Github?) after installing rbfeeder and yes I see exactly the same issue you describe here.


So after running sudo systemctl restart rbfeeder the MLAT line disappears from the box in the upper left corner but it takes some time (@15 mins) for the green MLAT indicator to disappear from the Ranking table.

If I take a look at FR24 on Port 8754 it shows MLAT as still running.

A reboot brings MLAT back on RB24 as you say.

Is there a fix for this bug?

Thanks & kind regards,

Probably off topic but I’ve just noticed an anomaly on this particular Pi that doesn’t seem to have affected the other two - when I run sudo apt update it tells me I have one upgrade and running apt list --upgradable returns the following;

$ apt list --upgradable
Listing… Done
dhcpcd5/unknown 1:8.1.2-1+rpt1+fa4 armhf [upgradable from: 1:8.1.2-1+rpt1]
N: There are 2 additional versions. Please use the ‘-a’ switch to see them.

Not sure if this might be related to something I’ve done today but all 3 Pi’s were updated yesterday and were exactly the same at one point.

Thanks & kind regards,

First you find out if you installed mlat-client from rb24 repo or from package built by me. To find out please post the output of following 2 commands:

apt-cache policy mlat-client

sudo find / -name mlat-client_0.2.11_BUSTER_armhf.deb


This is the FlightAware-provided bugfixed dhcpcd5 to avoid having it crash (and lose all networking) in some network environments. Up to you if you want to take that change or not.

I was certain it came from you but looking at the output I’m not so sure;

apt-cache policy mlat-client

Installed: 0.2.11
Candidate: 0.2.11
Version table:
*** 0.2.11 500
500 https://apt.rb24.com buster/main armhf Packages
100 /var/lib/dpkg/status

sudo find / -name mlat-client_0.2.11_BUSTER_armhf.deb

find: ‘/run/user/1000/gvfs’: Permission denied

Thanks & kind regards,

Thanks for the reply obj.

Well I Googled and read all 76 messages in the first thread that I found but as usual most of it went over my head!

Now I have never had any connectivity issues (AFAIK) and my setup is as follows;

Raspberry Pi 4B
SanDisk 32GB Extreme Pro
Original NOOBS Buster install
Static IP Address
Wired Ethernet connection/Wi-Fi disabled
DrayTek router
Pi-hole on a separate Pi/wired/static IP

So not sure if I might be susceptible or not and not sure what, if any action I should take?

Thanks & kind regards,