This DF is formatted with the first two bits as 1, and the next 3 bits
are part of the message rather than part of the DF code. So effectively
it spans 8 DF values if you are looking at the full 5 bits.
The logic for DF11 was completely broken and inverted. How did this ever work??
Actually, the broken version kinda works because the only types of message that
can yield an address that's not already in the ICAO filter are DF11/17/18.
So DF=17; DF=18; and DF=11 with IID=0 would pass the broken logic and populate the
filter. All other DFs would pass the broken test, too, but they can only ever
re-add entries that were already there.
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.
Magnitude conversion now happens immediately when sample data is
received, so there is no risk of newly received data clobbering old
data under CPU overload.
We already do this check when scoring a message for the demodulator,
but there are other paths that can feed us a message so also do the
check in the main decode path.
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.
(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.
since we have 8 bits spare, so there's no chance of confusing it
with an ICAO address, and we can safely use the filter table to match
future messages without also matching equivalent ICAO addresses.
Switch signalLevel back to a power measurement, don't put SNR in there.
But make it a 0.0 - 1.0 double so we're not scaling everywhere.
Adjust for the amplitude offset when calculating power.
Adapt everything else to the new scheme.
location (which may not be the aircraft location).
I suspect this sanity check is, in fact, redundant now that the
rest of the algorithm has had some bugs fixed; it should only
produce results within half a cell by definition.
Mostly refactoring the common code that was duplicated
between the different output types so that there aren't
many copies floating around.
This introduces "struct net_writer" to store the state of a
particular type of output service - buffers, time of last write,
connection count etc. prepareWrite() / completeWrite() give access
to the buffer and handle the actual writes and flushing when needed.
Heartbeat and time-based flushing move into a generic periodic-work
function.
Update the SBS output code to use the new infrastructure. This makes
a big different to CPU use when under load.
If we demodulate a message in 2.4MHz mode and it has a bad, uncorrectable CRC,
and --phase-enhance is on, then retry with the other possible phases until
we get a good CRC or run out of phases to try.
This is very expensive in AGC mode (lots of candidates that are not real
messages) but relatively cheap otherwise. It yields another 10% messages.
Also factor out some common stats code to avoid lots more copy/paste.
Apparently enabling AGC produces samples with quite different characteristics,
and ends up eating a lot more CPU as the previous heuristics would generate a
lot of false positives. Tweaking the parameters and a bit of optimization
seems to bring this back down to usable levels without losing many potential
messages.
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.
Oliver Jowett
Raphael Geissert
MalcolmRobb
hhm