# Firmware design for OBD2 - available PIDs request to ECU

According to many documentations, we can request a vehicle ECU to respond with the PIDs it supports. Link.My question is in the end.

I have designed an OBD2 scanner using STM32 and CAN. And it works flawlessly when I use the broadcast request ID (0x7DF) and request for individual PIDs (like RPM, Speed etc). But in this case, if multiple ECUs support a particular PID then my scanner will receive multiple responses for a single request. And so I decided to choose an ECU (not the broadcast ID). For this approach, we need to know the supported PIDs in an ECU and so I use 0x00 in Mode 1 (refer link).

Testing with emulator
This request when tested with an OBD2 emulator I was receiving an expected OBD2 frame. In which the data[0] is the msg-type [idicating if it's a CAN single frame, can consecutive frame or of any other type] data[1] is the byte that differentiates between PID response or DTC response. Data[2] is the requested PID value. And finally, the rest is the actual data bytes. Eg: A PID request 0x0c (RPM) has 2 bytes returned and so will have data2 and data4.
And in my case I requested for PID 0x00 Mode 1 and got Data[3:6]. Because this was an emulator every PID was supported by the ECU.
Bench testing my logic with the emulator worked.Received data:
Testing in a car
When I tested this same code in a car the response I got was not in accordance with what I received while testing. I tested for two cases:
1. Requesting a single ECU (0x7E0) for its supported PIDs
2. Using a broadcast request (0x7DF)

In case 1

I can't understand what each of the bytes represents.

In case 2

Here the data received seems correct, except the fact that data[0] and data[1] is repeated. But the rest is correct, I checked the supported PIDs using a scanner I bought.

My questions
1. Am I only supposed to request for available PID using a broadcast request ID?
2. Why was the response from ECU 1 not in standard to other ODB2 frames?
3. If you have any experience or know of any project in which an OBD scanner was designed, could you share the link?

EDIT/PROGRESS
The above test was done for Maruti Suzuki Swift. Just a while back I tested the same code in a Hyundai Accent and I received the same response as seen in "case 2", i.e. I tried using broadcast and tried communication to the ECU directly, which resulted in a similar frame as seen in case 2 picture.
But still, I'm receiving two bytes with data 16 instead of a single byte with data 6. Any idea why there might be an extra byte?

I'm not sure if I'm asking the right questions.

• try another IDs, such as 0x7E2 see examples there: github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/… – Raerg Hoitc Aug 29 '17 at 10:46
• Wth is "PID" in your context? In programming, it can mean two things: "Process Id" or "Proportional Integral Derivate" [controller]. These 2 are well-established industry standard terms, the former mostly in OS programming, the later mostly in embedded control systems. Whoever invented a third meaning of the acronym is severely incompetent and cannot have worked with any form of programming. Lesson learned: don't use TLAs in the first place, and don't invent new ones. – Lundin Nov 9 '18 at 11:39
• I cannot answer your questions, but Case 1 shows an error response: 0x03 0x7F 0x01 0x11 (length, error ind, pid, error#) meaning Service not Supported Using a request with ID 0x7E0 might conflict with an existing ECU. As I understand it you cannot address a specific unit by its ID. Issue a request (using a unique ID) and the right unit will answer or no one will. – Rob Sep 11 at 19:31

@Lundin Sorry for the comment disguised as a answer, but I do not have the rep for a comment. I'm sorry but the OP's usage of PID goes back to at least 1996 with the standardization of the On-board diagnositics port(OBD-II). PID in this case stands for Parameter ID and as such is used by all US vehicle manufacturers(since 1996) and most others in the world(at least 2001). Seeing as OBD-II is both a SAE(The Society of Automotive Engineers) and a ISO standard, I'm going to make the assumption that someone between the two knew how to program and was alright with the usage. As an aside, any time your outside area of expertise, you may not want to jump someone for what may be common usage in another area. It's obvious (as you did not understand the OP's usage of PID) that you have not spent any time in automotive diagnostics or you would have known what a PID was in the context of the OBD-II, which the OP made quite clear. Plus this is the Electrical Engineering SE not a programming one, why make the assumption?

EDIT: @Lundin It looks like you do know what OBD-II is(or at least the canbus), so why the comment about the usage of PID??