ODiSI 6
ODiSI 6
User’s Guide
Page 91
The JSON portion of the Tare Message is followed by a 16 bit CRC-16-ANSI checksum,
encoded as a 4-character hexadecimal number. The checksum is calculated over the entire
length of the JSON text, including the starting and final braces.
The checksum is followed by a single NULL character to mark the end of the Tare Message
transmission.
Example
{
"message type": "tare",
"message version": 1,
"product": "ODiSI 6",
"system serial number": "2017ODB10032",
"channel": 1,
"number of gages": 4,
"data": [ 103, -57.5, null, 91 ]
}B3F4
Receiving Messages Across TCP Packets
The described JSON messages may be split across multiple TCP packets, depending on the
size of the message and the number of sensors and gages that have been defined.
Each message will begin in a new TCP/IP packet. The checksum and terminating NULL
character will occur at the end of a packet.
A program receiving ODiSI Measurement Streaming Protocol messages can use either or
both of the following methods to determine when a complete Metadata or Measurement
Message has been received.
•
Concatenate multiple TCP packets until a NULL character is received. The four
characters preceding the NULL should be interpreted as a checksum. Everything
preceding the checksum should be interpreted as a JSON-encoded Metadata or
Measurement Message.
•
Count pairs of curly braces (that is, the { character and the } character) as data is
received. Each JSON message will begin with an opening { curly brace. Other pairs of
{} curly braces will be present within the message. When a closing } curly brace
matching the opening { curly brace is encountered, the receiver can conclude that the
end of the message has been reached. The receiver should expect to see seven more
characters
– two characters for the carriage return plus line feed, four characters for
the hexadecimal checksum, and a terminating NULL character.
If at any time the receiving program encounters a new packet that begins with:
{"message type"
the program should assume that this is the beginning of a new message. If the program was
in the process of storing TCP packets in order to assemble a message whose end has not
been received, the program should discard the previous partially-received message and begin
processing a new message starting with the new packet.
