The networking layer is still a toy however now there is not a blocking
sleep when we need to wait to process for new clients, but a basic form
of multiplexing is used to signal when at least one client needs some
care.
The code was also partially refactored, but more work is needed to make
it more straightforward.
The problem was the cprModFunction() not calculating the absolute value
of the latitude, so the table only worked for the northen hemisphere.
Thanks to @pwarren for finding the bug.
This fixes issue #13.
To try to decode messages with a fundamentally flawed preamble is mostly
a useless waste of CPU time.
The new aggressive mode still detects a sensible percentage of
additional messages because of the error tolerance and two-bits fixes
but does not waste your CPU time.
The phase correction was applied only to a subset of bits! Because of an
offset error.
The detection code layout was modified a bit to make it simpler to
implement more corrections in the future. However only phase correction
is performed currently. Slope correction, or to compensate for the cycloid
effect are two possible improvements.
* Better preamble detection to skip most of the messages we'll likely
not be able to decode.
* A Phase correction algorithm that improves the recognition compared
to the previous algorithm used.
* Javascript output in debug mode, and a debug.html file that can be
used in order to see graphically undecoded samples.
* Ability to detect cross-read messages, that are, messages that happen
to start and end across two different reads from the device or file.
* A few bugx fixed.
* README improved.
This commit address two issues with the implementation of CPR decoding:
Fix#1: The two functions N() and DLon() used to have the latitude
parameter as an integer (!), basically truncating the fractional part
before calling the NL() function to perform the lookup.
This resulted into random strange movements of aircrafts, especially
jumps or shifted positions.
Fix#2: Use milliseconds for CPR odd/even timestamps. Dump1090 already
tried to use the most recent packet received among the odd and even
packets currently available, however to do this correctly millisecond
resolution should be used, otherwise many times the odd and even packet
appear to have the same time in seconds and we don't always use the
latest received.
