Mode-S Beast:Data Output Formats: Difference between revisions
imported>Beastadmin Created page with "The Mode-S Beast supports two different output formats: * The AVR format, which is a ASCII hexdump of the raw frame contents with some variances * The Mode-S Beast binary for..." |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
The Mode-S Beast supports two different output formats: | 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 AVR format, which is a ASCII hexdump of the raw frame contents with some variances | ||
| Line 6: | Line 6: | ||
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. | 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)=== | |||
{| class="wikitable" | {| class="wikitable" | ||
| Line 23: | Line 23: | ||
===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: | 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: | ||
<code lang="text"> | <code lang="text"> | ||
<esc> "1" : 6 byte MLAT, 1 byte signal level, 2 byte Mode-AC<br> | <esc> "1" : 6 byte MLAT timestamp, 1 byte signal level, 2 byte Mode-AC<br> | ||
<esc> "2" : 6 byte MLAT, 1 byte signal level, 7 byte Mode-S short frame<br> | <esc> "2" : 6 byte MLAT timestamp, 1 byte signal level, 7 byte Mode-S short frame<br> | ||
<esc> "3" : 6 byte MLAT, 1 byte signal level, 14 byte Mode-S long frame<br> | <esc> "3" : 6 byte MLAT timestamp, 1 byte signal level, 14 byte Mode-S long frame<br> | ||
<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)<br> | |||
<esc><esc>: true 0x1a<br> | <esc><esc>: true 0x1a<br> | ||
| Line 36: | Line 37: | ||
</code> | </code> | ||
When binary format is selected, DIP#5 (MLAT timer) is ignored. For | 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 our devices is +/-3 ticks. Radarcape since using a timing GPS receiver has less spikes and a more stable clock compared to Air!Squitter and Beast Module with uBlox M8W non-timing module. | ||
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 | |||
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. | |||
Latest revision as of 20:00, 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 our devices is +/-3 ticks. Radarcape since using a timing GPS receiver has less spikes and a more stable clock compared to Air!Squitter and Beast Module with uBlox M8W non-timing module.
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.