Alpha 215C Protocol

Disclaimer: It used to be that the sign protocol was not publically available without cost. However, Adaptive Micro Systems has finally announced that the Alpha Communication protocol document is available for free download from their site. Tek-Solutions has the PDF version.

Note, a registered copy is $109 which gets the firmware and document updates. A registered copy with two hours of engineering support is $259.

In the past, we were mostly left with experimentation and information discovered on the net. As such, this document is not necessarily complete or correct.

Someone got me started with this fragment of QBASIC code which I ran on NT:

10 OPEN "COM1:9600,E,7,,CS,DS,CD" FOR RANDOM AS #1
20 FOR I = 1 TO 20: PRINT #1, CHR$(0); : NEXT I
30 PRINT #1, CHR$(1) + "Z00" + CHR$(2) + "AA" + CHR$(27) + " b" + "Message" + CHR$(4)

Communication Settings

I've tried various baudrates from 300, 1200, 4800, 9600, to 19200 at seven bits, even parity, 1 stop bit. They all seem to work.


The only trick seems to be that if there is longer than a second or so between characters to the sign, it assumes the data packet is done and a new one begins. You must send data to the sign in contiguous blocks.

Wake Up Sequence

This suggests that the NULs (0x00) are some type of attention getting sequence.

The odd part is that it seems you can use any character. The goal appears to be sending enough characters, which happen to be thrown away by the sign, so that it can determine the baudrate. This can be demonstrated by creating a for loop that wakes the sign with different characters.

It appears that a minimum of about 5 nuls are needed to sync the baudrate. However, once the sign has detected a new baudrate, you can get away with less.

0x01 is "start of header" [see an ASCII chart]
So we can conclude that a sequence of 0x00 or 0x01 is the best choice. Anything other than that might be taken as data, and 0xFF is out because the high bit is used for parity.

Sign Identification

The Z00 (zee zero zero) appears to be a sign identifier.

Working backwards, I'm guessing that 00 stands for all signs as it does with the Prolite Protocol.

If the value is 00, then no matter what the sign ID is, the sign responds. If the value is non-zero, it must match the sign's programmable id.

The 'Z', on the other hand, appears to identify the kind of sign in some way. This, again, can be seen by making a FOR-loop and testing all the values from 0 to 255:
Sending this...Shows the message. (Here's a guess as to the meaning.)
'!'Reports "Transmission Error" but in a moment shows the message.<
'1'Possibly one line signs?
'?'All signs?
'Z'All signs?
'f'Just the 215C? Does this work for any other models?
'z'All signs?
0xA1Reports "Transmission Ok" but in a moment shows the message.
0xB1'Same as '1'? Possibly one line signs?
0xC0Same as '?'? All signs?
0xDASame as 'Z'? All signs?
0xE6Same as 'f'? Just the 215C? Does this work for any other models?
0xFASame as 'z'? All signs?
It appears these are the same values, just with the high bit on. This makes sense, given we're using Even parity to talk with the sign, the 8th bit wouldn't be used. Additionally, it's curious the parity bit changes the behavior of the '!' message.

All other values do nothing with the sign.

Text Part

0x02 is "start of text" [see an ASCII chart]

I'm not quite sure what the "AA" +CHR$(27) +" b" (aye aye escape space bee) is doing.

After that it appears that you can have text until you get to 0x04 is "end of transmission". [see an ASCII chart]

The sign does not seem to care if there is a cr/lf sequence ending the request or not.

Sending Text

Sign Code
Sign ID
0x30 0x30
0x41 0x41 0x1B 0x20 0x62
Message EOT

Message Display Modes

Where the 'b' is above, I tried running through the full alphabet to see what would happen. This byte seems to control the display characteristics of the message.

I have not figured out how to change the message display mode in midstream of a message yet.

You might want to compare these with the Pro-Lite Display Effects.

Byte UsedDisplay Message Effect
'a' 0x61Regular smooth scroll, right to left
'b' 0x62Appear. Centers as much of message on screen, waits, and displays rest of message in similar manner
'c' 0x63Appear with flashing.
'd' 0x64Auto. Randomly picks an effect for each part of the message, as opposed to the message as a whole.
'e' 0x65Scroll up.
'f' 0x66Scroll down from top.
'g' 0x67Jerky scroll from right to left.
'h' 0x68Jerky scroll from left to right.
'i' 0x69Wipe up from bottom, covering text.
'j' 0x70Wipe down from top, covering text.
'k' 0x71Wipe over from right to left, character by character, not by pixels.
'l' 0x72Wipe over from left to right, character by character.
'm' 0x73Scroll up. Same as 'e'?
'n' 0x74This is doing something weird based on message itself. Will have to investigate.
'o' 0x75Auto/Random (same as 'd'?)
'p' 0x76--> CENTER <-- Text appears at sides and squishes content in.
'q' 0x77<-- CENTER --> Text splits in center and pushed content out.
'r' 0x78--> COVER <-- New text covers old out to in.
's' 0x79<-- UNCOVER --> New text uncovers in to out.
't' 0x80Compressed text! Using this mode the sign tricks your eyes into seeing more characters than it is capable of physically producing. Scrolls right to left.
'u' 0x81Fast Appear.
'v' 0x82Medium Appear.
'w' 0x83Maybe medium-slow appear.
'x' 0x84Same as 'p'?
'y' 0x85Same as 'q'?
'z' 0x86Same as 'r'?
'@' 0x40The sign went blank.
It is interesting to note that during Auto/Random mode, the sign produces more effects than are shown in the above table. This suggests that mode 'n' is doing something freaky, since the message seems to somehow control what happens.

I ran the whole character set through, and all of the unique modes appear in the subset above. One point of interest was when I sent 0x13 to the sign in the message, the time appeared.

It would seem that there are binary codes that expand to macros within the sign.
This page last updated [How to build a data cable] [ALPHA 215C] [Linux Communication Settings] [MindPrint]