Instead of force clearing mm.crc to zero if we successfully correct bit
errors, just use the mm.correctedbits variable. This allows us to print
out the crc value containing the errors during list output modes.
Actually use the (DF17) messages where we do bit correction.
Other changes to AVR message I/O.
1) treat mlat timestamp of zero as invalid (easier to work with than
(-1) and equally unlikely).
2) If we don't have a valid timestamp send a without timestamp
'*.......' message rather than '@.......' with invalid time.
3) Drop interpretation of obsolete AVR ' #' & '$' formats - they
wouldn't have worked anyway (wrong length).
If we error correct a DF17 frame, check that the ICAOaddr exists in our
recently seen ICAO cache. This reduces the likelyhood of birthday
paradox solutions producing false ICAO addresses
Restrict Syndromes to exclude DF bits. Do NOT introduce syndromes for
errors in the first 5 bits (DF field)
Use the --aggressive flag to see if we populate the two-bit error
syndromes. If --aggressive is not specified, then we don't attempt to
fix two bit errors.
New settings area can be opened by clicking Settings-link and closed by same link or OK-button. No settings to change yet.
modified: public_html/gmap.html
modified: public_html/script.js
modified: public_html/style.css
vk1etI believe there is an error in the way the CRC error syndromes are
being created in the two bit case. The inner loop was introducing an
extra error bit each time through rather than moving it. Below is the
modified code fragment for syndrome creation collapsedSun 07:26
19 May 2013 07:26vk1et [notifications@github.com]Actions
To:Mantirez/dump1090 [dump1090@noreply.github.com]Cc:MMalcolmRobb
[Support@ATTAvionics.com]
To help protect your privacy, some content in this message has been
blocked. If you're sure this message is from a trusted sender and you
want to re-enable the blocked features, click here.
Bugfix first noted by VK1ET, and posted here :
https://github.com/antirez/dump1090/pull/23#issuecomment-18113094
I believe there is an error in the way the CRC error syndromes are being
created in the two bit case. The inner loop was introducing an extra
error bit each time through rather than moving it.
Added quite a lot of new things this time - see modified files or just
be brave and try :)
modified: public_html/gmap.html
modified: public_html/script.js
modified: public_html/style.css
Updated the version number for Ulrich's code
Replaced some Tabs with spaces
Forward declaration of the fixBitErrors() function required for M$ VC
6.0 to suppress warning messages.
Based on a submission by VK1ET, but I've tweaked it a bit to use the
bFlags.
Basically, only print out values in --interactive that have been
received from the aircraft. Previous versions would display 0.000 for
lat and long for any positionless aircraft. This version prints blanks
instead for any/all fields that are not yet known.
Remove dependency of the SBS output code on the historic (a) aircraft
structure. The only items that were required were the decoded aircraft
Lat/Lon and these are now included in the mm structure.
Rewrite the SBS output code to use mm->bFlags when populating the output
fields. This ensures that all available data is output, and also that no
stale data is sent.
Using the mm->bFlags variable for SBS output means there is no further
requirement for the sbsFlags member in the aircraft structure, so remove
it.
Cross your fingers and hope this hasn't introduced too many bugs !
Implement additional bFlags to validate AircraftOnGround, and FS.
Decode Aircraft On Ground from DF0, DF4, DF5, DF16, DF20, and DF21 where
possible.
Flag FS as valid for DF4, DF5, DF20, DF21,
Remove dr and um from the mm structure. They're only used in console
list output mode, so decode them there if required.
Additional flags in the bFlags variables for even and odd CPR lat/lon
updates.
Change the interactiveReceiveData function to use the bFlags when
updating the aircraft (a) structure from the newly received (mm) message
structure. This should hopefully be faster than basically re-decoding
the DF, type and subtypes all over again.
If we decode the lat/lon into the aircraft (a) structure, back populate
it into the message (mm) structure. This allows us to print a decoded
Lat/Lon in the decoded message list output.
