Added lots of stuff including settings DEMO at http://bitropy.net:8080 #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Dynamically size terminal using SIGWINCH antirez@f18180f
The Mutex on the RTL data reader thread does not "force" the data processing thread to execute. Therefore, if the processor is busy, it is possible for a second RTL callback to occur before the data from the first has been processed. This will cause the loss of the first data, but worse, it will cause a slip in the timestamp. This upsets Beamfinder and MLAT operation in PlanePlotter. To solve this, keep a Fifo buffer which is filled by the callback thread, and emptied by the data processing thread. The fifo is the same size as the number of buffers requested in the call to rtlsdr_read_async(). Note - we only put the value of the pointer supplied in the callback into the fifo. We do not attempt to cache the data in the buffer pointed to by the pointer. This would require us to memcopy() 2Mbytes per second, which we don't want to do if we don't have to because it will only make the processor loading worse. Instead, we assume that the data in the buffer will remain valid after the callback returns, at least until it is overwritten by new data. It is still possible for us to lose data if we can't process it quickly enough. However, we can now detect this loss of data when the fifo is almost full, and correct the timestamp for the lost block/blocks.
Thanks to Blort on the PP list. The Beast binary message stream uses the 0x1a character a and escape to mark the beginning of a new message. However, the 0x1a character could occur in the body of a message since the message is binary. Therefore, the 0x1a is repeated -as Blort put it : This 56-bit Mode S Frame (containing a 1a) is supposed to look like this: 1a 32 00 00 48 7b a6 1a 1a 0c 20 28 17 b0 c0 c3 b0 What is actually looks (looked) like (from wireshark) is this: 1a 32 00 00 48 7b a6 1a 0c 20 28 17 b0 c0 c3 b0 There are supposed to be two 1A’s (Gunter’s Escape Character) in a row (1A 1A) whenever a data byte contains 1A, after the initial two 1A 3x characters.
Final tidy up and publish
Some users have reported issues where the TCP link to dump1090 can be lost at times of low traffic density - typically in the middle of the night. One possible reason for this is that some routers drop the link if there is no traffic for a predetermined period. To try and resolve this, dump1090 now sends a 'null' packet consisting of 7 "0x00" bytes approximately once a minute if there is no real received traffic during this time. This packet should be discarded by the application receiving the dump1090 because it will have an invalid checksum, and ICAO address 0x000000 is also invalid. However, this null packet should be enough to keep routers alive.
Make the modifications necessary to compile dump1090 for WinXP, Win7 and hopefully Win8. The files can be compiled using M$ Visual Studio/C++ 6.0. Due to various licensing issues, I haven't included the libraries or DLLs. You will need to locate pthreadVC2.lib and rtlsdr.lib to link the file, install the zadig drivers to support the dongle, and locate libusb-1.0.dll, msvcr100.dll, pthreadVC2.dll and rtlsdr.dll. dump1090.exe will not run on any Windows version prior to XP SP2, because msvcr100.dll imports several functions from the Windows kernel that are not available on earlier versions. This means dump1090 won't work on Win2K. The major change to the code relates to file handles. The original code assumes Linux behaviour in that handles are allocated from 0 sequentially upwards. However Windows handles are allocated pseudo randomly, and handle numbers greater than 1024 would break the code. The code has therefore been modified to use a linked list of connection structures, rather than a static array limited to 1024 entries.
Allow connection of a web browser to the Windows version via http://127.0.0.1:8080
Variable j points to the current location in the magnitude vector. When decoding a message (MODES_PREAMBLE_US+msglen)*2 is added to j. In the loop head j is increased by 1, so one value was skipped.
Fixed: now skipping correct number of values in magnitude buffer
Variable j points to the current location in the magnitude vector. When decoding a message (MODES_PREAMBLE_US+msglen)*2 is added to j. In the loop head j is increased by 1, so one value was skipped.
A few minor additions and bug fixes as detailed below 1) Additional command line option "--net-buffer <n>" to specify the TCP output buffer size. Default is n=0, which is 64Kb. Specify a value of n to increase the buffer size according to Size = 64Kb * 2^n, so an n of 1 = 128Kb, n=2 is 256Kb etc. n is limited to 7, so the max size is 8Mb. This option may assist if you have a high number of aircraft being received, and an unreliable network connection, or if the receiving end can be busy for an extended time. 2) Bug fix in ppup1090 which prevented the uploading of valid ModeA/Squawk codes 3) Bug fix per Markus Grab's commit.
Incorrect value for auto-gain option the Modes.gain is multiplied by 10.
Incorrect value for auto-gain
- decodes a bit more information - misc. small changes
decode more squawk codes
make network services disable-able
- keep trying to reconnect to server if disconnected
- do not block on network data
view1090 was using close to 100% CPU before, with the non-blocking commits and the reconnection code. sleep a bit between loop iterations to keep CPU usage low. CPU usage with this addition was down to <1% in testing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DEMO at http://bitropy.net:8080