This morning around 6am UTC PiAware showed me an aircraft with a solid signal flying up in Scotland around 260 NM away, beyond my 40K horizon, apparently flying at 10,000 ft. The data source was showing as ADS-B.
I checked FR24, which I feed from the same data, and that showed the aircraft as coming in to land at Manchester Airport, which is a short distance away, and showed its data source as MLAT, which I don’t feed to FR24.
Therefore it looks like FR24 showed the correct position and data source, based on other MLAT feeders. Whereas my PiAware was presumably also seeing it via MLAT but calculated the wrong position and incorrectly showed the source as ADS-B. This wrong calculation effect is mentioned in another thread, but I’ve not had it happen before, and no mention of why the data source is listed incorrectly as ADS-B.
Just wondered if anyone else sees this happen now and again?
This was the flight in question, and this is the tracklog. I saw it on my map at 0550 UTC which is when FlightAware is reporting a gap in the data and was not yet tracking it via MLAT. It shows the first MLAT calculation at 0601 UTC. Before the gap it was tracking it via ADS-B.
Could that be related to why PiAware said this was an ADS-B position even though it was in fact an MLAT position with the wrong solution displayed.
Interesting, thankyou I’ve not heard of this or seen it happen. Can you help me understand what I’m seeing on this map? Is this track some combination of correct ADS-B position, spoofed ADS-B position, correctly resolved MLAT position and incorrectly resolved MLAT position?
Edit – I see that for all parts of the route where it is offset, the source is listed as ADS-B (the spoofed more northern ADS-B). For all parts where it is correct, the source is listed as MLAT (which presumably cannot be spoofed although in some cases the wrong solution can be settled on based on timings, as per that previously linked thread). So MLAT, where it is available to be used, is exposing the spoofed ADS-B in this case.
Where is the spoofing coming from? Is it happening on the aircraft, presumably for some reason known to its operators? Or is this something malicious taking place from the ground and targeting certain aircraft? I suspect not since that track shows it all over the place across multiple countries.
Why did FR24 show the correct position? It was reported there as MLAT, so presumably the spoofed position was being ignored or overriden by MLAT calculations. Screenshots I happened to take from FR24 below.
And presumably then, my PiAware was not suffering from the wrong MLAT calculation. It was not using MLAT – it was reporting the spoofed ADS-B position and correctly describing the source as ADS-B. That would explain both those observations.
No there was no ADS-B position, only then the MLAT position is used for the trace linked.
Yes that can be done differently like FR24 overrides ADS-B with MLAT. But it’s not. Has pros and cons.
Like you being able to compare to the data you got locally.
Oh you’re not in the loop.
Russia had been jamming for a couple years but they started spoofing a year or so ago.
Not sure if it’s only Russia though.
Not quite.
That ADS-B position was just wrong due to bad GPS / transponder software on the 787.
The spoofing was at some point during the flight and the flight crew didn’t reset the relevant systems i believe. I assume that’s what most 787s are doing. Or they got a software update i don’t know.
Other types also suffer from the spoofing, but once they leave the range of the spoofing transmitter, the ADS-B position works correctly again.
You might find this site of some help:
2 Likes
I am running AIS-catcher which has a new feature to show an ads-b feed from a beast source on the same map.
It does not check or filter any impossible data out, yet, things like this
In this case, this might be just bad data, but very often there planes which are outside the possible range, but not by that much. They disappear after a few seconds, again that might point to bad data?!
Or here
That’s more likely to be the ais catcher algo not filtering out implausible jumps in position.
CPR decoding is complicated and when aircraft cross a CPR zone boundary, you can’t combine the odd and even messages, gotta wait for fresh ones or do a local decode.
Could also be bad data but i doubt that to be honest, it’s too many. Well unless you run 2 bit CRC correction. But even then it’s too much.
Also … thread hijacking with an unrelated issue -.-
Maybe delete and re-open.
Evidently not! I heard about Russia and Ukraine messing with each other’s GPS, but didn’t realise it was messing with other aircraft.
The track jumps between the correct one and a more northern incorrect one. Clicking along the track shows that the latter is sourced from ADS-B, the former from MLAT. So MLAT is exposing the ADS-B position as incorrect. Whenever the source switches to MLAT the track returns to the correct position. That’s what I was getting at. An example from one segment of the track at the link you posted:
Exactly – I had to be using that source for me to see the wrong track. I originally thought that the position was wrong due to a bad MLAT calculation and that PiAware was also incorrectly reporting the source as ADS-B. Now I can see that the source was indeed ADS-B and was correctly reported as such by PiAware, however that source itself was wrong due to this spoofing issue. Had I been using MLAT at that point I would have seen the correct position, as FR24 did.
I meant this as an example for gps spoofing, but while writing I thought more likely it is bad data, and not spoofing. It was not meant as an call for assistance, but thanks anyway!
