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
1) Implement additional timestamps to remember when a new Lat/Lon value
is generated.
2) Increase callsign[] character array to 16 chars to make it long word
aligned.
3) Change some more comments from /* to //
Use memset to clear entire structures at initial creation to zero, and
then populate values that should not be zero. Do this rather than
individually clear each structure member to zero.
This should be faster, plus it's safer when new structure members are
added because you don't have to remember to initialise them.
Use 32 bit registers to hold multiple characters and shift them. This
removes the need for multiple memory reads.
Also tidy up the DF-17 extraction routine to make it more readable.
ICAO documents refer to AC13 for altitude encoding and ID13 for squawk
wncoding. Rename decodeGillhamField to decodeID13Field to better
represent this.
There is a quite complex if/else construct for gathering statistics
inside the main decodeModeS loop. To speed the loop up when not
gathering statistics, make the whole construct conditional on Modes.stat
being set.
Also tidy up a few comments
Allow the decodeModeMessage function to re-calculate msgtype and
msgbits. This makes the code a bit more portable by not requiring the
calling function to fill in these fields before the call.
Changes supplied by John VK1ET.
This tidies up the thread termination, which then allows for use of [a
trapped] Ctrl/C to cleanly terminate the program and dump stats if flag
set.
Lots of changes to the decodeModesMessages() function, and associated
helper functions, with the aim of speeding the code up by reducing the
number of calls to the CRC functions. Also, only update the mm variables
which are part of the message we're decoding.
Change the way CRC's are generated and checked.
Change the way single and double bit error is implemented.
General tidy up of the function to make it more readable.
Modify all the Mode=S Gillham altitude decoding to use a new function
decodeGillhamField()
Change the Mode-S signal strength so that it rounds to the nearest
integer
Assume that DF0-DF15 are all short 56 bit messages
Assume that DF16-DF31 are all long 112 bit messages
This helps us error detect and error recover for bits in the first byte
The DF's for altitude include a Q bit to distinguish either 100ft or
25ft altitude encoding. This version implements the 100ft increments
used by older aircraft. These codes are basically ModeC altitudes
transmitted over ModeS.
Reformat the --interactive display to show more information
Add a "Mode" column. This displays the The primary message type "S" or
"A" plus any matching modes "a" and/or "c". Requires --modeac switch.
Add a "Sig" column to show the signal strength.
Add a --fix command line switch to enable error correction using CRC.
Change the default to OFF/Disabled.
Error correction can very occasionally result in an incorrect solution
to the crc equation. It also takes significant CPU work for very few
corrected results. Therefore, the default has been changed to OFF, but
you can re-enable it if you wish by using the --fix command line switch.
Implement changes suggested by John/VK1ET
Changes to cprNFunction to ensure fflag {was 'isodd'} is used as a flag.
Fix to decodeCPRrelative to pass 'surface' flag.
The original code stores the squawk as a decimal (base 10) value. Change
this to a hex value to reduce the amount of maths required to convert
the input binary value..
Rename all the variables used to store the squawk to "modeA", rather
than variously identity, squawk and modeA.
Several variables within structures contain the same information in
different forms.
The aircraft structure contains addr and hexaddr. Hexaddr is a printable
string version of addr. However, hexaddr is only ever used in printf
statments, so we can use printf(%06x) to print addr. This saves a printf
for every received command.
The modesMessage structure contains addr, and aa1,aa2,aa3 as separate
bytes. aa1,aa2 and aa3 are only ever used to construct addr, and to
print out. Therefore, we can use addr instead of them..
The original code made an attempt to reconcile a newly arrived ModeA/C
message with every known Mode-S report at the time of detection.
However, the results of matching up Modes A/C and S are only used in the
interactive display routine, and that is only called periodically from
within the BackgroundTasks loop.
Doing the matching on every ModeA/C arrival incurs quite a large CPU
processing load. Moving the matching up routine to the backgroundTasks
loop means that the task is performed muck less frequently and therefore
uses less CPU time.
Allow a greater range and negative values for Mode C (down to -1200
feet)
Stop attempting to feed ModeA/C data to SBS Output stream.
Allow Mode A only matches to Mode-S squawks when the Mode A code does
not conflict with any possible (legal) Mode C code.
Allow Mode C matches to track aircraft climbing and descending
relatively slowly. This also helps when trying to match Mode-S altitudes
which are 25 foot increments, with Mode C altitudes which are in 100
foot increments.
First attempt at decoding legacy SSR Modes A and C.
If the command line switch --modeac is used, the program will now
attempt to recover Mode A/C signals contained in the raw I/Q data
stream. The current recovery mechanism is quite strict and does not cope
well with overlapping and corrupt SSR replies. I estimate that less than
20% of possible returns are decoded correctly. Hopefully over the next
few iterations this can be improved.
If outputting raw data it is recommended to use the --net-ro-size and
--net-ro-rate command line options to reduce the number of very small
ethernet packets that will be generated by mode A/C replies.
Thanks to vk1et for these.
1) Correct for additional timestamp langth in raw output buffer when
using mlat mode
2) Don't output a timestamp when the message has been received from a
remote site (the internet). This is to avoid upsetting MLAT because
there is an indeterminate delay between reception at the remote site and
subsequent message arrival in the local dump1090 instance.
3) Allow @ character for raw data input with timestamp, and correctly
calculate the length.
The original code calculates Lat/Long only if it receives two DF-17
(subtype 9 or 18) within one second of each other. I have no idea why.
It then caches the results in the aircrafts data structure for use in
the --interactive display.
When SBS-1 style ASCII output is selected (port 30003) the code does not
attempt to calculate Lat/Long from the data just received - instead it
picks it up from the cached information in the aircraft's data
structure.
However, if the data isn't being updated this results in stale Lat/Long
being sent out. This is most likely to occur when the aircraft is at the
extreme edge of the receivers range when it may be getting some DF-17s
containing Lat/Long, but not 2 per second. The program will continue
sending the stale data until the aircraft finally times out (default 60
seconds)
I have modified the code to include a sbsflags variable in the aircraft
data structure. When a new Lat/Long is decoded and put into the
structure, a bit is set to indicate SBS_LAT_LONG_FRESH. Then, once the
Lat/Long is output the first time, the bit is cleared. Thereafter the
code will not populate the Lat/Long fields in the output message until
SBS_LAT_LONG_FRESH is set again.
The default is 0. This works in conjunction with --net-ro-size.
The program will attempt to gather up "net-ro-size" raw bytes before
sending them out over Ethernet. However, to avoid a long wait if the
traffic density is very low, the program will only wait for
"net-ro-rate" 64mS periods since the last send. before sending any data
added to the output buffer since the last send. This allows the user to
tailor the network load to suit their requirements.
