The old matching process which tracked mode A values as pseudo-aircraft
got very, very expensive with a large number of mode A/C messages (and
with lots of single-bit errors, which seems common with a Beast doing
the reception)
Instead just count A/C messages directly into a 4096-entry array (which
is very fast) and periodically scan the mode S aircraft list to see if
we can match anything up (which is fixed overhead + cost proportional
to the number of mode S aircraft)
Notice synthetic mlat messages by looking for messages with a magic
timestamp value. If they arrive, tag the derived data as mlat-derived.
Don't include mlat-derived output in FATSV output to avoid loops.
The DF17/18 values are generally more trustworthy as they have full
CRC coverage. Errors in the CRC bits of a DF0/4/16/20 message can
result in the contained altitude being attributed to the wrong aircraft.
Previously it forgot to advance to the next aircraft and only
happened to work because it cleared the position bitflags and so
the next iteration (on the same aircraft) would advance.
Track NUCp when we compute positions.
Do speed checks when we have an updated position with the same or worse NUCp
before accepting the new position. Don't do speed checks on new postions if
they improve NUCp - assume that the new position is better.
Include NUCp in aircraft.json
Gather stats on reasons for rejecting CPR data due to range/speed check failures.
Expire old positions if we have had no updates for 60 seconds.
Closes#16, closes#17.
This is possible now that the SBS output doesn't rely on the global block timestamp;
the output will look like this:
MSG,8,111,11111,4AC954,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,7,111,11111,392AEB,111111,2015/02/08,17:57:53.744,2015/02/08,17:57:53.936,,15375,,,,,,,,,,0
MSG,8,111,11111,392AEB,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,6,111,11111,800387,111111,2015/02/08,17:57:53.919,2015/02/08,17:57:53.936,,,,,,,,4745,0,0,0,0
where the "receive timestamp" (first time column) goes backwards to reflect the original reception
time of the delayed message, but the "forwarded timestamp" (second time column) reflects the actual
forwarding time.