Mode-S Beast:Data Output Formats - Revision history

Dl4mea at 19:54, 26 May 2025

2025-05-26T19:54:39Z

← Older revision		Revision as of 19:54, 26 May 2025
Line 1:		Line 1:
			__TOC__

	The Mode-S Beast supports two different raw data output formats:		The Mode-S Beast supports two different raw data output formats:

Dl4mea: /* Binary Format (DIP#3 in "ON" position) */

2020-05-15T20:00:41Z

Binary Format (DIP#3 in "ON" position)

← Older revision		Revision as of 20:00, 15 May 2020
Line 37:		Line 37:
	</code>		</code>

	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 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.		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.		'''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.

Dl4mea: /* Binary Format (DIP#3 in "ON" position) */

2020-05-15T19:57:42Z

Binary Format (DIP#3 in "ON" position)

← Older revision		Revision as of 19:57, 15 May 2020
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 ~~compatibilty~~ with AVR and later plannings, use "ON" position for the AVR format.		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 ~~compatiblity~~ reasons this will now stay as 0x1a and not be changed.		'''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.

Dl4mea: /* Binary Format (DIP#3 in "ON" position) */

2020-05-15T19:55:09Z

Binary Format (DIP#3 in "ON" position)

← Older revision		Revision as of 19:55, 15 May 2020
Line 31:		Line 31:
	<esc> "2" : 6 byte MLAT timestamp, 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 timestamp, 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, ~~status data~~, DIP switch configuration settings (not on Mode-S Beast classic)<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>

	<esc> is 0x1a, and "1", "2" and "3" are 0x31, 0x32 and 0x33		<esc> is 0x1a, and "1", "2" and "3" are 0x31, 0x32 and 0x33
	</code>		</code>

			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 compatibilty with AVR and later plannings, use "ON" position for the AVR format.		When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibilty 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 compatiblity reasons this will now stay as 0x1a and not be changed.		'''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 compatiblity reasons this will now stay as 0x1a and not be changed.

imported>Dl4mea: /* Binary Format (DIP#3 in "ON" position) */

2015-08-28T08:57:02Z

Binary Format (DIP#3 in "ON" position)

← Older revision		Revision as of 08:57, 28 August 2015
Line 28:		Line 28:

	<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, status data, DIP switch configuration settings (not on Mode-S Beast classic)<br>
	<esc><esc>: true 0x1a<br>		<esc><esc>: true 0x1a<br>

imported>Dl4mea at 12:16, 26 April 2015

2015-04-26T12:16:04Z

← Older revision		Revision as of 12:16, 26 April 2015
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

imported>Dl4mea: /* Binary Format (DIP#3 in "ON" position) */

2013-12-01T15:50:07Z

Binary Format (DIP#3 in "ON" position)

← Older revision		Revision as of 15:50, 1 December 2013
Line 37:		Line 37:

	When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibilty with AVR and later plannings, use "ON" position for the AVR format.		When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibilty 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 compatiblity reasons this will now stay as 0x1a and not be changed.
			'''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 compatiblity reasons this will now stay as 0x1a and not be changed.

imported>Dl4mea at 15:49, 1 December 2013

2013-12-01T15:49:23Z

← Older revision		Revision as of 15:49, 1 December 2013
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)~~'''~~		===AVR Format (DIP#3 in "open" position)===

	{\| class="wikitable"		{\| class="wikitable"
Line 23:		Line 23:


	~~'''~~Binary Format (DIP#3 in "ON" position)~~'''~~		===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:

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..."

2013-11-10T17:34:05Z

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..."

New page

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 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)'''

{| class="wikitable"
|'''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:

<code lang="text">
<esc> "1" : 6 byte MLAT, 1 byte signal level, 2 byte Mode-AC 
<esc> "2" : 6 byte MLAT, 1 byte signal level, 7 byte Mode-S short frame 
<esc> "3" : 6 byte MLAT, 1 byte signal level, 14 byte Mode-S long frame 
<esc><esc>: true 0x1a 

<esc> is 0x1a, and "1", "2" and "3" are 0x31, 0x32 and 0x33
</code>

When binary format is selected, DIP#5 (MLAT timer) is ignored. For compatibilty 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 compatiblity reasons this will now stay as 0x1a and not be changed.