# dump1090 mutability and flightaware big problems - solved :)

**URL:** <https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367>\
**Category:** ADS-B Flight Tracking\
**Created:** [September 29, 2015, 7:08am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367 "2015-09-29T07:08:22Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [September 29, 2015, 7:08am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/1 "2015-09-29T07:08:22Z")

</div>

since about 2 weeks i was running a clean raspian install with libusb-1.0-0-dev, [sdr/rtl-sdr: Software to turn the RTL2832U into a SDR receiver - rtl-sdr - Osmocom gitea](http://git.osmocom.org/rtl-sdr.git) and git://github.com/MalcolmRobb/dump1090.git.

anything went perfect - flightaware, planefinder and virtualradarserver were showing working mlat.

now i gave flightaware and mutability dump1090 (each on different raspis, fresh install from scratch and latest release) a try.

result - about 10% higher stats BUT ANYTHING MESSED UP:

- mutability dump1090: flightaware shows this error on log:  
‘mlat(2777): Beast-format results connection with localhost:30104: [Errno 111] Connection refused’
- vrs shows no mlat anymore for both raspis
- planefinder does no mlat for both raspis

additionally i have to say - installing mutability (latest release) was a pain and i do not understand where this configtool is good for. so much easier and faster to have a simple config file.

best  
tom

---

<div class="post-metadata">

**Author:** ![obj](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/obj/32/118984_2.png) [@obj](https://discussions.flightaware.com/u/obj)\
**Post date:** [September 29, 2015, 10:11am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/2 "2015-09-29T10:11:51Z")

</div>

Did you read the announcement post about piaware 2.1-3 at the top of the forum?

You can directly edit the config in /etc/default/dump1090-mutability if you don’t like the debconf interface; the debconf questions just end up populating that.

If you want to improve the install process, send me a pull request with the improvements (could just be docs if that’s all it needs).

Please remember that dump1090-mutability is a side project that I do because it’s interesting. If it works for you, great! If it doesn’t work, I’m happy to take improvements. If it doesn’t work and you don’t like it, don’t use it.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [September 29, 2015, 10:20am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/3 "2015-09-29T10:20:13Z")

</div>

oliver,

beside the tip about config file - your post doesn’t help me much - and maybe others running in the same things …

p.s. malcolmrobbs fork of dump1090 presents all data needed (mlat inclusive) in beast format on port 30005 - and at the same time virtualradarserver, flightaware and planefinder can use it from here without any problems. so - i don’t know what is/was the reason that dump1090 from mutability and flightaware change this behaviour that obviously worked well.

---

<div class="post-metadata">

**Author:** ![mgunther](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/mgunther/32/78172_2.png) [@mgunther](https://discussions.flightaware.com/u/mgunther)\
**Post date:** [September 29, 2015, 11:12am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/4 "2015-09-29T11:12:19Z")

</div>

Hi Tom,

The default port change was made for a good reason: “This change is to try to avoid accidentally feeding mlat results to a dump1090 that is not mlat-aware and may forward the results on unexpectedly (e.g. to other feeder software that doesn’t expect to see them).”

As you correctly point out, malcolmrobbs fork of dump1090 presents all data (mlat inclusive) in beast format on port 30005. This is fine if you expect this and use the presented data appropriately. However, if you forward the data lets say to some public sharing sites or other feeder software and include mlat positions you may run into trouble. You may inadvertently feed sensitive mlat positions (military, government, etc) and allow them to be displayed publicly. You may also confuse other feeding software by mixing in mlat positions where that software expects only standard ADS-B positions.

Hope that helps to explain the change in the default port.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [September 29, 2015, 11:22am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/5 "2015-09-29T11:22:02Z")

</div>

hi mgunther,

yes - that explanation helps much 🙂

but leeds to the next question what/how and where i have to change - so that virtualradarserver planefinder gets mlat working again.

thanks in advance  
tom

---

<div class="post-metadata">

**Author:** ![mgunther](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/mgunther/32/78172_2.png) [@mgunther](https://discussions.flightaware.com/u/mgunther)\
**Post date:** [September 29, 2015, 11:37am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/6 "2015-09-29T11:37:37Z")

</div>

The opening post of “Piaware 2.1-3 released” answers exactly your question:  
If you use non-FA supplied dump1090, you can either re-configure PiAware or dump1090. The post has instructions for both.  
If you use FA-supplied dump1090, you should upgrade this also through the control panel. I understand all required port changes will be made automatically and you won’t have to do anything else.

For you, a third option is available: You can make the mlat client listen for connections on yet another port and create a new feed in VRS to connect to that. You can then combine these two feeds (from dump1090 and mlat-client) into one feed that you display on the VRS map. This solution has the added benefit of separating your feeds so that you can display them separately (or combined), have separate range plots, have separate position counts in VRS and generally know exactly what you are getting from which source.  
If that is of interest to you, I can get instructions and screenshots together this evening.

---

<div class="post-metadata">

**Author:** ![heypete](https://avatars.discourse-cdn.com/v4/letter/h/b782af/32.png) [@heypete](https://discussions.flightaware.com/u/heypete)\
**Post date:** [September 30, 2015, 9:39am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/7 "2015-09-30T09:39:57Z")

</div>

> [@mgunther](#):
>
> If that is of interest to you, I can get instructions and screenshots together this evening.

I can’t speak for anyone else, but I’d be interested in that if it’s not too much trouble.

---

<div class="post-metadata">

**Author:** ![mgunther](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/mgunther/32/78172_2.png) [@mgunther](https://discussions.flightaware.com/u/mgunther)\
**Post date:** [September 30, 2015, 9:25pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/8 "2015-09-30T21:25:47Z")

</div>

Hopefully I have something tomorrow.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 8:33am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/9 "2015-10-02T08:33:24Z")

</div>

hi obj,

since yesterday i’m running dump1090-mutability 1.15-dev on my test site.  
along mgunthers [perfect howto](http://discussions.flightaware.com/viewtopic.php?p=177419#p177419) it was easy to setup and now runs stable with about 6,000 aircrafts and 500,000 positions per day.

so - it was simply my fault with all the ‘port-confusion’ at my first install on my own some days ago. as already stated in an other thread - if all documentation were in one place - maybe this confusion wouldn’t have happend - at least to me. anyway - we already agreed to disagree in this ‚documentation thing’ :)))

i have some additional questions - but i’m aware you said ‚no support for dev‘. as long as the questions also apply to supported versions maybe i’m lucky …

1. is there a differnce between the versions of rtl-sdr i had installed earlier (git://git.osmocom.org/rtl-sdr.git) and the version mgunther uses (librtlsdr0\_0.5.4.git-1\_armhf.deb librtlsdr-dev\_0.5.4.git-1\_armhf.deb)?

2. now i have about 20% more positions reported - are they real received or averaged values?

3. in vrs i have about 400% more messages my settings different from default are: EXTRA\_ARGS="–forward-mlat“, NET\_BIND\_ADDRESS=„“

4. my processor load decreased from about 15% to 11% on pi2. why is your code obviously better/faster/more efficient?

5. these were the switches i used with malcolmrobs fork: --net --enable-agc --gain -10 --fix --aggressive --mlat --modeac --net-ro-size 500 --net-ro-rate 5. how about them?

thanx in advance  
tom

---

<div class="post-metadata">

**Author:** ![obj](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/obj/32/118984_2.png) [@obj](https://discussions.flightaware.com/u/obj)\
**Post date:** [October 2, 2015, 10:26am UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/10 "2015-10-02T10:26:03Z")

</div>

> [@TomMuc](#):
>
> 1. is there a differnce between the versions of rtl-sdr i had installed earlier (git://git.osmocom.org/rtl-sdr.git) and the version mgunther uses (librtlsdr0\_0.5.4.git-1\_armhf.deb librtlsdr-dev\_0.5.4.git-1\_armhf.deb)?

They’re basically the same, the package is just the (github mirror of the) osmocom repo plus packaging rules. It’s a few commits behind now.

> 1. now i have about 20% more positions reported - are they real received or averaged values?

I don’t know, where are you looking?

> 1. in vrs i have about 400% more messages my settings different from default are: EXTRA\_ARGS="–forward-mlat“, NET\_BIND\_ADDRESS=„“

That’s not a question 😉

> 1. my processor load decreased from about 15% to 11% on pi2. why is your code obviously better/faster/more efficient?

Lots of incremental improvements, plus if you’re using --oversample you’re using a whole different demodulator which is where most of the CPU goes.

> 1. these were the switches i used with malcolmrobs fork: --net --enable-agc --gain -10 --fix --aggressive --mlat --modeac --net-ro-size 500 --net-ro-rate 5. how about them?

–aggressive is usually a bad idea.  
–modeac isn’t supported with --oversample (it’ll accept it with a warning but you won’t get any Mode A/C data)  
I never had any improvement with --enable-agc  
The gain setting depends on your antenna.  
The --net-ro-\* options may not be needed but they don’t really hurt.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 4:36pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/11 "2015-10-02T16:36:57Z")

</div>

thank you for your answers obj - here is what i did not understand …

> [@obj](#):
>
> > [@TomMuc](#):
> >
> > 1. now i have about 20% more positions reported - are they real received or averaged values?
> 
> I don’t know, where are you looking?

e.g. at port 8080 dump-mutability map screen

> [@TomMuc](#):
>
> 1. in vrs i have about 400% more messages my settings different from default are: EXTRA\_ARGS="–forward-mlat“, NET\_BIND\_ADDRESS=„“

measured from vrs input counter

> [@TomMuc](#):
>
> 1. these were the switches i used with malcolmrobs fork: --net --enable-agc --gain -10 --fix --aggressive --mlat --modeac --net-ro-size 500 --net-ro-rate 5. how about them?
> 
> > [@obj](#):
> >
> > –aggressive is usually a bad idea.  
> > –modeac isn’t supported with --oversample (it’ll accept it with a warning but you won’t get any Mode A/C data)  
> > I never had any improvement with --enable-agc  
> > The gain setting depends on your antenna.  
> > The --net-ro-\* options may not be needed but they don’t really hurt.

depends on the antenna - i was wondering as on github one from flightaware staff wrote that gain -10 is the best value by far and that seems to be their default setting? and what about the --fix switch?

---

<div class="post-metadata">

**Author:** ![obj](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/obj/32/118984_2.png) [@obj](https://discussions.flightaware.com/u/obj)\
**Post date:** [October 2, 2015, 4:50pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/12 "2015-10-02T16:50:40Z")

</div>

> [@TomMuc](#):
>
> > [@obj](#):
> >
> > > [@TomMuc](#):
> > >
> > > 1. now i have about 20% more positions reported - are they real received or averaged values?
> 
> I don’t know, where are you looking?  
> e.g. at port 8080 dump-mutability map screen

The messages/sec figure? That is the raw message rate measured over a 30-second sliding window.

> depends on the antenna - i was wondering as on github one from flightaware staff wrote that gain -10 is the best value by far and that seems to be their default setting?

gain -10 is a reasonable starting point for an unamplified antenna; it is basically maximum gain (even higher than the nominal manual maximum due to weirdness in librtlsdr). For an amplified antenna it may be too high. Either way, it is something that it is worth experimenting with to see if a different setting improves the performance of your particular setup - there is not one value that is right for everyone.

> and what about the --fix switch?

Sure, that’s usually safe enough.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 4:56pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/13 "2015-10-02T16:56:16Z")

</div>

dankeschoen 🙂

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 5:19pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/14 "2015-10-02T17:19:05Z")

</div>

hmmmm - but now i’m confused. where to set values and what is dominat?  
in dump1090-mutability i just have the choice between max and agc here is GAIN in capitals. when calling the help file there is only empty value and -10 and the switch is ‘gain’ in lower. as i have the option in EXTRA\_ARGS= to set all parameters free i ask myself:

→ where best to set e.g. gain to -10 aka agc?  
 → what happens when set on both places - does one override the other which rules?

---

<div class="post-metadata">

**Author:** ![obj](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/obj/32/118984_2.png) [@obj](https://discussions.flightaware.com/u/obj)\
**Post date:** [October 2, 2015, 5:31pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/15 "2015-10-02T17:31:31Z")

</div>

Take a look at the init.d script to see how the command line is assembled from the options: [github.com/mutability/dump1090/ … y.init#L54](https://github.com/mutability/dump1090/blob/master/debian/dump1090-mutability.init#L54)

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 5:49pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/16 "2015-10-02T17:49:19Z")

</div>

ok - i see that you catch empty values and set defaults etc. - but should i really start to decode your coding and what is where done with these variables in other places - instead of a short answer. did you eat a clown for breakfast?

p.s. looks like the direct given values via commandline override the config - but does EXTRA\_ARGS in configfile too?  
p.p.s. at the end you append the EXTRA\_ARGS to the argument-string - but then it’s possible to have them twice?  
p.p.p.s. where all this redundancy in the end good for is - i don’t know - should i?

---

<div class="post-metadata">

**Author:** ![mgunther](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/mgunther/32/78172_2.png) [@mgunther](https://discussions.flightaware.com/u/mgunther)\
**Post date:** [October 2, 2015, 6:28pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/17 "2015-10-02T18:28:57Z")

</div>

> [@mgunther](#):
>
> Hopefully I have something tomorrow.

I need more time for testing and discussions with obj about the best port and format to use. On top of that I need build a new SD card for a new Pi2. I guess it will be a few days.

---

<div class="post-metadata">

**Author:** ![obj](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/obj/32/118984_2.png) [@obj](https://discussions.flightaware.com/u/obj)\
**Post date:** [October 2, 2015, 6:36pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/18 "2015-10-02T18:36:25Z")

</div>

> [@TomMuc](#):
>
> ok - i see that you catch empty values and set defaults etc. - but should i really start to decode your coding and what is where done with these variables in other places - instead of a short answer. did you eat a clown for breakfast?

I think I am done with trying to help here.

---

<div class="post-metadata">

**Author:** ![TomMuc](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tommuc/32/113358_2.png) [@TomMuc](https://discussions.flightaware.com/u/TomMuc)\
**Post date:** [October 2, 2015, 6:41pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/19 "2015-10-02T18:41:57Z")

</div>

thanx a lot

---

<div class="post-metadata">

**Author:** ![heypete](https://avatars.discourse-cdn.com/v4/letter/h/b782af/32.png) [@heypete](https://discussions.flightaware.com/u/heypete)\
**Post date:** [October 2, 2015, 6:45pm UTC](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367/20 "2015-10-02T18:45:37Z")

</div>

> [@obj](#):
>
> > [@TomMuc](#):
> >
> > ok - i see that you catch empty values and set defaults etc. - but should i really start to decode your coding and what is where done with these variables in other places - instead of a short answer. did you eat a clown for breakfast?
> 
> I think I am done with trying to help here.

I, for one, have found the thread quite informative. Thanks for all the information.

[Next page](https://discussions.flightaware.com/t/dump1090-mutability-and-flightaware-big-problems-solved/17367.md?page=2)
