Version 1

Sign Panel Communications Protocol

This third generation sign communication protocol is meant for communication with an intelligent interconnect board which understands the size and layout of the sign panel.

Packet Delimiting

Packets are delimited with a packet delimeter byte, which is 0x7f. This delimeter is sent both at the beginning and end of a packet, though the ending delimeter may be treated as as beginning delimeter of the next packet if the sender is sending the packets in rapid succession.

The use of a packet delimeter of course necessitates the use of an escape byte; the escape byte is 0x7e. An escape sequence is 0x7e ESC, where ESC=b^0x50, i.e. the escaped byte is calculated with the XOR of the byte and the value 0x50.

Packet Identifier

The first byte after the packet delimeter is the packet identifier. Valid packets are indicated below in the packet section. If the value of the byte is not recognized, the interconnect board is required to forward all bytes on, immediately and unmodified, until it comes to the next packet delimeter.

If the packet is recognized but is too long or too short, then an invalid packet report should be generated and sent back to the server.

CRC

All CRCs in this protocol are the 32 bit CRC-32C (i.e. with polynomial 0x1EDC6F41). The initial remainder is 0xffffffff. If a packet fails its CRC check, an invalid packet should be sent back to the controller.

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 assumed that the available rates between 9600 and the maximum rate are the standard rates, e.g. 14400, 19200, 38400, 57600, 115200, etc.

Endian-ness

All multi-byte values in this protocol, unless otherwise specified, are in little-endian form.

PWM Duty Cycle

Unlike in previous communciations schemes, the controller sends the actual PWM duty cycle. For future compatibility, this is sent as a 16 bit unsigned int, but it just represents 0%-100% duty cycle, and the MBIB is free to translate this to its PWM hardware however is appropriate. (In practice, that will probably be by using the most significant 10 bits, but anything is fine.)

Boot Loader

When the MBIB first turns on, it will boot up with the main serial port at 9600 and in bootloader configuration. If the bootloader receives the handshake packet, it must immediately boot up the firmware, which will then probe the sign panel and send a sign description packet.

The bootloader speaks the same protocol as the main firmware, but has access to special packets not available during ordinary communication. This includes all packets which can write to the flash. The bootloader will ignore packets which do not make sense for it, such as caching and display packets.

The bootloader packets are not fully defined yet.

Message Board Info Area

The MBIB will have a 1 kilobyte area of permanent storage (e.g. flash) in which it will keep data pertaining to the sign. The first three bytes will be the three description bytes in the sign description packet (module type, led color, pfd capability). The controller will be able to program (through the bootloader) other information, such as the VIN number of the trailer, or factory ID number, etc. Other than the first three bytes, the MBIB does not need to concern itself with what information is stored in this area.

Display Error Checking

When the MBIB is instructed to display something on a row, after sending out the data and latching it, it must then enter error-checking mode to ensure That the data was received correctly by the modules. This is accomplished by sending out the data again, then reading the data which was serially shifted back from the modules.

If the data which comes back matches the data that was sent out, the MBIB is done. If it does not, the MBIB must latch, send out the data again, and compare, until the data is correct.

In short, the algorithm is to send out the data, then:

  1. Latch
  2. Send out data stream again
  3. Compare the data which comes back with what was sent out. If it matches, stop. If it does not match, goto 1.

The MBIB should do this independently on the rows, so if one row is verified and one not, only the row which is not verified will go through the resend-and-verify algorithm.

Caching

The MBIB will provide a data cache for the controller to store data streams on for use in displaying. This will enable high framerates for things like arrows and chevrons, as well as blanking between pages, while allowing us to keep a low bitrate.

For simplicity and maximum flexibility, the cache is just an area of memory which data packets can store data into and which cache display packets can refer to. The layout of the cache is entirely managed by the controller; the only responsibilities of the MBIB are recognizing the special offset value 0xffffff which means that the MBIB should generate zero-bytes instead of read from the cache, and otherwise ensuring that all cache operations are restricted to its cache area (i.e. the MBIB may not trust the controller and must clamp the offset and length such that it remains within the cache even if the values sent by the controller would not.)

The minimum cache size is 1KB. The MBIB should provide all free (contiguous) memory as cache; it does not need to worry about the cache size being a multiple of any minimum page size.

Auxiliary Sensor Channels

The MBIB can have attached to it one or more auxiliary sensors, such as a compass or doppler radar. These are addressed through the auxiliary sensor data packet. The controller sends one of these when it wants to send data to the sensor.

The MBIB must support the auxiliary sensor originating data. It should perform some sort of nagle algorithm, i.e. buffering the data coming from the auxiliary sensor for a short time (e.g. 10ms since the last byte or 200ms total for continuous writing), then spontaneously emit an Auxiliary Sensor Data Packet with that data to the controller. (The fact that this data may be a response to what the controller just sent to the sensor is irrelevant to the MBIB.)

Module Auto Detection

Since the MBIB talks to dumb modules, module parameters such as the type and LED color must be programmed into the MBIB (there are packets for this in the packet definition). Since the MBIB addresses each row independently, however, it can auto-detect the number of rows. Additionally, given a module type being programmed into it, it can detect the number of modules in a row based upon the number of LED drivers in each module.

The MBIB should do this auto-detection at startup, in order to provide the number of rows and modules in each row to the controller in the sign description packet.

HandShake

The controller will initiate communication either by speaking with the bootloader, or by sending a 0x5a handshake packet (note: the packet consists only of the byte 0x5a and nothing else; no delimiters are permitted, no CRC, etc. This is due to how the handshake works in gen2, and to ensure that out-of-date modules cannot talk to the bootloader.)

In response to the handshake packet, the MBIB should send a sign description packet. (This packet is encoded just as described above.)

Byte Count Data Type Field Value Description
1 Packet Identifier 0
8 data MBIB ID This field gives the unique ID of the MBIB which is speaking.
2 unsigned short version Firmware revision
1 unsigned byte
0V3
1V3 HD
2V3 CC
3V4
4V4 HD
5V4 CC
6V5
7V6 38mm
8V6 19mm
Module Type
1 unsigned byte
0Unknown
1Amber
2Red
3Green
4Purple
LED Color
1 unsigned byte
0Not Supported
1Supported
Pixel Failure Detection Support
1 unsigned byte row_count The number of rows which the MBIB detected.
row_count unsigned bytes For each row which the MBIB detected, the number of modules it detected in that row. 0 is an acceptable value if, for some reason, a row is missing between rows which exist.
4 unsigned byte Cache area (in bytes)
4 unsigned byte Maximum baud the MBIB can operate at.
4 CRC-32C The CRC of the packet.

Packet Definitions

Invalid Packet Report
Byte Count Data Type Field Value Description
1 Packet Identifier
1 unsigned byte
0CRC failed
1Packet too short
2Packet too long
The problem encountered.
4 CRC-32C The CRC of the packet.
Notes: This packet is only emitted by the MBIB.
Set BAUD Packet
Byte Count Data Type Value Description
1 Packet Identifier
4 unsigned int The bitrate to shift to.
4 CRC-32C The CRC of the packet.
Notes: The MBIB must foward this packet to its output before switching to the new baud rate.
Set Cache Data Packet
Byte Count Data Type Field Value Description
1 Packet Identifier
3 uint24 The offset in the cache to write to.
2 unsigned short length The number of bytes to write into the cache
length data The data to write.
4 CRC-32C The CRC of the packet.
Notes:
Display Packet
Byte Count Data Type Value Description
1 Packet Identifier
2 unsigned short PWM duty cycle.
1 unsigned byte stream_count
4*stream_count Stream Descriptor Each Stream Descriptor is 4 bytes long. It consists of a 24 bit address in the cache, followed by an 8 bit length value.
Stream Descriptor
lengthtypevalue
3uint24cache address
1uint8length (in bytes)

The cache address 0xffffff has a special value: it is not looked up in the cache but instead refers to length bytes of all zeroes.

4 CRC-32C The CRC of the packet.
Notes: The streams are for the rows in top-to-bottom order. If the controller wishes to omit a row (e.g. only the bottom row is updating in order to display chevrons), it would still have to include stream descriptors for each row above the one it wants to draw, it would just set them to length zero.
Set V-led Packet
Byte Count Data Type Value Description
1 Packet Identifier
2 unsigned short The value for V-led (i.e. the voltage supplied to the LEDs), in millivolts.
4 CRC-32C The CRC of the packet.
Notes: Once the power supply for V-led is set to as close as the MBIB can come to the requested value, the MBIB should send this packet back to the controller.
Pixel Failure Detection Packet
Byte Count Data Type Value Description
1 Packet Identifier
1 unsigned byte
0Detect Open Failures
1Detect Shorted Failures
Pixel failure detection type
1 bit field A bit field of the rows to test. Bit 0 corresponds to row 0, and so on.
4 CRC-32C The CRC of the packet.
Notes: This packet causes the sign panel to perform pixel failure detection and return the results with a Pixel Failure Report Packet.
Pixel Failure Report Packet
Byte Count Data Type Value Description
1 Packet Identifier
1 unsigned byte The pixel failure type. Same values as the failure detection type in the pixel failure detection packet.
1 unsigned byte stream_count The number of streams
1 unsigned byte stream_length The length of each stream
stream_count * (stream_length+1) stream The stream consists of an initial byte which indicates which row this stream is for, then stream_length data bytes from the stream.
4 CRC-32C The CRC of the packet.
Notes: This packet causes the sign panel to perform pixel failure detection and return the results.
Set Module Information Packet
Byte Count Data Type Value Description
1 Packet Identifier
8 key data 38:af:1e:ff:dd:e3:d0:13 A key which serves to ensure that this packet is deliberate.
1 unsigned byte The module type. The values are the same as in the sign description packet.
1 unsigned byte LED color. The values are the same as in the sign description packet.
1 unsigned byte PFD support. Same values as in the sign description packet.
4 CRC-32C The CRC of the packet.
Notes: The key exists mostly because this would be a short packet without it, and we had problems with a short module programming packet in gen2. Admittedly, that had a 16 bit CRC, but this is cheap and easy, and it would be very, very bad to program the modules by accident.

This is a bootloader-only packet.

Auxiliar Sensor Stream
Byte Count Data Type Value Description
1 Packet Identifier
1 unsigned byte The channel. Note: the high bit is set to 1 if this packet originated on the controller, 0 if it originated on the MBIB.
1 unsigned byte length The number of bytes of data.
length The data payload
4 CRC-32C The CRC of the packet.
Notes: The data must be sent out the serial port exactly as is; the MBIB is to do no kind of packet encoding or escaping. If the encoded protocol is has flag bytes or is escaped, that must be handled on the data that the controller sends up. If it uses the same framing and escape bytes as this protocol, that is merely unfortunate as they will all get escaped when this packet is sent.
Read Message Board Info Area Packet
Byte Count Data Type Value Description
1 Packet Identifier
2 unsigned short offset
2 unsigned short length
4 CRC-32C The CRC of the packet.
Notes:
Message Board Info Area Packet
Byte Count Data Type Value Description
1 Packet Identifier
2 unsigned short offset The offset where the data came in.
2 unsigned short length The length of the data
length data the data from the area at offset offset
4 CRC-32C The CRC of the packet.
Notes: