much appreciated! sorry for my missing the forest through the trees - so the aircraft-data-sets where i find the (always empty) sub-key ‘altitude’ are the ones that are entirely computed without transponder altitude? or in other words example1 has the less altitude precision than example2 ?
It’s not a key, it’s just a data value (the value containing it is an array, not an object)
You can’t distinguish the no-transponder-altitude case currently. The “mlat” key just tells you the datasource of various fields. A “mlat”-sourced altitude means that the altitude came from a mlat result, it doesn’t tell you about the inputs to the solver.
finally i got it so my guessing that i could differentiate the altitude-quality in mlat results by the different behavior: “mlat”:[“lat”,“lon”,“altitude”,“track”,“speed”,“vert_rate”] vs “mlat”:[“lat”,“lon”,“track”,“speed”,“vert_rate”] was false. i was just wondering if there is any meaning that i can use from this different behavior …
the second thing i was wondering if this-altitude thing reflects in key ‘nucp’ and what the exact meaning of the different values (mostly 0 or between 7-8 at my site) is? but i see i have to dive into dump1090 sources again and start learning about. that’s not easy but a good lesson in coding too
nucp is the Navigation Uncertainty Category - see the ADS-B specs (v0; later versions replaced it with a different set of measurements, but dump1090 hasn’t caught up with that yet). mlat results will always report 0 here.
that’s why i said i’m quite happy with flightaware mlat. this is an airport 4 miles away from me without direct sight - anyhow i get nearly always such perfect mlat positions and altitudes down to 50-100 feet above their runway. and over here in my neighborhood we have very very few sites. so in my eyes this is a great result!