Shering Weighing Limited
a member of the
Shering Weighing Group Limited
Sabre Interface Protocol
Sabre Interface Protocol
Technical Guide
Release: A
Date: 14 February 2001
Approved Equipment
European Approval No. Certificate No. FM14022
UK 2250 BS EN ISO 9001
No. 1097
Sabre Interface Protcol Release A
1.1 Overview
The method that Sabre Digital Weight Indicators, and other Sabre devices, use to
communicate with the external world is known as the Sabre Interface Protocol. It is
a simple packet protocol intended for use over serial links. It includes a checksum
for error detection.
A protocol conversation is generally a two-stage packet exchange. In the first stage, a
device will send a request to a DWI. If the DWI receives the packet and the frame and
the checksum are correct then the DWI will respond with an acknowledgement before
executing the required function. In the second stage the request originator will wait
for a reply from the DWI. If the reply is received correctly then an acknowledgement
will be sent to the DWI.
Please note that this document only covers the Sabre Interface Protocol itself. For
a full list of the available commands the reader should refer to the Software
Interfaces section of the SABRE 82x Digital Weight Indicator User’s Manual
supplied with their weighbridge.
Page 2
Sabre Interface Protcol Release A
1.2 Packet Structure
The packet structure that the Sabre Interface Protocol uses is made up of a number of
different fields, shown below in Figure 1:
Pkt ID
SOH
EOT
STX
ETX
MESSAGE CRC
Figure 1. Sabre Interface Protocol packet format
1.2.1 Packet Fields
SOH. 1 byte. This is the Start Of Header character.
Pkt ID. 1 byte. This is a digit between ‘0’ and ‘9’. It is used to detect repeated
packets. Any repeated packets are ignored. Starting at 0 (zero), each time a packet
is successfully sent or received the packet ID is incremented by 1. After 9, the ID
returns to 1 (one) and the cycle continues, 1-9, 1-9, etc, etc.
STX. 1 byte. This is the Start of TeXt character and is used to identify the start of
the message data.
MESSAGE. Variable length. This is the Sabre Command, along with any data
required to execute the command. This is an ASCII string. Refer to the Sabre 828
Digital Weight Indicator User’s Manual (Document No. A001/06/051) for more
information on the Sabre command structure and contents.
ETX. 1 byte. This is the End of TeXt character and is used to identify the end of
the message data.
CRC. 4 bytes. This is a Cyclic Redundancy Check used to ensure that the message
text is transmitted without error. Only the MESSAGE field is used in the CRC
calculation. See section 1.2.2.
EOT. 1 byte. This is the End Of Transmission character and signifies the end of
the packet.
Page 3
Sabre Interface Protcol Release A
1.2.2 Message CRC
The Sabre Interface Protocol employs the CCITT CRC-16 algorithm to calculate a
checksum for the message content of the packet. The CRC calculation is shown in the
listing below, using the ‘C’ programming language:
static const unsigned int _ccitt_lut[] =
{
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0
};
unsigned int crc_ccitt(char *s)
{
unsigned int crc = 0;
while (*s)
crc = (crc<<8) ^ _ccitt_lut[(crc>>8)^(*s++)];
return crc;
}
Listing 1. CCITT CRC-16 calculation using the 'C' programming language
Page 4
Sabre Interface Protcol Release A
1.3 The Send Stage
The send stage is illustrated in Figure 2.
Package data in
Sabre Protocol
format
Send Packet No
Get DWI
Response (time
out after one
second)
ACK?
No
NAK? Yes
No
Pause for one Return cause of
0x14? Yes Third Fail? Yes
second error
No
Timeout? Yes
No
Unexpected
response. Fail.
Finish
(Start receiving if
required)
Figure 2. The Send Stage of the Sabre Interface Protocol
A packet is sent by, say, device A. It then waits for a response from, say, device B.
Device A will only wait for a response from device B for one second before timing
out.
If device B responds with an acknowledgement (ACK) character, then the send has
succeeded. Device A will then continue normally.
If a negative acknowledgement (NAK) is received, indicating a CRC failure for
example, then device A will sent the packet again. Device A will only repeat the send
Page 5
Sabre Interface Protcol Release A
two more times (three including the original send) before stopping and indicating the
problem to the application software.
An ASCII 0x14 (Device Control 4, or DC4) character returned by device B indicates
that device B cannot accept the packet because a previous packet is still being
executed. Like the NAK situation, device A will attempt to re-send the packet up to a
maximum of three times, however, device A will wait for one second between retries
to allow time for the receiving device to carry out the previous command.
If device A receives no response from device B after one second, then device A will
again attempt to re-send the packet, again up to a maximum of three times.
Page 6
Sabre Interface Protcol Release A
1.4 The Receive Stage
The receive stage is illustrated in Figure 3.
Buffer characters
until EOT received
(timeout after 1 sec)
Got EOT?
Yes No
No
Check packet
structure
and CRC, etc.
OK? No Send NAK Third FAIL?
Yes
Yes
Send ACK
Return ERROR
Extract message
from packet
Return message
Figure 3. Receive stage of the Sabre Interface Protocol
When device A goes into receive mode it will wait for a packet, terminating when the
End Of Transmission (EOT) character is received, or timeout if there are no
characters after one second.
Once the EOT character is received, device A will attempt to decode the received
packet. It will check that the packet frame is correct, i.e. the SOH, STX, ETX and
EOT character are at the correct positions in the packet. It will then extract the CRC
of the message content of the packet sent by device B and calculate its own CRC for
the message part of the received packet. It will then compare the two. If either test
fails, device A will send a NAK character.
Page 7
Sabre Interface Protcol Release A
1.5 Example Conversation
Figure 4, below, illustrates examples of Sabre conversations.
PC sends <SOH>0<STX>03000000<ETX>crc<EOT>
Example of a DWI replies w ith <ACK>
successful
transaction DWI sends <SOH>0<STX>030100000000 05000k0A000001<ETX>crc<EOT>
PC replies w ith <ACK>
PC sends <SOH>0<STX>03000000<ETX>crc<EOT>
DWI replies w ith <ACK>
Example of a
transaction where
DWI sends <SOH>0<STX>030100000000 05000k0A000001<ETX>crc<EOT>
the PC sends the
request
PC replies w ith <NAK>
successfully, but
where the reply DWI sends <SOH>0<STX>030100000000 05000k0A000001<ETX>crc<EOT>
fails to decode
correctly twice, PC replies w ith <NAK>
succeeding on the
third attempt. DWI sends <SOH>0<STX>030100000000 05000k0A000001<ETX>crc<EOT>
PC replies w ith <ACK>
Figure 4. Example Sabre "conversation"
Page 8
Sabre Interface Protcol Release A
1.6 Protocol Timeouts
For the Sabre Interface Protocol, there are two levels of timeout:
Low Level Timeout. These timeouts are used at the basic send and receive level.
When a packet is sent by a device A, an acknowledgement (ACK) is expected
within one second, as are NAK or 0x14. If no response is received within this
time, the sending device attempts to send the packet again.
High Level Timeout. When a device sends a request to a DWI, and the send is
acknowledged correctly, there is a delay before the response is generated. In
general this delay is short, but some of the Sabre commands can take much longer
to complete. The response time for each command described is in the same region
(generally less than one second), and each should be given a (generous) read
timeout of 3 seconds.
These timeouts are specified in seconds. The software implementing these timeouts
should use appropriate functions to measure real seconds – i.e. they should not use
approximations, such as a FOR loop optimised for a particular computer or class of
computer, that may vary over time as hardware evolves.
Page 9
