It seems that someone in the South East Queensland area of Australia has bad location settings for their transmitter... There seems to be significant deviation from other positions obtained from FA etc, it happens when a/c get closer to the Sunshine Coast where there are 2 receivers, we've spoken to one, he replaced his rtlsdr dongle and now has better PPM .. But it hasn't solved the problem. I am guessing it's the other one up there, a friend is attempting to contact them now.. I think the main thing is the margin for error might need to be tightened and possible reject receivers which seem to be out of consensus with the rest..?
I can look into the MLAT side of things. It shouldn't matter with ADS-B traffic that's transmitting lat/lon.
I did write a python script that can get GPS WAAS 3D coords with altitude using software. I'll try to have it in the next release.
If I recall a conversation I had with Oliver a couple of years ago when the mlat client stuff came out, it's the height of the antenna that matters most. How much deviation is there before it starts causing problems?
You probably know this already but for those who don't. TLDR; The goal here is to calculate the position in space of the source of a transmission, based on the difference in the time of arrival of the signal at different receiving-stations placed in known locations. If clocks are not in sync then it can create large errors. The way MLAT works is it uses signal strength (with transponder emitted altitude)(with time-stamp) to calculate a probably curve - then lines up all those probability curves. So we know how fast RF travels and we know where LAT/LON of the various feeders receiving the signals. We know the curve of the earth (roughly) even though it bulges in the middle (not perfect sphere). That's also why MLAT feeders need to have their clocks synced; because we're comparing the time-stamp of when packet was decoded. [TDOA = Time Distance of Arrival] Time not in sync will create large errors. Realistically MLAT in 3D space is also calculating angles; then solving a huge matrix to get the 'best possible estimate' of the position of the transmitter. Feeder position is ECEF ("earth-centered, earth-fixed"), also known as ECR ("earth-centered rotational"), a geographic coordinate system and Cartesian coordinate system, and is sometimes known as a "conventional terrestrial" system. It represents positions (in meters) as X, Y, and Z coordinates. So is is where height of the antenna could throw in some errors; but nothing significant. Antenna height is going to have to do more with reception range. In theory, when there are enough feeders the overlapping (THE SOLUTION, POSITION OF AIRCRAFT) curves and ECEF estimates would eliminate the bad actors - AKA those with the wrong LAT/LON in the receiver or bad data. The MLAT server has some checks in the solver to look at the resulting position and see if it makes sense. We might be able to tighten the max range of an acceptable MLAT position and see if that helps or makes it worse. It likely won't make a difference if that MLAT is only slightly off. MLAT is also on the way out once ADS-B adoption becomes the standard. MLAT needs receivers - the more the better. Accuracy decreases with less than 5 in range. 4 feeds are needs to get an estimated position. It would be nice if Oliver was still making improvements to the server and the clients.
Here is something just to show even having good MLAT syncs - when the signal is flaky you get jaggies ... Mode S police helicopter.
Out here in the Seattle area there seems to be about 4 out of the 50+ stations that my station syncs with that consistently provide sync errors that are off by as much as 200 uS. I looked at one of them and they are syncing with 37 other stations and they are poisoning 32 of them. The strange thing is that there are 5 stations they sync with that they are within a few tenths of a uS of. How does that even happen? Do those few stations all share the same bogus time source?
They don't share a bogus time source, the time source works intermittently, as in USB data get lost most often due to low voltage. When USB data gets lost, the time source doesn't advance as it should, so the clock is now wrong compared to before. There is no absolute clock used, it's just a free running counter that counts the samples coming from the receiver. (well the system clock is used as well, but only to know which packets to match up to which other packets in order to synchronize on ADS-B position messages) That can produce what you see, don't ask me why exactly, it's quite complicated and i don't understand all of it. Feel free to have a look at the source: https://github.com/wiedehopf/mlat-server
It would be cool if the MLAT server took crowd sourced station bans. Like if I could set a "bad" list when I send out MLAT data to say that I don't want to be sync'd with certain stations. There are only a few and they are consistently bad. I don't know if the people running these stations even know they have a problem. There doesn't seem to be a way to email them to tell them to check it out. I use my ham call sign to identify my station, so anyone who really wants to email me can look me up.
I've actually written some code to automatically ignore people with bad sync for calculating positions. It's not perfect, but i hope it will work. James hasn't had time to test it yet though.