Saturnus' topic on getting a better Dump1090 etc. understanding, toward the ultimate setup in Docker

GitHub - flightaware/piaware_builder: Debian package builder for piaware

Yeah I checked that out, and tried it too but it’s for Debian. Not working on Alpine.

Or if you mean something else maybe… Downloaded as zip just now and scanned the files for ‘faup’ and found piaware_builder/rules at master · flightaware/piaware_builder · GitHub
That is the way to obtain faup?

EDIT: Tried it out and that indeed seems to be the case. faup1090 is build from the dump1090-fa package. :slight_smile: :+1:

I mean yeah you’ll have to figure out how to adapt the piaware_builder to Alpine.

Seems you found the appropriate build files.

./sensible-build.sh stretch

Try that and then check the package directory.
You can also do that on debian and copy over the package-stretch to your Alpine.

Then make the compilation work.

Yeah to be honest i don’t really have a clue how to compile that stuff on a non-debian system.
Don’t think it’s really meant to be compiled on a non-debian system.

Compiling works as long as the required programs and libraries are available for the distro. Open source helps a lot. I think FR24Feed is closed source thus compiling isn’t even possible. Have to replace the busybox base of Alpine via chroot or something, will see about that next week when time is available again. Also going to set up MLAT inside the same image as the main Piaware stuff then.
So the progress is quite good. It’s like getting it to work first and then smashing around with a hammer to make the package smaller then drilling a little hole/channel for the userdata to come in and finally polishing. :crazy_face:
Thanks for all the help, back at it next week.

Quick question while I am on the go for a few days…
Got fa-mlat-client working as a program but no MLAT results in stats. It is started by Piaware with these options:

allow-mlat yes
mlat-results yes
mlat-results-format beast,connect,172.19.0.19:30104 beast,listen,30105 ext_basestation,listen,30106

Log:

2019-07-13 12:22:51Z mlat-client(251): fa-mlat-client 0.2.10 starting up
2019-07-13 12:22:51Z mlat-client(251): Using UDP transport to 70.42.6.156 port 8559
2019-07-13 12:22:51Z mlat-client(251): Listening for Beast-format results connection on port 30105
2019-07-13 12:22:51Z mlat-client(251): Listening for Extended Basestation-format results connection on port 30106
2019-07-13 12:22:51Z mlat-client(251): Input connected to 192.168.1.19:30005
2019-07-13 12:22:51Z mlat-client(251): Detected BEAST format input
2019-07-13 12:22:51Z mlat-client(251): Input format changed to BEAST, 12MHz clock
2019-07-13 12:22:51Z mlat-client(251): Beast-format results connection with 172.19.0.19:30104: connection established
2019-07-13 12:37:51Z mlat-client(251): Receiver status: connected
2019-07-13 12:37:51Z mlat-client(251): Server status:   not synchronized with any nearby receivers
2019-07-13 12:37:51Z mlat-client(251): Receiver:   68.0 msg/s received       14.8 msg/s processed (22%)
2019-07-13 12:37:51Z mlat-client(251): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.2kB/s UDP to server
2019-07-13 12:37:51Z mlat-client(251): Aircraft: 8 of 8 Mode S, 5 of 6 ADS-B used

Does not change after a few hours.

Is this normal? Maybe no results because my non-development setup with much better antenna is working from the same lat/lon location? Because I saw no MLAT hits anymore since the day of starting the pro setup.

Probalby your clock is not stable.

dump1090-fa likes to run on real hardware so no USB data is lost.

Run rtl_test after stopping dump1090:

rtl_test -s 2400000

Until a second after startup some lost samples are acceptable.
After that, any lost samples will be a problem for MLAT.

How much time offset is acceptable? At this moment it’s ~3 seconds ahead.

The Ali stick is fit in a Windows computer, directly passed through in Virtualbox to Ubuntu Server, then fed to a Docker container. No emulation/simulation.

Maybe the stick itself broke already. Will do rtl_test later today.

The system time being somewhat accurate doesn’t hurt.
One normally runs some sort of time synchronization.
systemd-timesyncd or ntp is both acceptable.

But that’s not the clock i’m talking about.
I was talking about the MLAT pseudo clock which is basically just a sample count.
Very simplified:
Every amplitude reading from the SDR is called a sample.
You should get 2.4 Million samples per second. (2.4 Megasamples/s)

You count those samples.
If some samples are lost due to the USB bus not being capable of transmitting all of them, then you lose your clock.
It’s unstable.

Virtualization can be enough of a problem for USB latency and dump1090-fa working sufficiently for MLAT.

Understood, thanks!

I was unable to test on the holiday, but continued yesterday at home. Seems you are right about the forwarding of USB to a VM. It surprises me because I expected an almost ‘native forward’ since the device becomes unavailable in the host after forwarding, I think it even disappears.

Both the Docker container and the base OS (=VM) reported data loss. I plugged the stick into a RPi 3B+ and there was no loss any more in the Docker container. Used that opportunity (x86_64 → arm) to test out my Docker build code and that went pretty well.

mlat-client(16): Receiver status: connected
mlat-client(16): Server status:   synchronized with 107 nearby receivers
mlat-client(16): Receiver:   12.9 msg/s received        4.2 msg/s processed (33%)
mlat-client(16): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.1kB/s UDP to server
mlat-client(16): Results:  1.5 positions/minute
mlat-client(16): Aircraft: 2 of 2 Mode S, 0 of 0 ADS-B used

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

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 :smile:

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

:cry: 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.