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.
If --modeac is specified, then the program will be building an aircraft
list. Calculate the altitude when we create the aircraft structure (a) ,
and then back copy it into the mm structure. This avoids us having to do
a second ModeAtoModeC conversion in the list output display.
Also - bug fix in the ns_vel calculation.
Changes to 'dump1090.c'-file made accordingly.
modified: .gitignore
modified: dump1090.c
deleted: gmap.html
new file: public_html/gmap.html
new file: public_html/script.js
new file: public_html/style.css
Update the bFlags structure member to indicate which other structure
members contain decoded values.
Also, trim out mm structure members that are simple bitwise ands from
the raw data, unless the results are used in lots of places whereby
decoding them once is more efficient.
Extend the DF-17 CPR decoding to use User Lat/Lon for ground positions.
Also start implementing a bFlags structure variable to indicate which
fields in the mm and a data structures contain valid values.
Based on initial code supplied by VK1ET
Allow the user to specify their receivers (technically their aerials)
physical location. This is required for decoding ground positions, and
also for uploading aircraft data to various sharer sites.
The position can be hardwired by setting the MODES_USER_LATITUDE_DFLT
and MODES_USER_LONGITUDE_DFLT constants before compilation, or entered
at runtime via the new command line switches --lat and --lon. Either
way, the values are checked for validity before use.
Only clear mm after we are sure we have got a Mode A/C. This reduces
processor load.
Also tidy up some Linux compiler warnings that result from the last
change.
Based on a submission by VK1ET. Fully decode DF-17, metype 19. Take care
to only update fields that are valid in the data.
Also, initialise (to zero) the mm structures before use
