ELM633
Monitoring the LIN Bus
Data bytes that appear on the LIN bus can
assume values from 0 to 255. These cannot be
displayed using a PC terminal program, however,
since many of these values are not printable
characters. In order to make them readable, the
output could appear as:
>AT MA
49:
[T]
ELM633 re-formats every byte as
hexadecimal digits, using standard ASCII characters.
A typical request made of the ELM633 would appear
as:
a
pair of
As you experiment, you will likely find that
timeouts are a very common occurence. They simply
mean that there has been no activity for some time,
often due to the system going into a low-power sleep
mode. Error messages are described further in the
next section.
>AT MA
49: 6C 8F 04
This data is typical of what might be experienced
in many systems. The current version of the LIN
standard (2.0) allows for the possibility of an arbitrary
number of data bytes however, so while the ELM633
has no limitations on what it can display, the user
should be prepared for this possibility. This could
involve simply allocating enough buffer space,
processing the data faster than it arrives, or by simply
ignoring lines that are longer than a predetermined
length.
The ELM633 also supports one other type of
monitoring command, which is useful when you know
the specific responses that you wish to view. It is the
AT MR command, which requests that only specific
responses to ID bytes be displayed, while ignoring all
others. For instance, a ‘monitor all’ command might
have resulted in:
The AT MA is the user’s request to ‘monitor all’,
while the 49: 6C 8F 04 is what the ELM633 found on
the LIN bus. Note that the initial Synch Byte is always
received, but is never displayed (it is always 55).
The identifier byte (49 in this example) always
appears first, and is separated from the data bytes by
a colon character (“:”), while the pairs of hexadecimal
digits following represent the data bytes that were
received. The final pair of digits on each line is the
checksum byte (04 in this case).
Should the checksum byte not match the value
calculated internally by the ELM633, the error will be
flagged by printing a single question mark at the end of
the line. For an example, if the slave driver in the
above case was weak, allowing an extra ‘1’ to appear
in the first data byte of this example, the output might
typically look like:
>AT MA
>AT MA
D3: C0 00 3F
49: 6C 8F 04
92: D4 00 2B
D3: C0 00 3F
49: 6C 8F 04
49: 7C 8F 04?
The question mark at the end of the second
response line alerts you to the fact that an error is
present, but the position of the error cannot be
determined from this information – you will only be
able to say that it is somewhere in the response.
Another type of error that could occur is when a slave
fails to respond to the master. In this case, you would
typically see only the identifier, followed by a single
question mark:
.
.
.
Only a portion of the data stream is shown, as it
can typically be quite lengthy. However, if the user was
only interested in responses that began with 92 for
instance, they need only issue an AT MR 92 command
to filter the information for them. The above would
have looked like:
>AT MA
49:?
>AT MR 92
92: D4 00 2B
The question mark gets printed in this case
because 49 is not a valid checksum byte (all bytes
must add up to FF).
This command is often helpful when trying to
diagnose a particular problem.
Often, this would be followed by a timeout so the
ELM633DSB
Elm Electronics – Circuits for the Hobbyist
< http://www.elmelectronics.com/ >
7 of 11
ELM [ ELM ELECTRONICS ]
