Datenblatt-Suchmaschine für elektronische Bauteile
  German  ▼
ALLDATASHEETDE.COM

X  

ELM327P Datenblatt(PDF) 32 Page - ELM Electronics

Teilenummer ELM327P
Bauteilbeschribung  OBD to RS232 Interpreter
PDF  51 Pages
Scroll/Zoom Zoom In 100%  Zoom Out
Hersteller  ELM [ELM Electronics]
Direct Link  http://www.elmelectronics.com
Logo ELM - ELM Electronics

ELM327P Datenblatt(HTML) 32 Page - ELM Electronics

Back Button ELM327P Datasheet HTML 28Page - ELM Electronics ELM327P Datasheet HTML 29Page - ELM Electronics ELM327P Datasheet HTML 30Page - ELM Electronics ELM327P Datasheet HTML 31Page - ELM Electronics ELM327P Datasheet HTML 32Page - ELM Electronics ELM327P Datasheet HTML 33Page - ELM Electronics ELM327P Datasheet HTML 34Page - ELM Electronics ELM327P Datasheet HTML 35Page - ELM Electronics ELM327P Datasheet HTML 36Page - ELM Electronics Next Button
Zoom Inzoom in Zoom Outzoom out
 32 / 51 page
background image
32 of 51
ELM327
ELM327DSC
Elm Electronics – Circuits for the Hobbyist
www.elmelectronics.com
Multiline Responses
There are occasions when a vehicle must respond
with more information than one ‘message’ is able to
show. In these cases, it responds with several lines
which must be assembled into one complete message.
One example of this is a request for the serial
number of the vehicle (mode 09, PID 02). This is often
a multiline reply that needs to be joined. In these
situations, you must take care to ensure that all of the
reply has been received and it is in the correct order
before assembling the message. The actual response
usually has a byte that shows the sequence of the
data, to help with this. Here is one example for a
typical SAE J1850 vehicle:
>0902
49 02 01 00 00 00 31
49 02 02 44 34 47 50
49 02 03 30 30 52 35
49 02 04 35 42 31 32
49 02 05 33 34 35 36
Note that all OBD compliant vehicles do not
necessarily provide this information. Many older ones
do not, but as a rule the newer ones do. If your vehicle
does not support this parameter, you will only see a
“NO DATA” response.
The first two bytes (49 and 02) on each line of the
above response do not show any vehicle information.
They only show that this is a response to an 09 02
request. The next byte on each line shows the order in
which the data is to be assembled. Assembling the
remainder of the data in that order, and ignoring the
first few 00’s gives:
31 44 34 47 50 30 30 52 35 35 42 31 32
33 34 35 36
Using an ASCII table to convert these hex digits
gives the following serial number for the vehicle:
1 D 4 G P 0 0 R 5 5 B 1 2 3 4 5 6
CAN systems will display this information in a
somewhat different fashion. Here is a typical response
from a CAN vehicle:
>0902
014
0: 49 02 01 31 44 34
1: 47 50 30 30 52 35 35
2: 42 31 32 33 34 35 36
CAN Formatting has been left on (the default),
making the reading of the data easier. With formatting
on, the sequence numbers are shown with a colon (‘:’)
after each, so that they clearly stand out (0:, 1:, etc.).
CAN systems add this hex digit (it goes from 0 to F
then repeats), to aid in reassembling the data, just as
the J1850 vehicle did.
The first line of this response says that there are
014 bytes of information to follow. That is 14 in
hexadecimal, or 20 in decimal terms, which agrees
with the 6 + 7 + 7 bytes shown on the three lines.
Serial numbers are generally 17 digits long however,
so how do we assemble the number from 20 digits?
The second line shown begins with the familiar 49
02, as this is a response to an 09 02 request. Clearly
they are not part of the serial number. CAN will
occasionally add a third byte to the response which we
see next (the ‘01’), which shows the number of data
items that are to follow (the vehicle can only have one
VIN, so the response says there is only one data item).
That third byte can be ignored, so this leaves 17 data
bytes which are the serial number (purposely chosen
to be identical to the those of the previous example).
All that is needed is a conversion to ASCII, in order to
read them, exactly as before.
The following shows an example of a different type
of multiline response that can occur when two or more
ECUs respond to one request. Here is a typical
response to an 01 00 request:
>01 00
41 00 BE 3E B8 11
41 00 80 10 80 00
This is difficult to decipher without knowing a little
more information. We need to turn the headers on to
actually see ‘who’ is doing the talking:
>AT H1
OK
>01 00
48 6B 10 41 00 BE 3E B8 11 FA
48 6B 18 41 00 80 10 80 00 C0
Now, if you analyze the header, you can see that
the third byte shows ECU 10 (the engine controller)
and ECU 18 (the transmission) are both responding
with a reply that is valid for them. This type of
response occurs often, and you should be prepared for
it.
A final example shows how similar messages
might occasionally be ‘mixed up’ in a CAN system. We



Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51


Datenblatt Download

Go To PDF Page


Link URL



War ALLDATASHEET hilfreich?  [ DONATE ] 

Über Alldatasheet   |   Werbung   |   Kontakt   |   Privatsphäre und Datenschutz   |   Link zum Datenblatt    |   Linktausch   |   Hersteller
All Rights Reserved©Alldatasheet.com


Mirror Sites
English : Alldatasheet.com  |   English : Alldatasheet.net  |   Chinese : Alldatasheetcn.com  |   German : Alldatasheetde.com  |   Japanese : Alldatasheet.jp
Russian : Alldatasheetru.com  |   Korean : Alldatasheet.co.kr  |   Spanish : Alldatasheet.es  |   French : Alldatasheet.fr  |   Italian : Alldatasheetit.com
Portuguese : Alldatasheetpt.com  |   Polish : Alldatasheet.pl  |   Vietnamese : Alldatasheet.vn
Indian : Alldatasheet.in  |   Mexican : Alldatasheet.com.mx  |   British : Alldatasheet.co.uk  |   New Zealand : Alldatasheet.co.nz
Family Site : ic2ic.com  |   icmetro.com