Toyota(Scion) ECU

Apr 18, 2012 at 7:31 AM

So I recently received my ELM327 OBDII reader. I opted to use a Bluetooth model which installs an emulated COM port. The connection is made and the app checks for supported PID's (33 total). After this point, parsing the data becomes an issue. ECU details are: ECU PID 2024, Protocol 6 (incorrectly detected).

In GetPidData() while reading sensor pid 13 [0x0D] which is called by GetKilometersPerHour(), the ecu response is '7E8 03 41 0D 00'. When parsed, the app throws an out of bounds exception. In reading the response, I believe 7E8 = 2024, which is the ECU ID. I don't know what 03 references, but it may be protocol id (detected incorrectly as 6). 41 shows a valid response from mode 1, 0D is the sensor pid 13, and the actual data is 00, which makes sense, as the vehicle is parked. Setting the protocol to 3 manually, fails with a divide by zero due to the offset. I just need to determine the correct offset and ecuByte values, and which protocol they should be numbered as.

Would someone here be able to point me in the right direction to decode the ECU response correctly? I'm pretty sure I am visually reading the response correctly, just parsing it wrong. Thanks in advance. I'm really looking forward to getting this working, and contributing to this project. Thanks for all the hard work to get this project off the ground!

Coordinator
Apr 18, 2012 at 5:30 PM
Edited Apr 18, 2012 at 5:32 PM

Hm...Protocol 6 looks correct according to the offsets I have in the code...

offset = 4 -> that's the byte the data starts at
ecuByte = 0 -> that's the byte the ECU address is at

In your data, you have:

7E8 03 41 0D 00

ECU is at "byte" 0 (7E8), and the data is at "byte" 4 (00 -- it's zero-indexed)

Can you give me the line on which you're seeing the out of bounds exception?  Also, can you copy/paste the debug output of the library in the Output Window to your message?

It could be as simple as a slight difference in line breaks with the way your cable returns data vs. the one we had.

Apr 19, 2012 at 12:28 AM

Thanks Brian. After some more reading, I do believe the protocol (6) is correct. The first value is the ECU's CAN id (7E8), the second value indicates how many data bits follow (03), and the rest appears to be in the correct format. I am somewhat confused as to why this isn't just working. The out of bounds exception occurs in ObdDevice.cs at line 378. Below is the debug output:

-----------------------------------------------------------------------

ATZ,

ELM327 v1.5

ATE0, ATE0
OK

ATL0, OK

ATSP1, OK

01 00, NO DATA

A first chance exception of type 'Coding4Fun.Obd.ObdManager.ObdException' occurred in Coding4Fun.Obd.ObdManager.dll
It's not protocol 1
ATSP2, OK

01 00, NO DATA

A first chance exception of type 'Coding4Fun.Obd.ObdManager.ObdException' occurred in Coding4Fun.Obd.ObdManager.dll
It's not protocol 2
ATSP3, OK

01 00, BUS INIT: ...ERROR

A first chance exception of type 'Coding4Fun.Obd.ObdManager.ObdException' occurred in Coding4Fun.Obd.ObdManager.dll
It's not protocol 3
ATSP4, OK

01 00, BUS INIT: ...ERROR

A first chance exception of type 'Coding4Fun.Obd.ObdManager.ObdException' occurred in Coding4Fun.Obd.ObdManager.dll
It's not protocol 4
ATSP5, OK

01 00, BUS INIT: ERROR

A first chance exception of type 'Coding4Fun.Obd.ObdManager.ObdException' occurred in Coding4Fun.Obd.ObdManager.dll
It's not protocol 5
ATSP6, OK

01 00, 41 00 BE 1F A8 13

ATH1, OK

PID: 00, 7E8 06 41 00 BE 1F A8 13

PID: 20, 7E8 06 41 20 90 05 B0 15

PID: 40, 7E8 06 41 40 FA DC 20 00

Using ECU 2024 with 33 PIDs
PID: 0D, 7E8 03 41 0D 00

A first chance exception of type 'System.IndexOutOfRangeException' occurred in Coding4Fun.Obd.ObdManager.dll

-----------------------------------------------------------------------

Do you have any suggestions? I can also provide you the iTrace file via email if you think it would be helpful. Thanks!

Coordinator
Apr 19, 2012 at 12:39 AM

IntelliTrace may be handy.  You can get me at brpeek (a symbol representing at) microsoft.com.   :)

Apr 19, 2012 at 12:49 AM

Email sent. Thanks again. :)

Jun 7, 2012 at 4:28 AM

I know this is a late reply, but I just tested the app tonight for the first time, and ran into the same problem.
After looking at the code - and noticing the comments in the method for GetPidData, I saw that the bytes array is attempting to strip off a header and trailing checksum.  But, with the device I'm using - I'm fairly certain that there is no trailing checksum - which looks like it's the case above.

Even though "00" is the byte you want to use, it's not being used because the bytes[] declaration is subtracting 1 (and so is the for loop).

Simply remove the "- 1" from the bytes[] declaration, and from the for loop, and then your "00" byte will get used.

I found that this fixed my problem with GetFuelLevelInput() and with GetRpm().

Although - it's too late at night to go back out to the car and test if everything is working fine... but, this appears to have fixed my problems.

Coordinator
Jun 7, 2012 at 4:32 AM

You are correct.  It seems some devices don't send the header/checksum in the way the cable we used does.  I haven't yet gotten around to a fix, but your fix above is correct!