CR1000 Manual - Campbell Scientific

Section 7. Installation
7.8.8.1 Introduction
Serial denotes transmission of bits (1s and 0s) sequentially, or "serially." A byte
is a packet of sequential bits. RS-232 and TTL standards use bytes containing
eight bits each. Imagine that an instrument transmits the byte "11001010" to the
CR1000. The instrument does this by translating "11001010" into a series of
higher and lower voltages, which it transmits to the CR1000. The CR1000
receives and reconstructs these voltage levels as "11001010." Because an RS-232
or TTL standard is adhered to by both the instrument and the CR1000, the byte
successfully passes between them.
If the byte is displayed on a terminal as it was received, it will appear as an ASCII
/ ANSI character or control code. Table ASCII / ANSI Equivalents (p. 201) shows a
sample of ASCII / ANSI character and code equivalents.
Table 30. ASCII / ANSI Equivalents
Byte
Received
ASCII
Character
Displayed
Decimal
ASCII
Code
Hex
ASCII
Code
00110010 2 50 32
1100010 b 98 62
00101011 + 43 2b
00001101 cr 13 d
00000001 ☺ 1 1
Read More! See the appendix ASCII / ANSI Table (p. 553) for a complete list of
ASCII / ANSI codes and their binary and hex equivalents.
The face value of the byte, however, is not what is usually of interest. The
manufacturer of the instrument must specify what information in the byte is of
interest. For instance, two bytes may be received, one for character 2, the other for
character b. The pair of characters together, "2b", is the hexadecimal code for "+",
"+" being the information of interest. Or, perhaps, the leading bit, the MSB (Most
Significant Bit), on each of two bytes is dropped, the remaining bits combined,
and the resulting "super byte" translated from the remaining bits into a decimal
value. The variety of protocols is limited only by the number of instruments on
the market. For one in-depth example of how bits may be translated into usable
information, see the appendix FP2 Data Format (p. 557).
Note ASCII / ANSI control character ff-form feed (binary 00001100) causes a
terminal screen to clear. This can be frustrating for a developer who prefers to see
information on a screen, rather than a blank screen. Some third party terminal
emulator programs, such as Procomm, are useful tools in serial I/O development
since they handle this and other idiosyncrasies of serial communication.
When a standardized serial protocol is supported by the CR1000, such as
PakBus® or Modbus, translation of bytes is relatively easy and transparent.
However, when bytes require specialized translation, specialized code is required
in the user-entered CRBasic program, and development time can extend into
several hours or days.
201