User Manual
© 2017 Inertial Sense, LLC
13
11/30/2017
The format of the packet data is determined by the packet identifier. For a data packet (PID_DATA (4) or
PID_SET_DATA (5)) the first 12 bytes are always the data identifier (4 byte int), the offset into the data (4 byte int),
and the length of data (4 byte int, not including the 12 bytes or packet header / footer).
Packet footer (4 bytes)
1 byte
–
checksum byte A (most significant byte)
1 byte
–
checksum byte B (middle byte)
1 byte
–
checksum byte C (least significant byte)
1 byte
–
packet stop byte (0xFE)
The packet checksum is a 24-bit integer (little-endian) that can be created as follows:
-
Start the checksum value at 0x00AAAAAA and skip the packet start byte
-
Exclusive OR the checksum with the packet header (identifier, counter, and packet flags)
o
checksum ^= packetId
o
checksum ^= (counter << 8)
o
checksum ^= (packetFlags << 16)
-
Exclusive OR the checksum with each data byte in packet, repeating the following three steps, until all
data is included (i == dataLength).
o
checksum ^= ( dataByte[i++] )
o
checksum ^= ( dataByte[i++] << 8 )
o
checksum ^= ( dataByte[i++] << 16 )
-
Decode encoded bytes (bytes prefixed by 0xFD) before calculating checksum for that byte.
-
Perform any endianness byte swapping AFTER checksum is fully calculated.
-
The checksum is stored in the packet footer in little endian format (see packet footer structure above).
If your CPU architecture does not match the packet flags, you need to swap bytes appropriately. The SDK does this
for you automatically. Bytes 0x0A, 0x24, 0xB5, 0xD3, 0xFD, 0xFE and 0xFF are reserved bytes, with 0xFD being a
reserved byte prefix. When those bytes are written to a packet, they are prefixed with 0xFD and then written with
all the bits inverted. The packet start and end byte are never encoded. When calculating a checksum, decode the
byte if necessary first and then add the byte to the checksum calculation.
A raw packet can never be more than 2048 bytes. A decoded packet will never be more than 1024 bytes.
For a full example of encoding and decoding binary packets, please reference the following files in the SDK source:
com_manager.c, com_manager.h, data_structures.c and data_structures.h, and in particular, the functions
encodeBinaryPacket() and decodeBinaryPacket().
5.2
ASCII Protocol
For simple use, the Inertial Sense device can communicate back and forth using plain ASCII text. This format is
based on NMEA (
http://www.gpsinformation.org/dale/nmea.htm
). ASCII packets follow the NMEA 0183 structure
and have the following format:
1 byte
–
Start packet, always the $ byte (0x24)
n bytes (usually 4 or 5)
–
packet identifier
1 byte
–
a comma (0x2C)
n bytes
–
comma separated list of data, i.e. 1,2,3,4,5,6
1 byte
–
checksum marker, always the * byte (0x2A)
2 bytes
–
checksum in hex format (i.e. f5), 0 padded if necessary
2 bytes
–
End packet, always carriage return and line feed (\r\n or 0x0D, 0x0A)