What is the "secure S-Bus Data Mode"?

FAQ #100713

 

Why has the secure Data Mode been introduced?
The secure data mode prevents the situation that a Serial-S-Bus response telegram who's timeout had exceeded (and therefore a new request has been sent) is interpreted as the response to the following request. This situation could occur if e.g. radio modems are used and the master port timeout is not set adequately (if the transmission time of the request and the response are longer than the timeout).
How does the secure Data Mode work?
The secure data mode introduces a new (additional) header to the existing S-Bus data mode telegram. A secure S-Bus data mode telegram has the following structure:

• One byte of framing character (B5, used as frame synchronisation) 
• One byte "AT character" indicating that this is a secure data mode header (0x10 = Request; 0x11 = Response)
• One byte indicating the telegram length of the following (standard S-Bus data mode) telegram
• One byte for the sequence number of the telegam
• A complete standard S-Bus data mode telegram (again starting with a framing character B5 and including the CRC)

If the master does support the secure data mode, it will use it for all request telegrams it sends on all serial ports. The slave does answer in the same mode as the request is sent, if possible. If a slave that does not support the secure data mode, it will answer all requests with the standard data mode.

Example
Below you can find two samples that show the request- and response telegrams of stations supporting the secure data mode. The black parts of the telegrams are common standard data mode telegrams that are extended by the secure data mode header (blue).
The speciality of the second request telegram is that the register address is equal to 181 ( = 0xB5, which corresponds to the data mode framing character). In order to avoid the value B5 in the telegram, a DLE (Data Link Escape) character is used for replacing the "B5" inside the telegram. This DLE character (0xC500, red in the second example) is two bytes long but is only counted as one byte in the secure data mode header.

	Request:	B5 10 09 02 B5 00 05 06 00 00 00 F8 1D
	Response:	B5 11 08 02 B5 01 12 34 56 78 A6 D0

 

	Request:	B5 10 09 03 B5 00 05 06 00 00 C5 00 94 C6
	Response:	B5 11 08 03 B5 01 00 00 00 00 12 FC

Is it a problem if the master talks "secure Data Mode" and the slave talks "standard data mode"?
No. In this case the master sends the secure data mode header which is not interpreted by the slave.
After the slave reads the framing character, it tries interpreting the AT command which does not have a value he recognizes. The slave therefore stopps the interpretation and again starts waiting for the next framing character which will be the one of the standard S-Bus data mode telegram. The slave will answer this request with a standard S-Bus response telegram which will be detected by the master as standard S-Bus telegram (due to the AT character).

	Request:	B5 10 09 02 B5 00 05 06 00 00 00 F8 1D
	Response:	B5 01 12 34 56 78 A6 D0

              (the blue part is ignored by the slave)

Firmware versions supporting the secure Data Mode
The secure data mode is introduced in the following firmware versions. The "deactivate option" indicates the first firmware version where the "Secure S-Bus Data mode" can be deactivated (see FAQ 101084).

System	first official FW	pilot FW	"deactivate" option
PCD1.M1x0	-	-	-
PCD1.M1x5	0E3	$A5	-
PCD1.M2xx0	1.14.23	since beginning	1.14.23
PCD2.M110/120	-	-	-
PCD2.M150	0E3	$D1	-
PCD2/4.M170	0E3	$21	-
PCS1.C4/C6/C8	0C0	-	-
PCD6.Mxxx	-	-	-
PCD3.Mxxxx	1.08.23*)	1.08.00*)	1.10.16
PCD2.M480	03C	-	-
PCD2.M5xx0	1.08.19	-	1.10.16

^*) On PCD3 systems, the Secure S-Bus Data mode has been first implemented as server and later also as client. The table above indicates the first client-implementation. The Secure S-Bus data mode server functionality has been implemented in version 03C (first pilot version has been $31).