I’ve noticed that MLAT data can be really jumpy (up to a mile between data points). This is even with >20 synchronized sites around KSEA. I’m curious if the problem is incorrect/low-precision location data entered by individual piaware sites or inherent lack of precision in hardware timers on RP2s. PCs have the RDTSC opcode to read the processor’s time stamp counter (TSC) directly, but there are issues here (different readings based on which core you happen to be executing on). There’s also the Intel HPET Timer on PCs which is supposed to be better. There’s a pretty good Windows based article here: msdn.microsoft.com/en-us/librar … 08(v=vs.85.aspx
The ARM doesn’t have the equivalent of RDTSC and I don’t know if the RP2 has any other hardware to help. Light travels almost a quarter mile in a microsecond so there’s little room for error.
If the problem is bad location data entered by piaware feeders, could the ADS-B signals that are used to synchronize multiple MLAT stations also be used to precisely locate the piaware site? By looking at several ADS-B readings from several directions over time you could compute the only location consistent with all those readings. Again though, this only works if there’s a precise clock/timer on the RP2.
From a completely different angle, I’ve seen people experimenting with using an RTL2832U dongle to process GPS signals. If that was possible then you would have precise time and location. Could enough GPS signal pass through a 1090MHz filter to allow this to work even if the chip could be programmed to do it?
I did look at the MLAT code to try and answer some of this myself, but it was quickly clear this was a very complex (and justifiably so) piece of software. Also my system level experience is all on Windows making it more difficult.
In summary then:
- Are MAT errors due to bad user entered locations or lack of precise clock hardware on RP2s?
- If bad location, could a series of ADS-B receptions from a variety of directions be used to determine the correct position?
- Could the RTL2832U be used as a GPS receiver to calibrate actual location/time from time to time?
As I said, more brainstorming than feature request. I think I’m particularly hoping OBJ is reading this…