The old logic had a number of problems, including:
* sending heartbeats on all service types if any type needed
a heartbeat
* sending a heartbeat multiple times a second if there was a
service type that was idle but didn't generate traffic when
an empty message was sent (e.g. FATSV)
Rewrite it all so that heartbeats are explicitly tracked and handled
per service type, rather than by sending a dummy message.
Also switch to mode A/C messages for the beast/raw heartbeat, as
it's a bit more compact and less likely to mess with Mode S state
(an all-zeros Mode S message actually looks valid)
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.
In particular, not guarding in flushWrites() meant that we
could end up trying to write to an uninitialized writer
(where writer->service == c->service == NULL) and crashing.
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.
Move ModeA/C demodulator to demod_2000 (decoding stays in mode_ac.c)
Remove dependency on interactive.c in stats.c
faup1090 then doesn't need interactive.c at all.
This is a from-scratch reimplementation that should be functionally
equivalent to the Flightaware version that was based on dump1090_mr
and had its fingers deep in the network code. This version should be
a little less invasive / fragile..
This lets different things dynamically create the services they need,
and sorts out the horrible hacks that view1090 used to make outgoing
connections. Now you can explicitly create a service and tell it to make
an outgoing connection.
This means that view1090 can now just set all the ports to zero (to disable
the listeners), do a normal net init, then explicitly construct the beast
input service without a listener and tell it to make a connection as needed.
This gives access to the existing throttling behaviour when reading
from a file with --interactive, without needing to actually have
--interactive.
This is useful when testing, as without --throttle samples will be
processsed much faster than real-time, which can produce different
results with e.g. aircraft/filter expiry times and position/speed checks.
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.
This currently understands:
UC8 (original rtl_sdr format, 8-bit unsigned complex);
SC16 (16-bit signed complex, full width);
SC16Q11 (bladeRF native format: 16-bit signed complex with 11 bits of magnitude)
This affected Beast input/output, and AVR output in --mlat mode.
Works on a little-endian host, should work on a big-endian host but
I don't have one to test with.
Probably fixes#44.
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.
* use PageName, not literal "DUMP1090"
* use document.title directly, not a selector
* include number of positionless aircraft too
* rename the config options
* some simplification of the changes
This would mangle messages if the first byte of a message ended up
as the last byte returned by a read() call - it would read beyond
the end of the buffer, decide the message was damaged, and then run
off into the message data looking for a new delimiter. Sometimes
that would work (only dropping one message), but sometimes it would
run into data that happened to look like a message start but
actually wasn't, and then try to interpret that, leading to completely
bogus message data being read.
Fixes#29.
