Same plane positioned on ADSB and MLAT

[whacky]

I wonder how the MLAT server decides when to perform MLAT. I saw this plane on two receivers, one with ADSB position, the other with MLAT position.

Is MLAT is performed only for objects whose position cannot be determined from ADSB? If MLAT is performed on all objects at all times, which position is used on aggregator sites such as FlightAware?

Related to my receivers, if MLAT is performed on all objects at all times, are messages from receivers that report ADSB positions used in the calculation? Are MLAT results fed back into receivers that report the object’s ADSB positions? (If so, what does dump1090-fa or tar1090 do with MLAT feeds on objects for which the receiver has ADSB position?)

[wiedehopf]

@whacky

I saw this plane on two receivers, one with ADSB position, the other with MLAT position.

One of the receivers is for UAT … you could have mentioned that in the question.

It’s 978 add on transponders that are used in addition to an existing ModeS transponder on 1090 MHz.
The mlat-client logic about which aircraft are located doesn’t know about UAT.

dump1090-fa / readsb will use the higher quality position which is ADS-B and ignore the MLAT position.
(tar1090 is not involved as it’s just a webinterface looking at the json)

[whacky]

I should clarify that both receivers are 1090 MHz; they are actually both Pro Stick Plus.

[obj]

@whacky

Is MLAT is performed only for objects whose position cannot be determined from ADSB?

Yes, based on a local decision (i.e. the local receiver will start to feed data for mlat if it does not see ADS-B positions for a while).

It is fairly common to have aircraft that are on the edge of your receiver range which are ADS-B equipped, but where the low signal strength means that only occasional short Mode S messages (e.g. DF11) are successfully received. The longer DF17 ADS-B messages that carry position information have too many errors to be decoded. In that case you’ll see mlat based on the shorter messages until reception improves.

You may continue to receive mlat results for some time after the local receiver stops sending mlat data (either because the aircraft moved out of range, or because you started hearing ADS-B positions). In that case, as wiedehopf says, locally received ADS-B positions will override any mlat results received.

[whacky]

Thanks for the explanation! It is fascinating to learn the delicate dance of local vs server-side decisions. Even more amazingly, this also means that at the same time my second receiver didn’t receive position from ADS-B, there must be at least 4 other reasonably spaced receivers in the same condition.

[foxhunter]

I am using a Jetvision AirSquitter connected to the JetVision MLAT network.
On this i can filter the view from which sources the aircraft are displayed.

If i select an aircraft which shows as MLAT, it is displayed then as ADS-B if i disable MLAT for a moment as source for the map.

Example is this Helicopter. In the first view, all sources are enabled, in the second view i disabled MLAT, so the source is shown as ADS-B

I assume the device is displaying it on the most reliable source at the given moment.

[JRG1956]

@obj

You may continue to receive mlat results for some time after the local receiver stops sending mlat data

Do you have a sense on the upper bound time for continuing to receive mlat data after the local receiver stops sending?

Every few days I see a red MLAT status on my FlightAware web page (I think attributed to processor load or timing issues) - I have been ignoring this because I can still see mlat aircraft when I check my local feeder page. MLAT usually comes back online within 30 minutes or so of me noticing (I haven’t sat there waiting for it go green, so that’s just based on when I remember to look again), and it doesn’t seem to be affecting my site stats.

Does the MLAT status update in real time or is the a better way to check current MLAT status?

If the issue is real, I think the issue could relate to highly variable packet latency due to my use of a mobile broadband connection. Is that a possibility?

[obj]

@JRG1956

Do you have a sense on the upper bound time for continuing to receive mlat data after the local receiver stops sending?

3 minutes.

@JRG1956

If the issue is real, I think the issue could relate to highly variable packet latency due to my use of a mobile broadband connection. Is that a possibility?

Your data needs to arrive no later that 2.5 seconds after the first copy of the data arrives from another receiver. High latency could interfere with that, but it really would need to be high latency (>1 second)

[JRG1956]

Thanks @obj,

I will work on the assumption that if I can still see mlat aircraft on my local site more than three minutes after noticing a red MLAT status flag on my FlightAware page, then mlat is probably fine, despite the status message.

I was probably on the wrong track when I asked about latency variability, but will try pinging the FlightAware server to get and idea of how consistent the round trip time is - I doubt it would be drifting out to higher than a second.

Quoting from an old thread (2016 vintage - I assume it hasn’t changed, but I hadn’t noted down the exact current message) the message associated with the MLAT warning is:

“…This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU”

I was confused by the reference to feeder having unreliable timing information - if I’ve understood how MLAT works correctly, my feeder isn’t using its internal clock at all, just counting pulses to establish a time difference relative to receipt of another aircraft’s position message. So it isn’t the feeder’s “timing” that is the problem, its is either an incorrect location or the feeder is overloaded and taking too long to count the pulses and calculate the time difference?

[obj]

CPU load is usually not an issue these days (it was more of a problem back in the Pi 1 days).

Incorrect locations will show up as timing problems (because the compensation for the propagation delay from an ADS-B beacon aircraft to the receiver is using an incorrect distance)

Actual timing problems show up as timing problems! If you have a dongle with an uncompensated crystal then the sampling rate can drift significantly; if it drifts too fast or too far for the mlat server to compensate for, then you’ll see timing errors.

USB bus errors or bandwidth problems also show up as timing errors. rtlsdr dongles can silently drop samples in those cases, and that looks to the mlat system like the clock has suddenly stepped (e.g. a signal that was expected to arrive at around sample-count 10000 actually arrives at sample-count 8000, because the dongle silently dropped 2000 samples).

[JRG1956]

Thanks for the clarification - my memory is getting worse by the year!

I had been so focused on the RasPi4, that I’d forgotten about the receiver having an oscillator and the potential for USB issues to manifest as MLAT problems. I’m using an Airspy Mini, and remember running into problems when trying power it through long, thin-conductor cables. That problem was obvious - MLAT simply didn’t work. Current cable is 30cm, 24 AWG so voltage drop is minimal, but I could be having intermittent temperature issues with the Airspy. It is summer here and the RasPi can hit 70 Celsius on very hot days, but generally peaks below 65C most days.

I will investigate further - thanks for the advice.

[pete3500]

Fun fact everyone here probably already knows, but I’m throwing it out there just for funsies. It’s pretty common knowledge that all the ADS-B data piped into the FAA’s air traffic data system (I can’t remember the official name, and it’s probably changed since I was briefed) is added to all the other air traffic surveillance data sources (PSR, SSR, etc.) with the track being displayed to controllers representing the weighted average of the differing data, the weighting of each varying based on some algorithmic sorcery. That’s not the fun fact, though. The fun fact is based on how and when the FAA systems leverage the MLAT calculations for these aircraft.

Remember when they invented ADS-B back in the 90’s? Remember how those were the good ole days of pre-9-11, when with few exceptions, bad stuff generally happened over somewhere else, because we were good to go here in the US? So, pre-9-11 the FAA culture, and the company line was essentially something to the effect of “Safety of Flight Over Rules EVERYTHING!”. While in many ways, that’s still the company line, or at least it is when things like 737 Max debacles are not happening. One of the aspects of our society nowadays has forced the hand of the FAA, and they must now say “Safety of Flight Over Rules EVERYTHING…except national security”.

Back when the system was being developed up in the Capstone project in Alaska, and to a limited extent parts of Colorado, the FAA still believed that civil aviation was the global equalizer that no matter what, everyone could agree on. Because of this culture, I would be surprised if the question of signal validity or nefarious use of the ADS-B system was ever raised. If so, I know for a fact it would have been shot down in an instant as not aligning with their safety-of-flight says HELL NO" mantra.

Wanna guess how often those issues were raised after the 9/11 attacks and the subsequent realization that there are many in this world who would LOVE to mess with a Superpower’s air traffic surveillance system? Much to the frustration of the new DHS leadership, by the time the FAA thought to apply even basic encryption protocols to their new and rapidly integrating ADS-B surveillance system, it was too late to act, or at least that was what they claimed. “The users can’t be asked to foot the bill for a complete rebuild of a system they just only recently agreed to equip for”. In other words, the airline executives didn’t want to have ask the government for another hand-out so soon since the last one, bad timing. So what to do? Enter in, smart people.

I would think that the computing power required to do this would be absolutely off the charts, but I am not a smart person. Soon after 9/11 occurred, the FAA could only take DHS and DoD fist pounding for so long. Someone was going to either spoof ghost aircraft into the NAS surveillance system and create utter chaos using a €2500 ($3000) software defined radio, and they were actually trying to shut it, ADS-B, off. DoD agreed to take custody of enough domestic PSR systems before the FAA mothballed them all (a plan since revamped), but what about unencrypted data flying through the air?

Every single ADS-B transmission which includes the aircraft’s GNSS/ INS calculated position, as well as a handful of other obscure data packets no one cares about, is validated in real time, as it’s piped in, using MLAT to cross reference the position. If the position falls within whatever is considored an expected or acceptable position delta, the ADS-B data is allowed to continue into the greater NAS surveillance monster. However, if the signal is found to differ from the calculated MLAT position beyond that acceptable difference, the ADS-B signal is diverted to a holding ‘bucket’, and retained for some duration of time in the event there is further scrutiny. This eventually led to the FAA’s Aircraft HEXCODE Blacklist for repeat offenders. They found that the vast majority of these flagged positional data packets weren’t the bad guys trying to reap havoc on the US. It was shoddy ADS-B Out system components and installation, mostly from the humble General Aviation community.

Anyway, fun fact that took longer to work through then I originally thought. If you want, you can print out this book I just wrote and I’ll sign it so you can impress all your friends!!!

[wiedehopf]

@pete3500

create utter chaos using a $25 software defined radio,

SDRs for $25 are receive only, not transmit.

[pete3500]

LOLOL That WHOLE post and THAT’s what you pull out to bust my stones with!?!?! LOL You’re absolutely right, but maybe I just missed the “0” key! LOL Well, to address that valid point, if Mr. Terror McTerrorist is clever enough to make that little box do what he wants, they could be $25,000, and it wouldn’t matter. Unfortunately, bad people are not stupid, so luckily the FAA played a little catch-up before they saved up enough to buy one!

[wiedehopf]

@pete3500

LOL You’re absolutely right, but maybe I just missed the “0” key!

So just fix it.
I never implied that your reasoning was flawed in regards to ADS-B spoofing.

[pete3500]

Well, the error was mine, I didn’t mistype, I was just playing around about fat fingering it. For the record, I took no offense to your call out of the error, and to be a good sport, I’ll correct the error.

Let me ask you this, the RTL-SDR RTL2832U crashed the SDR reciever party and ended up causing the legacy SDR manufactures to up their game or introduce a more entry level SDR unit to the marketplace (at least that’s the story I read about it). I’m not sure if I would have any practical use for a SDR transmit capability, but do you guys, most who have been involved in this community for years longer that I have, see a similar type situation potentially occurring with another industry disruptor introducing a ultra low cost transmit capable SDR at any point?

Did anyone see the RTL-SDR digital TV tuning dongle’s sudden introduction into the recieve only SDRs? I think that’s every small business owner with a hand in innovation’s dream! “Look everyone, I reinvented the cheese grater into the Grater5000, which sells for $25. And Bob the random hacker made some mods to the Grater5000 and now it’s an autonomous stealth drone with a range of 5,000 miles! Anyone interested???!!”

Ok, I’ll correct my mistake.