In recent versions of Firefox and (especially) Chrome, ".dev" domains are
force-redirected to a secure connection (HTTPS) instead of HTTP. Not
supporting an HTTPS connection makes for a bad user experience, so we want
to make enabling SSL support easy. Since we don't issue certificates, this
section is commented out by default, and it will require modification.
This is done primarily for PiAware, though it is applicable to just the
Dump1090 project.
--fix --fix was a poor choice for this, as some existing configs
happened to specify --fix twice but only expected 1-bit correction.
So move 2-bit correction to a separate option.
"--fix" or "--fix --fix" now gives 1-bit correction.
"--fix-2bit" or "--fix --fix-2bit" or "--fix-2bit --fix" gives 2-bit correction.
Version bump to 3.8.2~dev
Standard lighttpd will refuse to start if modules are loaded more than
once. Turn the module addition into a comment, explain why it's disabled
by default and in which cases you should enable it.
On some instances of lighttpd, like the one that comes with PiHole, the
alias module is not loaded by default. This makes the configuration of
PiAware's lighttpd not work (see e.g.
https://discourse.pi-hole.net/t/pi-hole-and-piaware-lighttpd/9611).
This way we ensure that the alias module is loaded even on non-default
lighttpd configurations.
When `unreliable_tracks` was added to the JSON output, the trailing `}` after `single_message` should likely have been removed.
Side note: should this just be `unreliable` since it is nested inside `tracks`? `all` and `single_message` don't have the `tracks` suffix.
residual, use the full 24-bit syndrome.
Previously this would mask off the low 7 bits, which isn't particularly
great - it doesn't really make sense in that it implies a somewhat
random IID value, and it would actually only correct 20 possible bit
errors out of the 51 possible errors, 16 of which were errors in
the top 16 bits of the CRC itself. It is also risky as it will accept
a larger number of possible garbage messages as the lower 7 bits may take
any value.
Instead, use the full syndrome, assuming that the damaged message
had IID=0 - which seems more likely than assuming a random IID, since
IID=0 is used for acquisition squitters and should be arriving regularly.
The reduced rate of corrections for DF11 messages shouldn't have
much of an impact as DF11s carry very little data themselves - they
are mainly used to acquire the aircraft address. Once one good message
for an aircraft turns up (which would require IID=0 anyway before we'd
accept it) it doesn't really matter if we discard more damaged messages,
as they're not contributing to anything useful in the aircraft state
beyond air/ground status, which is also carried in many other messages.
John Berninger
Oliver Jowett
Eric Tran
Claudio Moretti
Determinant
Carlos Pizarro
Jade Michael Thornton
byronbest
Oliver Jowett
Dan McGee