»  BC-BF Legacy Discussion »  Electrical
#Firmware design for OBD2 - available PIDs request to ECU

Custom Search
Login | Register

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Firmware design for OBD2 - available PIDs request to ECU
PostPosted: Fri Dec 15, 2017 4:46 am 
In Neutral
Joined: Fri Dec 15, 2017 4:17 am
Posts: 1
Hi to all, I'm not sure if I'm asking the right questions. Whatever, it makes me dysphoria because I don't know error where take place. The situation is following: 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 http://www.kynix.com/Detail/914252/CAN.html. 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
The response I received:
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?

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?

Thank you taking time to read and your advice.

Profile  Offline
Reply with quote  
 Post subject: Re: Firmware design for OBD2 - available PIDs request to ECU
PostPosted: Fri Dec 15, 2017 3:57 pm 
Joined: Tue Aug 25, 2009 7:52 am
Posts: 4693
Location: Des Moines, Wa
How does this work with our 90-94 OBD-1 Legacys?

1992 Legacy SS 5mt, build in progress

Profile  Offline
Reply with quote  

Display posts from previous:  Sort by  

Post new topic Reply to topic  [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


Top You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
Search for:
Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Dizayn Ercan Koc