@wiedehopf and I have been discussing this via pm since it was faster and easier and there’s a few things we’ve discussed that may have a bearing on this.
My station is dedicated to ADSB tracking, runs headless, and was sending position data to FlightAware. It is currently an almost two year old system that’s been updated and upgraded along the way. I started sending data to FlightRadar24 since a utility in Flight Simulator 2020 uses their data to put real world aircraft in the sim. (The sim already can do that using FA Firehose data but it’s delayed and filtered/incomplete)
But it’s pretty much always had issues with the MLAT flag on my FA stats page.
I ran the scripts to set up sending data to ADSBExchange since weidehopf has access to the MLAT data if I submit there. As part of that setup, some extra packages got installed and I ran some more updates. Wiedehopf didn’t see anything particularly bad in my data, though. We also verified my GPS location and altitude, I got out an old handheld GPS and verified against the maps and that seemed accurate.
And so far my MLAT flag is still green. It’s an intermittent problem, though. One thing wiedehopf mentioned is I have White Sands in view of my antenna and they apparently do gps spoofing/jamming there and now I know why I see tracks drop out on aircraft flying across the southern part of my state. When they have gps positions but reduced accuracy, I see airlines with minor zig-zag flight paths even as they near KABQ.
I don’t know if it’s strictly for diagnostics or openly known, but wiedehopf set up a map view that filters out all traffic except those with bad gps information - either degraded or missing and interestingly, down south near White Sands is a hotbed. Some web searches show this is well known too. I’d post the link but don’t know if it’s for public use. It’s pretty wild though. When their jamming is active, southern New Mexico lights up. Otherwise there’s just occasional planes at random locations or some in militarized areas of the world.
He also mentioned others around me using inaccurate antenna locations can kind of build in a sensitivity to MLAT positions. I’m going to build a new SD card from scratch and try my station with a fresh build to see if some cruft somehow is contributing to the MLAT flag issue but my guess is there won’t be a difference. I’ve swapped SDR dongles and power supplies. Blue filter, antenna, cable, and Pi are all the same. As noted, there were more software updates that got prompted by the ADSBExchange scripts install.
So I’m on alert, waiting for a red MLAT flag to grep logs and let him know so he can sift the MLAT data to see if we can nail it down, but it could be there’s nothing I can do about it. Still have some things yet to do and investigate but it could all come down to the radio environment where I am.
I’ll update if anything changes or we get more information. I don’t expect it but the Pi will be working slightly differently now that the ADSBExchange scripts are running. I had already done updates and such to move to PiAware 6.1 but some things got updated with that change. It’s now a slightly different Pi OS and app set running.
I really want to thank @wiedehopf for all the help through all this. We spent a fair amount of time sussing things out and getting ADSBExchange all working properly with a bit of frustration from me forgetting my block everything and open holes for specific traffic. The local ADSBExchange page uses port 80 and my box only allowed 8080 (PiAware) and 22 (ssh) until he realized I was blocking 80. Now it’s all 
! (Except for maybe that MLAT flag…)
Here’s what degraded GPS looks like on a DAL tubeliner… Not dramatic but a symptom of the White Sands jamming (I think). Where it drops out entirely (not shown) it’s a dotted line. I thought all those interruptions to the south were signal obstructions by local mountains, but that’s not all that’s going on apparently.
