Jump to content

SMX Protocol ?


TWilkie

Recommended Posts

Hi All,

I have been searching a long time to find information on the Strand SMX protocol. The only refference I can find is that it uses a non-standard 9 bit communication stream. I have requested the detailed information from Strand, and they are happy to help, but it is so old that the full original docs are hard to find.

If anyone here has specific details on SMX I would appreceate a copy...

 

My email address is: terry.wilkie@cirquedusoleil.com

 

Regards,

 

Terry

Link to comment
Share on other sites

I believe the Strand GSX has a SMX output, maybe try the manual for that desk, should have some kind of info about it on there.

 

 

Tom

 

 

EDIT: A quick google search revealed that SMX was apparently one of the various digital protocals that was invented before DMX became industry standard. Had the advantage of error reporting, but I cant seem to find a reason why it never took off..

Link to comment
Share on other sites

SMX was apparently one of the various digital protocals that was invented before DMX became industry standard. Had the advantage of error reporting, but I cant seem to find a reason why it never took off..

 

I was under the impression that SMX (Strand MultipleX) was actually created by Strand to supercede DMX. It believe it was devised sometime around 93, and published as an open standard in 96. It wasn't adapted by manufacturers due to its relative complexity when compared to DMX.

 

Given it was published as an open standard I assume there is kicking about somewhere a full spec sheet for it. I havn't been able to locate one though.

Link to comment
Share on other sites

Dear All

 

Off the top of my head, I think there may be some information in these two volumes:

 

Control Systems for Live Entertainment - John Huntington

Let There Be Light - Entertainment Lighting Software Pioneers in Conversation - Robert Bell

 

My copies are at work, so if anyone has them to hand perhaps they can check.

 

ESTA or USITT might be worth a try; mind you, the following ESTA .pdf is all I can find:

 

ESTA Document

 

Hope this helps in some way.

 

Ken

Link to comment
Share on other sites

  • 1 month later...

Hi All,

I've aquired some of the public domain docs regarding SMX. First the copyright and disclaimer:

 

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.

 

 

 

Simple... Right :)

:D

 

Regards,

 

 

Terry

Link to comment
Share on other sites

A quick google search revealed that SMX was apparently one of the various digital protocals that was invented before DMX became industry standard. Had the advantage of error reporting, but I cant seem to find a reason why it never took off..

 

Simple... Right

 

 

SMX was designed to provide fault reporting and other nice features, unfortunatly it is so complex that it is seldom seen in practice!

 

Barney

Link to comment
Share on other sites

the lack of takeup might be involved with V*L - they had feedback down DMX cable pins 4 and 5 IIRC - maybe they thought that V*L would have a go at them in court over 'intelligent items' giving feedback down the control cable...
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.