For everyone interested in this…
Install glibc-2.29-r0.apk + glibc-bin-2.29-r0.apk (and libstdc++) in Alpine to get it working.
My current image sizes according to portainer:
Dump1090: 9,5 MB
Piaware + mlat-client: 75,7 MB
FR24feed: 14,2 MB
Saturnus' topic on getting a better Dump1090 etc. understanding, toward the ultimate setup in Docker
Hi guys.
Is it okay to ask about FlightRadar24Feed here or is that inappropriate?
If ok, then the question is if it is possible to get their MLAT results piped to Dump1090/VRS. I could not find any information on this, and thus, conclude that they do not support this.
They don’t provide any MLAT results to feeders, which really is a pity.
1 Like
Lame. I might ask them on the forums why not.
Something else…
What do you make of this Dump1090 stats.json:
"total":{"start":1564747377.1,"end":1564762797.2,"local":{"samples_processed":37008179200,"samples_dropped":0,"modeac":0,"modes":349691479,"bad":221497417,"unknown_icao":119852055,"accepted":[8342007],"signal":-7.6,"noise":-20.5,"peak_signal":-0.6,"strong_signals":525812},"remote":{"modeac":0,"modes":126005,"bad":0,"unknown_icao":0,"accepted":[126005]},"cpr":{"surface":1,"airborne":509381,"global_ok":462321,"global_bad":3280,"global_range":2769,"global_speed":489,"global_skipped":957,"local_ok":33103,"local_aircraft_relative":0,"local_receiver_relative":0,"local_skipped":10678,"local_range":7706,"local_speed":2971,"filtered":0},"altitude_suppressed":0,"cpu":{"demod":3966985,"reader":724621,"background":186961},"tracks":{"all":1295,"single_message":83},"messages":8468012}
Yesterday I took the setup apart for some measuring in preparation of the outside placement in a few weeks. Since then…some trouble according to the stats. After some coaxial adjustments, the aircrafts amount is probably on track again, but positions amounts according to FA en FR are a bit degraded. I have no stats.json from before but what I see is that the “bad” field has a high number. What to make of that?
1 Like
Good joke 
Which dump1090 version are you running?
Versions prior to mutability 1.15 have worse decoding.
The really developed version is dump1090-fa, so i would recommend using that.
1 Like
haha.
Dump1090-fa v3.7.1.
Ah i missed the “before” the last time i read it.
You can turn the gain down a notch probably.
Receiving a lot more ModeS preambles than messages that most likely are just noise is completely normal.
Those fields in the stats correspond to these lines in the console stats output that can be turned on:
Aug 02 12:03:28 pi dump1090-fa[13151]: Local receiver:
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 samples processed
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 samples dropped
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 Mode A/C messages received
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 Mode-S message preambles received
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 with bad message format or invalid CRC
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 with unrecognized ICAO address
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 accepted with correct CRC
Aug 02 12:03:28 pi dump1090-fa[13151]: 0 messages with signal power above -3dBFS
Is it possible that the antenna is in a better position after reassembly and due to the high gain gets more overloaded, leading to actually a worse positions number with a better antenna position?
Which stick are you using?
It’s possible the interference is overloading the builtin LNA. This happens in some situations with the Pro Stick Plus. A better antenna position could be the reason.
You can always reduce the gain and see if that helps, but i doubt it’s the problem.
Yes Pro Stick Plus + Stanislav 1090MHz antenna. Setup is still inside the house now, on a good position. Once outside, it will be in clear view and should be quite a lot better. There should not be much interference here (but maybe I should test this somehow), on the outer area of a flat 50.000 population village/city.
Inside the following holds:
Impossible to tell which position is good, only way is to test.
Anyway reduce the gain a bit.
Will reduce soon.
Currently still gathering data to be able to compare to last week. Reducing now would introduce a second factor.
Well that’s not quite true.
When the signals are stronger, you need to reduce the gain otherwise the added signal which is normally useful, might create problems.
So to really compare two locations, you should aim for the same number of messages >-3dB roughly and then compare the results.
Ok, so to tune the gain for each hardware change.
The location was not really changed btw. I adjusted the N-SMA pigtail a bit that 1) seems to have loose ends unless you push the cable towards the connectors and 2) is actually RP-SMA so I am using a self made copper pin/bridge which was a bunch of wires before and now solid piece of copper from electricity wires sanded by machine and hand. Both these issues will be eliminated by installing a direct N-SMA adapter in the outside setup, so will just live with it for now. I cannot install that direct adapter yet because it has to be covered by pipe, otherwise reception is very bad. A know phenomenon to the antenna builder apparently. Current pipe is too long and thus the USB stick won’t fit underneath. I might saw it off later and then also test that factor (direct adapter) before going outside.
@wiedehopf
Hi I am onto your software now. GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
The thing is, I am not running Dump1090 with webinterface. But I do have the stats.json available locally.
I guess collectd.conf and especially dump1090.py needs to be adjusted from url to file then?
I could try to modify it but probably I will break it.
Why not?
You need the webserver anyway for serving the graphs.
You could just hardcode in dump1090.py
Find where it downloads the files and figure out how to read it from a path.
Edit: Easy solution:
Make a directory and a symlink to /run/dump1090-fa:
mkdir /usr/local/share/dump1090-data
ln -s /run/dump1090-fa /usr/local/share/dump1090-data/data
And as URL line in collectd.conf:
URL "file:///usr/local/share/dump1090-data"
This is a little hacky but is required because dump1090.py appends /data to the URL it gets 
But it’s easy enough to work around.
The stats.json is available locally but only because it is ‘mounted’ from a remote location.
Hmmm maybe I could mount that stats.json inside the lighttpd webserver then host it via http that way. Bit clumsy, so I will try your way.
And you can’t connect with http to that remote?
Or the remote isn’t running a webserver?
Anyway many solutions.
This is actually great, now my collectd will continue collecting data even if lighttpd doesn’t like to run because of the configuration or something 
Less gaps in my data, because i often restart lighttpd or do some shenanigans.
The remote is a Docker container that only runs Dump1090. To stick to my project mission/vision I cannot run lighttpd in the same container.
You need Docker man!! A lighttpd per site that you run.
So … where do you have the webinterface?