I’m still in testing my UAT unit. Everything works just fine, I just haven’t made the leap to buy the expensive antenna and place it outside. It’s currently a stock antenna sitting on my 3D printer with plenty of structure above it. It doesn’t get much traffic right now and it shouldn’t. However, sense MLAT has come out, when the antenna does pickup an aircraft, MLAT data is often used instead of the UAT data. MLAT is, at best, an estimate. UAT isn’t. It’s accurate (Just as good as 1090ES). I suggest there be a way for UAT feeders to be identified and for UAT data to be prioritized over MLAT. Otherwise, the more accurate data will (mostly) keep getting pushed aside over the less accurate data.
I assume you’re using uat2esnt?
Yes. It’s all your software.
How would this work?
Send the UAT data to the servers that are decoding MLAT to say don’t bother with MLAT decode - this is the accurate data
Then what do you do with all the 1090 receivers that would contribute to the MLAT decode? - pass them back the UAT information with a flag to colour them as UAT and not feed the data forwards?.
(we have to remember that there still is no data connection the FA end to integrate the MLAT data with ADSB data)
It is probably mostly just a case of inhibiting use of mlat positions within dump1090’s tracking logic for a short time after receiving a non mlat position
There is also a more interesting thing to do here (blue sky…) which is to do mlat on everything - ads-b or not - and use the mlat positions as a sanity check on what the aircraft is reporting. There are lots of transponders out there reporting crap ADS-B positions - not even “out by 10km”, more “completely random data”. Luckily they usually also report a very low accuracy value.
I have a daily FedEx cargo flight that does that. It ‘lands’ (on the taxiway) and then it goes a mile off the runway and then taxis through the fields to the cargo terminal.
Same plane everyday. Clearly their ADS-B unit is wonky. It’s also the only plane I see daily that does not turn off their transponder on the ground.
Then it takes off next to the runway. 
… but most stations won’t be equipped to receive UAT - so they’ll still say “I have these position-less signals as MLAT candidates” to the MLAT server
… assuming that there are enough receivers to produce an MLAT position, but then again it doesn’t need a full |MLAT position calculation … the signal from just one receiver is sufficient to produce a sphere of possible positions (assuming the station position is correct) and if the position reported is not on the sphere then the confidence goes down.
If I understand correctly the radius of the possible position sphere correspond to the time delay between the signal being transmitted and received. Once you have tow receivers - you have two intersecting spheres - the aircraft should be on the circle produced where the two spheres intersect … and will be at one of two points if the reported altitude is correct.
Get three receivers - you have three spheres intersecting = 2 possible points (one would probably be at a negative altitude)
More than three, you can start doing statistical averages on the position.
Well, sure, but I thought the problem here was one of local display. Obviously FA can make decisions about whether to use mlat data or ADS-B (be it 1090ES or UAT) data internally, there’s nothing special needed to make that happen.
[quote=“obj”]
There is also a more interesting thing to do here (blue sky…) which is to do mlat on everything - ads-b or not - and use the mlat positions as a sanity check on what the aircraft is reporting. There are lots of transponders out there reporting crap ADS-B positions - not even “out by 10km”, more “completely random data”. Luckily they usually also report a very low accuracy value.
… assuming that there are enough receivers to produce an MLAT position, but then again it doesn’t need a full |MLAT position calculation … the signal from just one receiver is sufficient to produce a sphere of possible positions (assuming the station position is correct) and if the position reported is not on the sphere then the confidence goes down.
If I understand correctly the radius of the possible position sphere correspond to the time delay between the signal being transmitted and received. Once you have tow receivers - you have two intersecting spheres - the aircraft should be on the circle produced where the two spheres intersect … and will be at one of two points if the reported altitude is correct.
Get three receivers - you have three spheres intersecting = 2 possible points (one would probably be at a negative altitude)
More than three, you can start doing statistical averages on the position.
[/quote]
Close, except that you do not know the time delay between the signal being transmitted and received; you know the reception times at different receivers, but you don’t know the transmission time. The equations end up looking like: t0 = |P0 - A|/c + D; t1 = |P1 - A|/c + D; t2 = |P2 - A|/c + D; … where t0 t1 t2 are arrival times, P0 P1 P2 are (vector) receiver positions, A is the (vector) aircraft position, c is the speed of propagation, and D is the unknown offset between the transmission time and the receiver clocks. You solve for A and D. The solutions look like one-sheeted hyperboloids for each pair of stations. One receiver on its own doesn’t give you anything particularly useful. More than one and you’re looking at intersecting hyperbolas, which have various different ways they can intersect.
But actually for overdetermined cases (which is how mlat works here) it’s easier to not even worry about the exact solution and just throw it all into a least-squares solver.