SMX

Copyright * 1995 Strand Lighting Limited
This document and the information contained within it is issued on the strict understanding that neither Strand Lighting Ltd, nor its employees, agents, subsidiary or associated companies accept any liability for any error or omission. Strand Lighting Ltd. owns the copyright of this document and the SMX protocol which shall not be amended or substituted without prior written consent of Strand Lighting Ltd. A non-exclusive free licence is granted to you in perpetuity to use this document and the SMX Protocol.

The Overview of SMX:

PHYSICAL DETAILS

Overview

SMX uses a standard RS485 multi-drop serial data bus. Transmitters should only hold their lines active during actual transmission, and remain tri-state at other times. See Bus turnaround below.
A logical 1 is represented by the data + line being positive with respect to data -.

Data Format

Data is transmitted as asynchronous 8 bit bytes, in the following 11 bit format:
Field Bits Value
Start 1 0
Data 8 0x00 to 0xFF
Framing 1 0 or 1
Stop 1 1

The data bytes may assume any value, and these are transmitted in the standard way with LSB first.

Framing

The first byte of a frame has bit 9 (normally the parity bit in asynchronous data) as a logical 1, all subsequent bytes have a logical 0. The ninth bit at 1 always indicates the first byte of a frame. UART's supporting a "9-bit wakeup" mode may confer loading advantages by allowing software to ignore all but the header bytes of each frame.
Implementation Note: A possible work-round for a serial port not able to support "stuck parity" - I.e. 9th bit at 0 or 1, is to calculate the parity for each byte sent (in software), and set the serial port's parity accordingly. This may often involve resetting the port on each byte, which may involve a 1 byte gap in between each data byte, but no inter-byte time-outs are implemented in Strand reception software, and this causes no practical problems.

Signalling Rate
The speed of the bus may be one of the following:
* 250 kbaud
* 62.5 kbaud
* 19.2 kbaud
* 9.6 kbaud
* 2.4 kbaud
Stations shall support these standard rates up to their maximum, and may support other non-standard rates if desired. The skew of the bit edges due to timing distortion, jitter, and other factors, as seen by the receiver shall be within +/-20% of their nominal edge position. The clock speed error of the transmit and receiver clocks shall be better than +/- 0.5%.

Bus turnaround

In line with ref. (I), the transmitter must release the line to a high impedance state within 11 bit times of the last transmitted stop bit. When starting to transmit, the station must wait for at least 22 bit times after the last received stop bit, before placing the transmitter in a low impedance state.
Implementation Note: For simplicity, no "token" as such is passed around the system. If frames collide, then they are lost, and must be re-sent

COMMAND FORMAT
Typical Class 0 Frame
FADR FCTL FLEN SCTL ATYPE ARC ADATA FCS
0xFFFF 0x00 0x00 - 0xFF 0x00 0x00 -
0xFF 0x0000 Data bytes 0x0000 - 0xFFFF
Broadcast Class 0 no. of bytes in FDATA Only Segment Application dependent Not used As Required

 SMX Header   FDATA  FCS

FADR - Frame Address

All class 0 messages require a 16 bit address, but all currently implemented message data types use the broadcast "all stations" address, 0xFFFF. It is therefore possible to individually address stations, or broadcast, as required. Class 0 messages imply that no replies are allowed, even if individual stations are addressed.

FCTL - Frame Control byte

This byte is used for frame sequencing and indicating requests/responses in Class 1 (bi-directional) messages. It is set to 0 for Class 0 (unidirectional) messages.

FLEN - Frame Data Length

This 8 bit value is the count of all the bytes in FDATA. FLEN = 0 means no FDATA field is present, the maximum value of FLEN is 0xFF. A class 0 frame with FLEN shall be ignored.

FDATA - Frame Data

The Frame Data, FDATA is defined by the application. In class 0 messages, SCTL is set to 0, indicating that the message has only one segment (segmentation not allowed on class 0 messages). In general, the ARC, Application Return Code, is not used, and set to zero.
The Application Type code, ATYPE, defines the type of message transferred, e.g. Outlook (ATYPE 0x22) etc. ADATA, the Application Data, is entirely defined by ATYPE. See references (ii) and (iii) for examples.
Implementation Note: The total frame size may often be limited in practice as necessitated by the limited resources of some stations. Any designed limitations will be indicated in the specific Application Type documents.


FCS - Frame Check Sequence

The FCS definition is repeated here from ref. (I) verbatim. The FCS covers all fields within the frame including the FCS itself. The 2 bytes of the FCS are calculated so that the following summation formulae (modulo 255) are satisfied:and
Where:
I is the position of the byte in the frame.
ai is the value of the byte.
L is the no of bytes in the frame.

FCS generation

The following algorithm is an efficient way of generating and checking the FCS :
V0, V1 are variables within the algorithm.
I, L are as above.
X is the first byte of the FCS (at L-1).
Y is the second byte of the FCS (at L).
All addition is done modulo 255.
* Initialise the FCS bytes at L, L-1 to 0
* Initialise V0, and V1 to 0
* Process each byte for I=1 to L by:
a) Adding the value of the byte to V0
b) Adding the value of V0 to V1
* Calculate X and Y such that:
X = V0-V1
Y = V1- (2*V0)
* Put the values of X and Y in bytes L-1 and L respectively.

FCS checking
* Initialise V0 and V1 to 0.
* Process each byte for I=1 to L by:
a) Adding the value of the byte to V0
b) Adding the value of V0 to V1
* If V0 = V1 = 0, then the FCS is correct.

Click to expand...