Load devel settings file after config.js and settings are saved for
developers even after merges.
modified: .gitignore
modified: public_html/config.js
modified: public_html/gmap.html
modified: public_html/script.js
Example file
--- untrackedDeveloperSettings.js ---
// Load this file after config.js so these settings are used
var CONST_CENTERLAT = 35.21928;
var CONST_CENTERLON = -80.94406;
var CONST_ZOOMLVL = 9;
--- untrackedDeveloperSettings.js END ---
This is the start of breaking the main dump109.c file into smaller
modules to make it a bit more maintainable.
Move all the #define and structure declarations into dump1090.h
Changes based on ideas from John VK1ET. His commit notes are as follows
:
1. Change input socket handling to avoid unnecessary memmove (use
pointers instead)
2. Add ability to read and decode binary beast format TCP.
3. Change output socket handling same as sbs_output - only call output
handler if there is a current client connected use separate ports for
beast in and out - no need for --net-beast flag. Will input/output
format defined by socket connected to. avr raw, beast binary and sbs can
be handled simultaneously.
4. Some comments changes, filtering of ModeAC to json,.
Resolves some merge conflicts that I couldn't find a way to fix during
the previous merge.
Remove a few Tabs that escaped in the edit/merge
Rename the fix_errors flag variable to nFix_crc since it now represents
the number of crc errors to attempt to fix.
Remove the aggressive variable since it's now part of nFix_crc
Only print phase correction statistics when phase correction is enabled.
Add an additional Modes.stat_ph_bit_fix[] to count the bits fixed during
phase correction
Sorry Ulrich - I can't get Github to resolve the merge errors and
preserve your commit notes, so I'll add them here.
Improvements on bit error correction, doc update, preparation for
program installation/package build
Hi,
I committed some further improvements on the bit error correction code,
updated the readme, and implemented a way to install the program in the
linux file system hierarchy (allows for package building).
Regards,
Ulrich
Bug fixes in the SBS output code as a result of an EMAIL from Liviu
Some software gets upset if null fields are output where the software is
expecting a valid value. This was being caused by DF0's outputting and
SBS MSG5. MSG5 needs Atert and SPI flags, which are derived from the FS
field. DF0 doesn't have an FS field, so cannot output a MSG5. Change so
that DF0 results in an SBS MSG7.
Also DF17/DF18 metypes 5 to 18 contain raw Lat/Lon data. However they
cannot be decoded into real Lat/Lon values unless both even and odd
parts are available Therefore, when we receive a DF17/DF18 we need to
check that we have successfully decoded the Lat/Lon before we attempt to
send an SBS MSG2 or MSG3. If we don't have a decoded Lat/Lon, send a
MSG7 instead.
untrackedDeveloperSettings.js
Create file and add line `var developerSettings = true;` on top of it.
After that some settings can be overwritten with deleloper's flavour.
-- Example File w/o line numbers --
var developerSettings = true;
var CONST_CENTERLAT = 60.0; // 45.0
var CONST_CENTERLON = 20.0; // 9.0
var CONST_ZOOMLVL = 6; //5
-- End of Example File --
modified: .gitignore
modified: public_html/gmap.html
modified: public_html/script.js
Phase enhancement is used to try and increase the signal amplitude when
Nyquist sample aliasing is suspected. In previous versions, this was
enabled by default. In this version, the default is off. There is now an
additional command line switch --phase-enhance to turn it on.
There are also additional debug statistics which count the number of
phase demodulation failures in for both uncorrected and phase corrected
passes.
Ideally we should clear down the mm structure every loop of our
ModeA/C/S bit detector. However, we're getting 2Mbits of data per
second, and the structure is several tens of bytes long. Clearing down
every loop would require us to zero up to 100Mb per second. The memset
function may be fast, but it's still going to take up valuable processor
time.
So instead of clearing the whole structure every loop, just clear the
important parts.
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.
