# Understanding the difference between CAN IDs and PIDS on OBD-II

I am trying to understand the CAN protocol for reading the diagnostic information from a car. For example, I know that on the car I am working on uses CAN identifier 0x7E0 as a query and 0x7E8 is the response sent back.

I am using a Vector GL1000 logger, and I am writing the code for this. The GL1000 uses a C-like language, and for me to retrieve information it uses the following format:

VAR Variable1 = CAN1 DATA (can-id) [bitA bitB]


And for example if I wanted to retrieve the engine coolant temperature, the PID is: 05. I understand my variable will look like so:

VAR Variable1 = CAN1 Data 0x7E0 (or is it 0x7E8?) [ bitA bitB]


I am stuck, because I don't know if I should use the query or the response CAN ID, and I don't know what bitA & bitB should be if I want to retrieve the engine coolant temperature.

I know this is far fetched, but Vectors IT cannot help me. Is there a way I can clarify such a far fetched question?

• You should transmit with Query ID and wait for Response ID – Swanand Jun 20 '15 at 16:07

You send CAN Msg from your Vector device right?Then your CAN requet must be like this

ID -7E0 DLC - 8 D0-02 D1-01 D2-0C D3-D7 -0

• I'd love to know how you got to the payload you did. Can you edit your answer and elaborate? – akohlsmith Aug 25 '16 at 2:21

UDS is a closed standard, but essential parts of it are available online. What you most probably want is UDS service \$22: Read Data By Identifier. UDS support different CAN frame structure, the simplest and most used being "single frame":

So, you will essentially need to send

0x7E0: 03 22 05 00 00 00 00 00
|     |  |  \-/------------- DID (two bytes)
|     |  \------------------ SID
|     \--------------------- data lenght
\--------------------------- CAN ID


and wait for a reply with CAN ID 0x7E8. However, reality is usually harder than that: many ECUs will require you to send a Diagnostic Session Control request first, or even reply to Security Access challenge. Others will require a checksum to be present in the last data byte. You may have to experiment quite a bit to get this working on the ECU you have at hand.

There is no really easy anwer to that. Either you are doing ISO standard OBD (like the one done by the various ELM devices around) or you are trying to access some specific ECU on the car network.

Each manufacturer does whatever it likes for non-mandated OBD features, so good luck with that.

In the case you are actually trying to do standard ISO OBD, given that 7E0 and 7E8 are actually the standard addressed, the best way is to read the ISO specifications (they are expensive but you can find most of the stuff online). You should start with ISO 15765 and follow the leads. There are many tutorials around with many info.

As for the syntax sorry but I can't help, the 'bitA bitB' thing seems to be vector specific.

On-board diagnostics, OBD2 is a 'higher layer protocol' (think of it as a language) while CAN bus is a method for communication (like a telephone).

In particular, the OBD2 standard specifies the OBD2 connector, incl. a set of five protocols that it can run on. Further, since 2008, CAN bus (ISO 15765) has been the mandatory protocol for OBD2 in all cars sold in the US, which basically eliminates the other 4 protocols over time.

To read diagnostic data, special PID's commands are used.

PID’s (On-board diagnostics Parameter IDs) - codes that are used to query the values of indicators of certain vehicle sensors.

Basic pids can be found on Wikipedia, which contains a complete set of basic commands that all cars should support. There are also sets of commands for certain brands and types of cars, these sets are available for a fee.