Alpha 215C ProtocolDisclaimer: 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 SettingsI've tried various baudrates from 300, 1200, 4800, 9600, to 19200 at seven bits, even parity, 1 stop bit. They all seem to work.
TimingThe 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 SequenceThis 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]
Sign IdentificationThe 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:
Text Part0x02 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.
Message Display ModesWhere 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.
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.