Extron Electronics RGB 300 User Manual

Page 21

Appendix A • Programmer's Guide

Extron RGB 300 Universal Interface • User’s Manual

This detailed programming guide is for the user who plans to
write his/her own software for controlling the RGB 300. It is
not related to do with the Windows software described in
Chapter 4. Knowledge of hexadecimal and binary numbers is
recommended when writing programs for the RGB 300.
Number conversion is discussed on A-5.

Communication Format

The information exchange between the RGB 300 and a Host
system (connected to the RS- 232 control port) is based on a
proprietary format and protocol. The information is byte
oriented. The numeric value of each byte determines how it is
interpreted, in one of three categories:

1. Communication control. 00 thru 1F hex (0 thru 31 decimal)

2. Command codes. 20 thru 7F hex (32 thru 127 decimal)

3. Specific data. 80 thru FF hex (127 thru 255 decimal)

Command Structure

Commands from the Host system are made up as follows:

1. Command Code, followed by:
2. Data (if any), followed by:
3. Checksum, followed by:
4. End of transmission mark

Command Codes (20 thru 7F hex)

The command code is one byte, having a value ranging from
20 to 7F hex. However, the command codes used by the
RGB 300 are:
30 thru 48 hex for Commands, and 70 thru 73 for Reports.
They are listed and described later.

Data Bytes (80 thru FF hex)

Data can follow the Command Code for three reasons:

1. If the Host is sending new settings to the RGB 300, data

bytes will contain that new information.

2. Data byte(s) may be needed to make the command more

specific. For example, to tell the RGB 300 to load a new
block number, a data byte is needed to specify the block
number.

3. When the RGB 300 responds to a request for information, it

returns the original command code, followed by data bytes.

____ A data byte always has bit 7 set. Bits 0 thru 6 may be binary

encoded, or they may represent numbers 00 thru 7F hex
(decimal 0 thru 127) In the examples that follow, the value 80
hex (or 128 decimal) is often added to the information. This
makes it a data byte.

A-1

Communication Format

Checksum

The checksum is a two byte field (CKS1 & CKS2) built
according to the following procedure:

1. The binary sum (2-bytes) is calculated for all command code

and data bytes.
Example: A2B7 hex. is:

1010 0010 1011 0111

binary

2. The two most significant bits (15 & 14) are dropped. (lsb =

bit zero) Example:

--10 0010 1011 0111

binary

3. The remaining 14 bits are split into two 7-bit fields

Example:

--10 0010 1 & 011 0111

binary (45/37 hex)

4. Both 7-bit fields are padded with a “1” in the most significant

bit position, thus creating two “data type” bytes. Example:

110 0010 1 & 1011 0111

binary (C5 & B7 hex)

5. CKS1 is the most significant byte (C5), and is transmitted

first, followed by CKS2, the least significant byte (B7) of the
Checksum.

Alternate Checksum Calculation in Decimal

1. Add all transmitted bytes starting with the command code

and ending with the last data byte.
Example: 41, 655 decimal

2. If the sum is more than 16, 384 then subtract 16, 384 from it.

Example: 41, 655 - 16, 384 = 25, 271

2.a. Repeat this step until the sum is less than 16, 384.

Example: 25, 271 - 16, 384 = 8, 887

3. Divide the result from step 2 by 128

Example: 8, 887/128 = 69.429

4. Take the integer portion of the result (69) from step 3 and

add 128 Example: 69 + 128 = 197 decimal This is the first
checksum byte CKS1.

5. Take the integer portion of the result (69) from step 3 and

multiply by 128. Example: 69 x 128 = 8, 832

7. Take the result from step 5 (8, 832) and subtract it from the

result of step 2 (8, 887), and add 128 to the result.
Example: 8, 887 - 8, 832 = 55, + 128 = 183 decimal.
This becomes the second byte CKS2

End Of Transmission

This is always the single character EOT (04h).

A-2

Checksum