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.
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.
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.
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.
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.
since yesterday i’m running dump1090-mutability 1.15-dev on my test site.
along mgunthers perfect howto 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 …
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)?
now i have about 20% more positions reported - are they real received or averaged values?
in vrs i have about 400% more messages my settings different from default are: EXTRA_ARGS="–forward-mlat“, NET_BIND_ADDRESS=„“
my processor load decreased from about 15% to 11% on pi2. why is your code obviously better/faster/more efficient?
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?
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.
now i have about 20% more positions reported - are they real received or averaged values?
I don’t know, where are you looking?
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
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.
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.
thank you for your answers obj - here is what i did not understand …
e.g. at port 8080 dump-mutability map screen
measured from vrs input counter
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?
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.
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?
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?
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.
