For remotely received messages that have a mlat timestamp, we have no
useful way of turning that timestamp into a wallclock timestamp, so
don't try, or we'll just produce wildly wrong results (_days_ in error)
There is a danger in always using relative decoding where possible.
If there is an undetected error in the first pair of messages received,
then global CPR decoding will give a bad position, and subsequent
relative decoding will just walk around near that bad position even
though many error-free pairs of odd/even messages may have been received.
The first pair of position messages also tends to be the most error-prone, as
they are usually received at the extreme edge of receiver range.
(I see this happen at least once a day in practice)
So, instead, prefer to use global decoding when we have sufficiently recent data.
With recent data this should always be as good as relative decoding, and it
avoids getting stuck with bad data for long periods of time. If we don't have
enough recent data for a global solution, fall back to relative decoding.
If a CPR message with an undetected error is received this can produce out-of-range results for latitude.
e.g. even latitude of 78000, odd latitude of 0 produces a latitude index j=35 and rlat0 = 213.
This disables most decoding of the contents of Mode S messages, aircraft tracking, and some output modes that depend on them.
It's intended for edge receivers that just forward to a central hub rather than processing data locally.
Release of COAA PlanePlotter MLAT and SMU support for RPi
ppup1090 now supports Ground Stations functions required for MLAT and
SMU operation. This is *ONLY* available for RPi and similar linux
hardware.
Also included are sample startup scripts for dump1090 only and
dump1090+ppup1090 together.
view1090 was using close to 100% CPU before, with the non-blocking
commits and the reconnection code. sleep a bit between loop iterations
to keep CPU usage low.
CPU usage with this addition was down to <1% in testing.
