MLAT client statistics


Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Receiver status: connected
Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Server status:   synchronized with 53 nearby receivers
Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Receiver:  776.7 msg/s received      382.3 msg/s processed (49%)
Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Server:      2.1 kB/s from server    0.0kB/s TCP to server     4.1kB/s UDP to server
Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Results:  936.7 positions/minute
Sep 23 07:37:26 raspberrypi piaware[597]: mlat-client(741): Aircraft: 75 of 113 Mode S, 18 of 66 ADS-B used


Perhaps this has been answered elsewhere and I apologize if so, however I’ve been wondering how this is processed: Apparently ~50% of the messages are being dropped assuming this is post-process of dump1090, which I assume would only be feeding valid MODE-S messages in the first place. What must one do to increase the hit-rate of these messages and what is causing this many packets being dropped? Coordinates and altitude should be spot-on for this setup - PiAware 3.0.5, running behind mutability. FEC is enabled per standard conf parms.

You actually want that percentage to be as low as possible really.

mlat-client’s main processing loop is all in Python and it is relatively expensive to process messages there. There is a C extension module that takes the raw TCP data, packetizes it, and passes only “interesting” messages up to the Python layer to reduce the cost of processing messages in the Python layer that aren’t actually useful.

The percentage tells you what fraction of messages got passed up to the Python layer. More messages being passed up means more CPU used.

“interesting” messages are either:

  • ADS-B messages for ADS-B equipped aircraft that the server has picked to use for synchronization; or
  • Mode S messages from non-ADS-B aircraft where your receiver has been selected to forward data for multilateration (this requires sufficient nearby receivers hearing the aircraft; also load gets distributed when there is a high density of receivers)

It is normal to only be processing a fraction of the total traffic received.

Thank you for the quick clarification. I had a peek through coordinator.py and it started to make more sense after digesting your reply.

Alright, have an interesting caveat, decided to post it here since it deals with MLAT reporting.

I reconfigured for the sake of testing to have the Pi3 boot and run from a USB stick (no host sdcard inserted), running the same configuration with dump1090-mutability and Piaware 3.0.5. Time zone is set, ntpq is showing a good ntp configuration pegged to stratum-1, everything appears to be running smoothly with the exception of MLAT. It reports clock unstable with a big fat zero for Mode-S - when viewing map, MLAT appears to be popping in and out and collectd graphs ultimately end with an MLAT flatline. I power off, re-insert the sdcard, power back up (system running on sdcard again) and MLAT pops in within 30 seconds or so - solid again. Is MLAT reliant upon some sort of timing pegged on the sd slot?!? The contents of the sdcard was rsynced to the USB stick with the only changes between the two being boot config and fstab to allow for mass storage boot, so other than no sdcard being present in the slot, hardware and software are identical during the test. Nothing funky in dmesg that I could spot. Have tested this 3 separate times all ending with the same result - borked MLAT when no sdcard is present in the slot. I gotta be missing something simple. Ideas?

No, but it is dependent on getting a continuous stream of sample data from the dongle, as it does all its timing by counting samples. The dongle USB implementation is not great and seems quite sensitive to bus noise or other devices on the bus, I would guess that having root on USB adds enough USB traffic that some sample data starts getting dropped.