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
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 is the
msg-type [idicating if it's a CAN single frame, can consecutive frame or of any other type]
data is the byte that differentiates between PID response or DTC response.
Data 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
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?
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.