{short description of image}

Protocol

Version 1.1

1. Purpose

1.1 The purpose of the Able-Baker {short description of image} Protocol is to provide a simple method for two devices to share status information. It is not suitable for transferring large amounts of data. It is designed to be easy to implement and test using the Microsoft Windows HyperTerminal program. This is an open protocol.

Top of page

2. Specifications

2.1 - The Able-Baker {short description of image} Protocol is suitable for any point to point network hardware system. It was primarily developed for RS-232C serial communication ports.

2.2 - The Able-Baker {short description of image} Protocol is set up to be used in a Master-Slave format. However, unsolicited responses from the Slave unit are supported.

2.3 - The Able-Baker {short description of image} Protocol is an ASCII protocol. The protocol can be used at any Baud rate with or without hardware parity checking and with or without flow control.

2.4 - If the Able-Baker {short description of image} Protocol is used with software flow control the XON (DC1 - ASCII 17 ) and XOFF (DC3 - ASCII 19 ) characters must be removed from the string before (or during) parsing. This may be implemented in either hardware or software.

2.5 - The Able-Baker {short description of image} Protocol uses 100% redundancy. Each message command is transmitted twice in a single frame to insure data validity. The Expanded Response format is an exception to this requirement. The expanded response format sis intended for non-critical information. (If error checking is desired the query may be transmitted twice and the results compared.)

Top of page

3. Framing

3.1 - The Able-Baker {short description of image} Protocol is made up of a normal frame of four ASCII characters or an expanded response frame of eight characters.

3.2 - The normal frame has a Start Character, two message characters, and a termination character.

3.2.1 - Start Character - Always "!" (exclamation point ASCII - 33)

3.2.2 - Message Characters - Any character from the translation table repeated twice. (For example "AA")

3.2.3 - Termination Character - Always Carriage Return (ASCII - 13)

3.3 - The expanded response frame has a Start Character, an expanded response format character, three message characters, and a termination character.

3.3.1 - Start Character - Always "!" (exclamation point ASCII - 33)

3.3.2 - Expanded Response Format Character - Always "." (period ASCII - 46)

3.3.3 - Message Characters - Any three alpha-numeric characters. Non alpha numeric characters are not allowed. All three characters must be transmitted.

3.3.4 - Termination Character - Always Carriage Return (ASCII - 13)

3.3.5 - Optional characters may be appended to the frame. These will be ignored by the protocol but may be helpful in a specific application. (For example appending a line feed character.)

Top of page

4. Translation Table

4.1 The message characters are limited to printable ASCII characters as listed in the translation table (See PDF file). Each message character can be assigned to either the Master or the Slave unit (but not both).

4.2 A message character may represent a Query, an Answer, or a Command.

4.3 ASCII Characters not in the translation table are not allowed to be used as message characters.

4.4 This protocol uses only printable ASCII characters as message characters.

Top of page

5. Parsing Frames

5.1 The input buffer should be read and characters flushed until a Start Character "!" (ASCII - 33) is read.

5.2 If the next character is a not a "." (ASCII - 46) then the next two characters must be identical. If they match a valid message the receiver should execute the command. If the characters are not identical or the message is not valid these characters should be flushed and the parser should start looking for the next start character.

5.3 If the next character is a "." (ASCII - 46) and the system is expecting an expanded response and the next three characters match a valid response the receiver should execute the command. If the message is not valid these characters should be flushed and the parser should start looking for the next start character.

Top of page

6. Unsolicited Response from the Slave Unit

6.1 A Message command may be sent from the master unit to the slave to allow the slave to send any unsolicited message. The slave will be able to send an unsolicited message at any time until the master sends any other message. The ability to send an unsolicited message will then be canceled until the master resends the message command to allow unsolicited messages.

6.2 When allowed to send unsolicited messages the slave will send the message immediately. This will typically be used to report alarms to the Master unit.

Top of page

7. Registration

7.1 The Able-Baker WOW!™ Protocol is an open protocol available for any suitable use. (We accept no liability for any use of this protocol.) Voluntary registration is requested to allow us to advise users of specification updates.

For more information or to register call or write: