Mode-S Beast:Data Output Formats: Difference between revisions
| Line 39: | Line 39: | ||
The timestamp tick error is the error of the internal NCO counter at the 1PPS account. It is a metric for the accuracy of the adjustment of the NCO to the 1PPS. Typical range on Radarcape is +/-3 ticks, on Air!Squitter and Mode-S Beast Module with uBlox GPS module up to +/-10 ticks. | The timestamp tick error is the error of the internal NCO counter at the 1PPS account. It is a metric for the accuracy of the adjustment of the NCO to the 1PPS. Typical range on Radarcape is +/-3 ticks, on Air!Squitter and Mode-S Beast Module with uBlox GPS module up to +/-10 ticks. | ||
When binary format is selected, DIP#5 (MLAT timer) is ignored. For | When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibility with AVR and later plannings, use "ON" position for the AVR format. | ||
'''Note:''' Months after the binary format was introduced, I got noticed that in ASCII <esc> is encoded as 0x1b. I actually wanted to use this code, but unfortunately only implemented my believes. For | '''Note:''' Months after the binary format was introduced, I got noticed that in ASCII <esc> is encoded as 0x1b. I actually wanted to use this code, but unfortunately only implemented my believes. For compatibility reasons this will now stay as 0x1a and not be changed. | ||
Revision as of 19:57, 15 May 2020
The Mode-S Beast supports two different raw data output formats:
- The AVR format, which is a ASCII hexdump of the raw frame contents with some variances
- The Mode-S Beast binary format, which is an escaped transparent binary protocol, always contains time and signal level information
A special note to Planeplotter users: When using USB or COM interface, Planeplotter automatically adapts to the format. When using TCP/Ethnernet, currently it only supports binary format. It makes no longer sense to run the bandwidth consuming AVR format over Ethernet, really. And over USB, it does so, too.
AVR Format (DIP#3 in "open" position)
| MLAT Information enable switch | SW5 | Format |
| disabled | open | Standard output: 56 Bit Mode-S frames: *02E99619FACDAE; 112 Bit Mode-S frames: *8D3C5EE69901BD9540078D37335F; Mode-A/C frames: *7700; (Note: Mode-A/C frame values are octal) The distinction between Mode-S and Mode-A/C is only done due to the length of the frame. Examples: *02E99619FACDAE; *8D3C5EE69901BD9540078D37335F; *7700; |
| enabled | on | Format with MLAT timer information - sometimes also called raw data: 56 Bit Mode-S frames: @016CE3671C745DFFE7AB7BFCAB; 112 Bit Mode-S frames: @016CE3671AA88D00199A8BB80030A8000628F400; Mode-A/C frames: @016CE3671C747700; Examples: @016CE3671C7423FFE7AB7BFCAB; @016CE3671AA8A800199A8BB80030A8000628F400; @016CE3671C747700; |
Binary Format (DIP#3 in "ON" position)
There are only three frame formats in the binary protocol, in order to keep some control characters, the Mode-S Beast uses a so called escaped binary format:
<esc> "1" : 6 byte MLAT timestamp, 1 byte signal level, 2 byte Mode-AC
<esc> "2" : 6 byte MLAT timestamp, 1 byte signal level, 7 byte Mode-S short frame
<esc> "3" : 6 byte MLAT timestamp, 1 byte signal level, 14 byte Mode-S long frame
<esc> "4" : 6 byte MLAT timestamp, 1 byte unused, DIP switch configuration settings, time stamp error ticks as int8_t (1 tick is 15ns) (message "4" not on Mode-S Beast classic)
<esc><esc>: true 0x1a
<esc> is 0x1a, and "1", "2" and "3" are 0x31, 0x32 and 0x33
The timestamp tick error is the error of the internal NCO counter at the 1PPS account. It is a metric for the accuracy of the adjustment of the NCO to the 1PPS. Typical range on Radarcape is +/-3 ticks, on Air!Squitter and Mode-S Beast Module with uBlox GPS module up to +/-10 ticks.
When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibility with AVR and later plannings, use "ON" position for the AVR format.
Note: Months after the binary format was introduced, I got noticed that in ASCII <esc> is encoded as 0x1b. I actually wanted to use this code, but unfortunately only implemented my believes. For compatibility reasons this will now stay as 0x1a and not be changed.