Sign Panel Communications Protocol
CRC
All CRC's used in this protocol are 2-byte Cyclic Redundancy
Checks based on the CRC-16-CCITT polynomial x^16 + x^12 + x^5 +
1 (0x1021). The initial remainder is 0xffff, the final XOR value
is 0x0000, and neither the data nor the remainder are
reflected.
The CRC is encoded in little-endian form.
Note: both the intelligent interconnect board and the modules
are required to check the CRC for the packets they recieve.
Addresses
Addresses used in this protocol will be 1 byte, divided up as
follows: the two most significant bits will designate the row
number, with 0 designating the top row. The 6 least significant
bits will designate the position within the row, with the first
module on the string being 0 and the last module on the string
being 63.
Modules should ignore the two most significant bits of an
address byte when comparing the byte to their own address. The
intelligent interconnect board, if it is attached to the system,
is responsible for inserting the row number on any packets
originating from the modules which contain addresses.
Please note: any software which changes an address is
required to recompute a new CRC for the packet.
Communication Rates
All devices implementing this protocol must be able to speak
@ 9600 bits/second. They may optionally implement one or more
speeds higher than that.
It is recommended that the intelligent interconnect board
report its maximum rate as the lesser of its physical maximum
rate and the maximum rate of its connected modules multiplied by
the number of rows attached. (For example, an intelligent
interconnect board with three rows attached @ 9600bps should
report a maximum rate of 28800.) This will allow the controller
to send data up to the interconnect board using a single DMA
transaction without requiring large buffers on the interconnect
board.
Endian-ness
All multi-byte values in this protocol, unless other
specified, are in little-endian form.
New Packet Encoding
In order to streamline operation and promote forward
compatibility, a new packet encoding format is defined. This
encoding begins each packet with a start-of-packet byte, then
uses an escape sequence to encode either a start-of-packet byte
or an escape byte. The packet encodings are otherwise
unchanged.
In order to promote backward compatibility, this new encoding
is turned on (if it is going to be turned on) immediately after
the handshake packet and before the what-the-heck-are-you packet
is sent. It is intiated with a "protocol version request
packet". If this packet is not received before a
what-the-heck-are-you packet, it should not be accepted in
future operation (to avoid a corrupted packet accidentally
turning this on).
If the protocol version is not set with a protocol version
request packet, modules and other devices should operate in the
older mode, without any start-of-packet or escape bytes.
Unrecognized Packets
Immediately after the start-of-packet byte will be the packet
ID for the packet. If a module (or other device) does not
recognize this packet, it should forward all bytes it receives
until it sees another start-of-packet byte. In this way the
modules and other devices will be forward-compatible, able to
pass on packets that they don't recognize. (note: this means
that they should pass on escape bytes unmodified, and should not
do escaping of the bytes.)
Since a module can resynchronize onto the next packet simply
by waiting for a packet ID it recognizes after a start-of-packet
byte, devices should not send out noop packets to resynchronize,
as in the old version of this protocol.
Encoding
The start of packet byte is 0xfc. The escape byte is 0xfd. The following escape sequences are recognized:
Escape sequence | Decoded value |
0xfd 0x0c | 0xfc |
0xfd 0x0d | 0xfd |
As a reminder, this is an on-the-wire encoding, so it is done
as the last step before transmission and the first step before
interpretation. Thus the start-of-packet byte must be stripped
and all escape sequences decoded before checking the CRC on a
packet.
Handshake
The purpose of the handshake is to determine the setup
information and establish the communication rate. Communication
always begins at 9600 bits/second.
The handshake packets are, roughly in the order typically transmitted:
Handshake Request Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x5a |
Can we handshake? |
Handshake Ack Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x5a |
Sure! |
Modules are required to pass the handshake ack
packet on to the next module in the chain unchanged. The
intelligent interconnect board is required to send it back
to the controller. |
What the heck are you? Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x02 |
Packet Type |
Sign Description Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x03 |
Packet Type |
1 |
unsigned byte |
|
Sign description:
0x00 | Intelligent Interconnect Board attached to V3 HDs |
0x01 | Intelligent Interconnect Board attached to V6 HD |
0x02 | Intelligent Interconnect Board attached to V6 LD |
0x03 | V3 HD |
0x04 | V6 HD |
0x05 | V6 LD |
0x06 | V4 HD |
0x07 | Intelligent Interconnect Board attached to V4 HD |
0x08 | V3 |
0x09 | V4 |
0x0a | V5 |
0x0f | Newer Module |
The top two bits of this byte indicate the color of the LEDs and have the following meaning:
0x00 | LED Color Unknown |
0x40 | Amber LEDs |
0x80 | Red LEDs |
0xc0 | Green LEDs |
The top two bits are independent of the module/interconnect bits.
The third top bit (bit 5, corresponding to the bit mask
0x20) indicates the orientation of the module. The meaning is as follows:
0x00 | normal (horizontal) |
0x20 | rotated (vertical) |
The fourth top bit indicates whether an advanced sign description packet is supported:
0x00 | Not supported |
0x10 | Advanced Sign Description Supported |
|
1 |
address byte |
|
Maximum Address. The interconnect board shall report the
address of the highest address module (i.e. the
bottom-right module). Modules report as described below. |
4 |
unsigned integer |
|
The maximum bit rate supported by this communications device (e.g. 9600, 115200, etc). |
2 |
CRC |
|
CRC as defined by the protocol. |
If a module recieves a what-the-heck-are-you
packet, it will originate a sign description packet (with
an address of 0x00). If a module recieves a sign
description packet, it will increment the address byte by
one, recalculate the CRC, and pass the packet on. Thus
once the packet falls off of the end of the module string,
it will contain the highest address for the
string. (Incidentally, though it's not necessary, the
modules might as well record their address in case it
comes up in error reporting before an address packet comes
through.)
NOTE:This sign description packet does not include
later modules such as the V13. They are required to use
the 0x0f newer module indicator and the controller will
request an advanced sign description packet. They are,
however, required to fill out the address and baudrate
section of this packet. |
If the sign description packet indicates that the modules
support an advanced sign description packet, the controller will
send one and the modules will fill it out and return it:
Advanced Sign Description Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0xaa |
Packet Type |
1 |
unsigned byte |
1 |
Protocol Version. |
1 |
unsigned byte |
|
Communication Hardware Description:
0x01 | Bare Modules |
0x02 | Intelligent Interconnect Board |
0x03 | Parallel Interconnect Board |
|
1 |
unsigned byte |
|
Sign description:
0x00 | Intelligent Interconnect Board attached to V3 HDs |
0x01 | Intelligent Interconnect Board attached to V6 HD |
0x02 | Intelligent Interconnect Board attached to V6 LD |
0x03 | V3 HD |
0x04 | V6 HD |
0x05 | V6 LD |
0x06 | V4 HD |
0x07 | Intelligent Interconnect Board attached to V4 HD |
0x08 | V3 |
0x09 | V4 |
0x0a | V5 |
|
1 |
unsigned byte |
|
The LED color.
0x00 | LED Color Unknown |
0x01 | Amber LEDs |
0x02 | Red LEDs |
0x03 | Green LEDs |
0x04 | White LEDs |
|
1 |
unsigned byte |
|
Module orientation.
0x00 | unknown orientation |
0x01 | normal (horizontal) |
0x02 | rotated (vertical) |
|
1 |
unsigned byte |
|
The LED revision. This is used in the computation of an appropriate V-LED setting.
|
1 |
unsigned byte |
|
Sign Panel Row Count (0 if there are only bare modules) |
1 |
unsigned byte |
|
Sign Panel Column Count (0 if there are only bare modules) |
1 |
unsigned byte |
|
Interconnect Board Firmware Version (0xff for N/A) |
1 |
address byte |
|
Maximum Address. The maximum possible address given
the shape of the sign, regardless of whether the module
that should be there is actually present and alive. How
bare modules should fill this field in is described in the
notes. |
4 |
unsigned integer |
|
The maximum bit rate supported by this communications device (e.g. 9600, 115200, etc). |
8 |
data |
0 |
Reserved. |
2 |
CRC |
|
CRC as defined by the protocol. |
If a module recieves a what-the-heck-are-you
packet, it will originate a sign description packet (with
an address of 0x00). If a module recieves a sign
description packet, it will increment the address byte by
one, recalculate the CRC, and pass the packet on. Thus
once the packet falls off of the end of the module string,
it will contain the highest address for the
string. (Incidentally, though it's not necessary, the
modules might as well record their address in case it
comes up in error reporting before an address packet comes
through.) |
Bit Rate Request Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x10 |
Packet Type |
4 |
unsigned integer |
|
requested bit rate (e.g. 9600, 115200, etc.) |
2 |
CRC |
|
CRC as defined by the protocol. |
The controller can request any bit rate that
it likes. If the sign can comply, it will switch to that
bit rate permanently (if the controller can't talk to it
at that speed, the controller will reset the
modules). There's no acknowledgement of success or error
on failure (even CRC failure) because after requesting
the rate change, the controller will change its bit rate
accordingly, wait a respectable period (e.g. 1000ms),
then send a handshake request packet. If the sign answers
with a handshake ack packet, then the controller knows
that everything has gone well. If it doesn't get back an
ack packet, it will reset the modules and try again three
times. If four tries doesn't work, we don't really have a
prayer at the higher speed anyway, so we'll stay at the
lower speed. The controller will indicate an error
condition if it timed out attempting to establish a
communication speed which the sign panel advertised
itself as capable of. |
Normal Operation
Normal operation is typically synchronous — that is,
the sign panel typically only sends packets in response to the
controller. This is not always the case, however. The sign panel
is permitted to send error packets on its own when it has
detected that communication has broken down. It's also permitted
to send data packets on its own.
Since bytes can go missing, which will screw up the protocol,
modules are required to send comm error packets on CRC failures
and all other communication errors. When the controller notices
a comm error packet, it will immediately resynchronize with the
sign by sending 2N resync packets (described below) where
N is the size of the largest packet described in this
protocol. Resync packets are 1-byte packets passed on unchanged
from module to module. After the controller starts
resynchronization, it will know that resynchronization is
achieved once it gets a resync packet back. Except during
resynchronization, the controller will ignore resynchronization
packets. It is believed that the typical error rate will be low,
so the extra time taken during the rare event of protocol errors
is a good trade-off for the efficiency of not including error
correction bytes.
Global packets are passed on by modules unaltered, and
distributed simultaneously by the interconnect board to all rows
(if the interconnect board fails to get the global packet back
from any populated row, it will send a communications error
packet back to the controller).
Prior to sending a batch of local packets, the sign
controller will send an address packet so that every module
knows its address. Local packets are passed unmolested from
module to module until a module recieves a packet with its
address. It then acts on the packet and does nothing
further. There's no need for ack packets because the odds of an
entire local packet getting lost are so small (given the minimum
size for local packets) that it's not worth worrying about. Any
errors caused by local packets completely dropping out will be
corrected within 2 seconds by the next data sent up to the sign
in any event. Anything other than complete packet loss will
result in a detected and reported communications error
packet. (And actual severing of the communications lines will be
detected by global packets not returning.)
Note: since all packets have a known size, they do not
include a byte count. This helps to guard against errors because
if the wrong bytes are used as the byte count (because previous
bytes have been lost), a module could concievably start waiting
for 65,536 bytes to come in, which will delay resynchronization
considerably.
Note: all unrecognized packet types will be treated as an
error and the module which recieves it will transmit a
communications error packet.
NOTE: there was a second draw packet which was added because
of pixel failure detection. The first, original draw packet will
not trigger an incremental pixel failure to be performed, while
the new draw packet will trigger the incremental pixel
failure test.
Appendix A. Packet Definitions
Draw Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x11 |
Packet Type |
1 |
unsigned byte |
|
Sign intensity. |
2 |
CRC |
|
CRC as defined by the protocol. |
The draw command causes the module to
display the most recent data it was sent via a data
packet.
0 is the minimum intensity and 255 is the
maximum intensity. If a full intensity table is too
complex for a given module to implement, it is recommended
that the module only implement the top 4 bits of the
intensity. That is, it should use a 16 entry table and
convert the intensity byte by the operation (i >> 4). This
ensures forward compatibility with hardware which has
enough memory to implement a full 256 entry intensity
table. |
V3 HD Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x12 |
Packet Type |
1 |
address |
|
Module Address |
10 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC as defined by the protocol. |
Since a V3 HD module is 8 pixels wide and 10 pixels
high, the module data is coded in rows, where the first
byte is the top row, the second byte is the second row
from top, etc. |
V6 HD Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x13 |
Packet Type |
1 |
address |
|
Module Address |
96 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC as defined by the protocol. |
The pattern is specified in 32 pixel strips,
where each 4 bytes correspondings to a row or column in
along the 32 pixel orientation. (Up and down don't mean
much since the modules may be oriented in either direction
on the sign panel.) The first 4-byte group corresponds to
either the left column or the top row of the module,
depending on the module's orientation. |
V6 LD Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x14 |
Packet Type |
1 |
address |
|
Module Address |
24 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC as defined by the protocol. |
The pattern is specified in 16 pixel strips,
where each 2 bytes correspondings to a row or column in
along the 16 pixel orientation. (Up and down don't mean
much since the modules may be oriented in either direction
on the sign panel.) The first 2-byte group corresponds to
either the left column or the top row of the module,
depending on the module's orientation. |
V3/V4 Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x15 |
Packet Type |
1 |
unsigned byte |
|
Module Address |
9 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC |
The pattern is specified where each byte
corresponds to the row, the zeroth byte corresponding to
the top row, the 8th byte to the bottom row. |
V5 Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x16 |
Packet Type |
1 |
unsigned byte |
|
Module Address |
18 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC |
The pattern is specified as if there were two V3s next to each other, the v3 on the left first. |
No-Op Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x17 |
Packet Type |
The no-op packet is used for resynchronization of the protocol. |
Error Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x18 |
Packet Type |
1 |
address |
|
Module Address |
1 |
unsigned byte |
|
Error Condition:
0 | Lost Communication |
1 | Unreturned Global |
2 | LED failure |
3 | Electronic failure |
4 | Intensity Table CRC check failed |
5 | Position-dependent packet prior to Address Packet |
6 | VLED problem detected. |
7 | Module unconfigured. |
8 | Packet attempted to reprogram EEPROM without sending EEPROM Unlock Packet first. |
|
2 |
CRC |
|
CRC |
Note: the address that the module sends is the
last address it received from an address packet, or 0 if it
never received an address packet.
Note: if the
interconnect board doesn't recieve a global packet back from
a row, it will report the lost communication as occurring at
address 63 in the row that the global didn't return
from. |
Protocol Error Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x19 |
Packet Type |
1 |
address |
|
Module Address |
2 |
CRC |
|
CRC |
This packet signifies that a protocol error
has occurred (i.e. some packet failed its CRC
check).
Note: the address that the module sends is
the last address it receives from an address packet, or 0
if it never received an address packet. |
Sensor Data Request Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x1a |
Packet Type |
2 |
crc |
|
CRC |
Requests that the interconnect board send a
sensor data packet for each of its sensors. This is a local
packet, but is not addressed because the interconnect board
is always directly connected. |
Sensor Data Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x1b |
Packet Type |
1 |
unsigned byte |
|
Sensor type:
0 | Temperature Sensor |
1 | Humidity Sensor |
2 | High Water detector |
3 | Barometer |
4 | Photocell |
5 | Radar Gun |
6 | Scale |
7 | Compass |
|
4 |
varies |
|
Sensor reading |
2 |
CRC |
|
Packet CRC |
The interpretation of the sensor reading is
dependent on the sensor type. For compass, the 4 bytes are
a little-endian integer representing in centi-degrees. |
Intensity Table Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
1c |
Packet Type |
32 |
short[] |
|
The intensity table. It's an array of 16 little-endian
short integers. The duty cycle is (1024
- value)/1024, and the table is in increasing
order of duty cycle (i.e. the first table entry
corresponds to intensity 0, and the last corresponds to
intensity 16). |
2 |
CRC |
|
Table CRC (CRC of the table only) |
2 |
CRC |
|
Packet CRC (covers the table crc as well as the packet type & the table) |
Serial Number Request Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
1d |
Packet Type |
2 |
CRC |
|
Packet CRC |
Module Serial Number Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
1e |
Packet Type |
1 |
address |
|
Module Address |
4 |
unsigned integer |
|
Module Serial Number |
2 |
CRC |
|
Packet CRC |
Address Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
1f |
Packet Type |
1 |
unsigned byte |
|
Address |
2 |
CRC |
|
Packet CRC |
The controller sends out the address packet
starting at 0. Each module records its address from the
packet, then increments the address number, recalculates
the CRC, and passes the address on. |
Pixel Failure Report Request Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x80 |
Packet Type |
1 |
unsigned byte |
|
module address |
2 |
CRC |
|
Packet CRC |
Notes:Requests the module's current map of failed pixels. Does not cause any pixel failure testing to take place prior to the report. |
V3 / V4 Pixel Failure Report Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x81 |
Packet Type |
1 |
unsigned byte |
|
module address |
9 |
unsigned bytes |
|
Pixel Failure pixmap data |
2 |
CRC |
|
Packet CRC |
Notes:The data is arranged in exactly the same way as with the Data Packet.
|
V5 Pixel Failure Report Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x82 |
Packet Type |
1 |
unsigned byte |
|
module address |
18 |
unsigned bytes |
|
Pixel Failure pixmap data |
2 |
CRC |
|
Packet CRC |
Notes:The data is arranged in exactly the same way as with the Data Packet.
|
V3 HD / V4 HD Pixel Failure Report Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x83 |
Packet Type |
1 |
unsigned byte |
|
module address |
10 |
unsigned bytes |
|
Pixel Failure pixmap data |
2 |
CRC |
|
Packet CRC |
Notes:The data is arranged in exactly the same way as with the Data Packet.
|
V6 38mm Pixel Failure Report Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x84 |
Packet Type |
1 |
unsigned byte |
|
module address |
24 |
unsigned bytes |
|
Pixel Failure pixmap data |
2 |
CRC |
|
Packet CRC |
Notes:The data is arranged in exactly the same way as with the Data Packet.
|
V6 19mm Pixel Failure Report Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x85 |
Packet Type |
1 |
unsigned byte |
|
module address |
96 |
unsigned bytes |
|
Pixel Failure pixmap data |
2 |
CRC |
|
Packet CRC |
Notes:The data is arranged in exactly the same way as with the Data Packet.
|
Draw Packet w/ Incremental Pixel Failure Test (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x8f |
Packet Type |
1 |
unsigned byte |
|
Sign intensity. |
2 |
CRC |
|
CRC as defined by the protocol. |
This draw command causes the module to
first perform an incremental pixel failure test (i.e. of
one module) and then display the most recent data it was
sent via a data packet.
0 is the minimum intensity and 255 is the
maximum intensity. If a full intensity table is too
complex for a given module to implement, it is recommended
that the module only implement the top 4 bits of the
intensity. That is, it should use a 16 entry table and
convert the intensity byte by the operation (i >> 4). This
ensures forward compatibility with hardware which has
enough memory to implement a full 256 entry intensity
table. |
Test Module for Pixel Failures Packet (local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x8e |
Packet Type |
1 |
unsigned byte |
|
Module Address |
1 |
unsigned byte |
|
the number of additional pixel clocks to hold the pixel on for during a test past the minimum (0-255) |
1 |
|
|
the number of milliseconds to wait between testing each individual pixel |
2 |
CRC |
|
Packet CRC |
This packet causes the module to perform a
whole-module test of every pixel, according to the
supplied parameters. When the module is finished with the
test, it then returns the appropriate pixel failure report
packet. |
Pixel Failure Detection Capability Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x8c |
Packet Type |
2 |
CRC |
|
Packet CRC |
This packet should just be forwarded on if a
module supports PFD. If it does not, consuming it or
generating a protocol error are both acceptable. |
Incremental PFD Pixel Clock Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x8d |
Packet Type |
1 |
unsigned byte |
|
Pixel Clock count |
2 |
CRC |
|
Packet CRC |
NOTES: this packet sets the # of pixel clock cycles the module will use for doing incremental tests. |
V13 Data Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x95 |
Packet Type |
1 |
address |
|
Module Address |
9 |
unsigned bytes |
|
Pattern Data |
2 |
CRC |
|
CRC as defined by the protocol. |
Since a V13 module is 8 pixels wide and 9 pixels
high, the module data is coded in rows, where the first
byte is the top row, the second byte is the second row
from top, etc. |
V-LED Levels Packet (Global)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x96 |
Packet Type |
2 |
unsigned short |
|
V-LED for normal operation (in millivolts) |
2 |
unsigned short |
|
V-LED for pixel test (in millivolts) |
2 |
CRC |
|
Packet CRC |
This packet programs the module with the V-LED values to use for normal operation and when doing a pixel failure test.
Note: the module may not have milivolt accuracy in its V-LED setting.
NOTE:This packet must be preceded by an EEPROM Unlock Packet. |
V-LED Level Override Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x97 |
Packet Type |
1 |
unsigned byte |
|
module address |
2 |
unsigned short |
|
V-LED level (millivolts) |
2 |
CRC |
|
Packet CRC |
This packet gives the module a temporary override value that takes precedence over anything set with the V-LED levels packet. (temporary as in it goes away when power is lost) Note: the module may not have milivolt accuracy in its V-LED setting. |
Power-On Delay Packet (Local)
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x98 |
Packet Type |
1 |
unsigned byte |
|
module address |
2 |
unsigned byte |
|
power-on delay (milliseconds) |
2 |
CRC |
|
Packet CRC |
This packet is meant to program the module with its particular power-on time. Each module in a sign panel will be programmed with a separate power-on time so that they will power on sequentially, putting a lower load on the power supply. Note: The module may not have full milisecond accuracy on its startup time. |
Protocol Version Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0xff |
Packet Type |
1 |
byte |
|
protocol version |
2 |
CRC |
|
Packet CRC |
The selects a new protocol version to use after initial communication at the default protocol version. A version number of 0 denotes the old protocol, but this is pointless as its the default and older modules do not understand this packet anyway. A version of 1 denotes the version of the protocol with start-of-packet and escape bytes. The protocol version packet must be forwarded before the new protocol is engaged. |
Appendix B. Packet types
Appendix C. Suitable Packet Codes
The following is a list of possible packet type codes which are at least
three bit-shifts away from each other (all codes are in hexadecimal):
02, 03, 10, 11, 12, 13, 14, 15, 17, 18, 19, 1a, 1b, 1c, 1d,
1e, 1f, 2c, 5a, 5b, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 8a,
8b, 8c, 8d, 8e, 8f, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 9a,
9b, 9c, 9d, 9e, 9f, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa,
ab, ac, ad, ae, af, b8, b9, ba, bb, bc, bd, be, bf, c0, c1, c2,
c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf, d0, d1, d2,
d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df, e0, e1, e2,
e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef, f0, f1, f2,
f3, f4, f5, f6, f7, f8, f9, fa, fb, fc, fd, fe, ff
Appendix D. Integrated Compass
The integrated compass is a pass-through device which we
communicate with by sending it packets inside of module data
packets addressed to module 0xfe. This is done in order to
smuggle the packets past the modules who do not understand any
compass-related packets. The compass is the last device in the
communication chain so it sends packets directly back to the
controller in response.
The returned data does not go through modules so could, in
theory, be in any format, but for convenience of parsing on the
controller side the response packets are formatted like a normal
sign communication protocol packet.
Below is an example of the packets sent to the compass
embedded in a V3 data packet (but, again, they can be embedded
in any module data packet and because of limitations in older
modules should be embedded in the data packet for whatever
modules the sign is composed of). Following are the packets the
compass will respond with.
Compass Calibration Data Request Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x15 |
Packet Type(V3 Data) |
1 |
unsigned byte |
0xfe |
Compass Module Address |
1 |
unsigned byte |
0x14 |
Compass Request Type(Calibration Data) |
8 |
unsigned bytes |
0 |
V3 Data Filler |
2 |
CRC |
|
Packet CRC |
NOTES: Packet used to request a compass calibration packet from the compass module. 0xfe is a unique module address the compass listens for. |
Axis Data Request Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x15 |
Packet Type(V3 Data) |
1 |
unsigned byte |
0xfe |
Compass Module Address |
1 |
unsigned byte |
0x15 |
Compass Request Type(Axis Data) |
8 |
unsigned bytes |
0 |
V3 Data Filler |
2 |
CRC |
|
Packet CRC |
NOTES: Packet used to request an Axis Data Packet from the compass module. 0xfe is a unique module address the compass listens for. |
Compass Axis Data Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x93 |
Packet Type |
1 |
unsigned byte |
0xfe |
Compass Module Address |
2 |
unsigned bytes |
|
Accelerometer X low and high bytes |
2 |
unsigned bytes |
|
Accelerometer Y low and high bytes |
2 |
unsigned bytes |
|
Accelerometer Z low and high bytes |
2 |
unsigned bytes |
|
Magnetometer X low and high bytes |
2 |
unsigned bytes |
|
Magnetometer Y low and high bytes |
2 |
unsigned bytes |
|
Magnetometer Z low and high bytes |
2 |
CRC |
|
Packet CRC |
NOTES: This packet comes as a response to an Axis data request. The low bytes comes first
in the two byte raw readings from accelerometer and magnetometer. Data is used to calculate out bearing using vectors. |
Compass Calibration Data Packet
Byte Count |
Data Type |
Value |
Description |
1 |
unsigned byte |
0x94 |
Packet Type |
1 |
unsigned byte |
0xfe |
Compass Module Address |
2 |
unsigned bytes |
|
Minimum X low and high bytes |
2 |
unsigned bytes |
|
Maximum X low and high bytes |
2 |
unsigned bytes |
|
Minimum Y low and high bytes |
2 |
unsigned bytes |
|
Maximum Y low and high bytes |
2 |
unsigned bytes |
|
Minimum Z low and high bytes |
2 |
unsigned bytes |
|
Maximum Z low and high bytes |
2 |
CRC |
|
Packet CRC |
NOTES: Response packet to a request for the calibration data stored on the compass module. This calibration
is separate from the install calibration and should be pre installed on a compass module. It is used to calculate offsets to the bearings. |