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.
the message being emitted immediately.
Fix computation of reception time so it's more sensible (the block timestamp
is some time after reception of the _end_ of the block, not the start) - this
means that message-emission times are always later than message-reception
times in SBS output, which is a bit more sensible.
Use clock_gettime in preference to ftime.
(except in --net-verbatim mode, where we emit them all)
Move aircraft tracking into track.[ch].
Clean up references to "interactive mode" when tracking
aircraft - we always track aircraft, even in non-interactive
mode.
could confuse the partial correction used in DF11.
That code shows that yes, there are ambiguous syndromes in the
2-bit correction case only, so disable corrections of more than
1 bit in DF11.
This means the 1/5/15 min values may reflect a period that ended
up to 1 minute ago, but the length of the measured period is always
as expected i.e. 1/5/15 mins.