Version 16

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 sequenceDecoded value
0xfd 0x0c0xfc
0xfd 0x0d0xfd

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:
0x00Intelligent Interconnect Board attached to V3 HDs
0x01Intelligent Interconnect Board attached to V6 HD
0x02Intelligent Interconnect Board attached to V6 LD
0x03V3 HD
0x04V6 HD
0x05V6 LD
0x06V4 HD
0x07Intelligent Interconnect Board attached to V4 HD
0x08V3
0x09V4
0x0aV5
0x0fNewer Module
The top two bits of this byte indicate the color of the LEDs and have the following meaning:
0x00LED Color Unknown
0x40Amber LEDs
0x80Red LEDs
0xc0Green 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:
0x00normal (horizontal)
0x20rotated (vertical)
The fourth top bit indicates whether an advanced sign description packet is supported:
0x00Not supported
0x10Advanced 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:
0x01Bare Modules
0x02Intelligent Interconnect Board
0x03Parallel Interconnect Board
1 unsigned byte Sign description:
0x00Intelligent Interconnect Board attached to V3 HDs
0x01Intelligent Interconnect Board attached to V6 HD
0x02Intelligent Interconnect Board attached to V6 LD
0x03V3 HD
0x04V6 HD
0x05V6 LD
0x06V4 HD
0x07Intelligent Interconnect Board attached to V4 HD
0x08V3
0x09V4
0x0aV5
1 unsigned byte The LED color.
0x00LED Color Unknown
0x01Amber LEDs
0x02Red LEDs
0x03Green LEDs
0x04White LEDs
1 unsigned byte Module orientation.
0x00unknown orientation
0x01normal (horizontal)
0x02rotated (vertical)
1 unsigned byte The LED revision. This is used in the computation of an appropriate V-LED setting.
0x00Revision Unknown
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:
0Lost Communication
1Unreturned Global
2LED failure
3Electronic failure
4Intensity Table CRC check failed
5Position-dependent packet prior to Address Packet
6VLED problem detected.
7Module unconfigured.
8Packet 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:
0Temperature Sensor
1Humidity Sensor
2High Water detector
3Barometer
4Photocell
5Radar Gun
6Scale
7Compass
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

Packet Type # Packet Type
0 Item Insertion Packet
1 Library Item Insertion Packet
2 Item Request Packet
3 Library Item Request Packet
4 Item List Request Packet
5 Library Item List Request Packet
6 Item List Packet
7 Library Item List Packet
8 Item Deletion Packet
9 Library Item Deletion Packet
10 Library Creation Packet
11 Library Deletion Packet
12 Active Library Query Packet
13 Active Library Packet
14 Library Font Restriction List Packet

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.