SparkFun Forums

[camando64]

Wow,
Thanks for your support.
I'm hitting this harder this week so will let you know how I go.

Cam

[gimpo]

My suggestion is to buy a little TFT display from adafruit. As I know is the only way to check what your program is doing by printing some output on the TFT screen.
Adafruit has developed a (free) library for printing text easily by instruction like "print" and "println".
It has helped a lot in debugging my program. In that way, I was able to print the contents of the text buffer (i.e. RESPONSE.data) drectly on the display and check with my eyes what Arduino was receiving. This allowed me to refine my code.

As I remember, even the little 1.44" display allows 21 or 20 chars per row and it has 16 rows. Wiring it to Arduino is simple, just follow instructions on their website. The display will use other pins other than the Serial TX/RX pin. So they can be used for communicating with the OBD board only.

[splaq]

@Gimpo,

Not sure if you're watching this or not, but your solutions exactly describe my issues. My car is KWP2000 and I'm getting all kinds of funky results, as a matter of fact one thing you explained perfectly matched an issue I was having, I was getting the bus-init response when I sent the 0100 (display available pids) command.. I was starting to think I have a bad module.

Anyways, I grabbed your code and I'm going to give it a shot. I have one question though, in your getRPM() function, you send the Serial.println("2130") command to check the RPM as according to the ECU. But then specify an expected response of 6160, Can I leave that blank? Because I'm not looking for a specific RPM, I'm wanting to display the range.

Also a few lines down from there, you have

Code: Select all

int position = bufferEndPositionOf("6130");

Is the 6130 the length of the message you're expecting? I'm not understanding those two things. I'd very much appreciate it if you could explain both of those and how I might work with them.

[splaq]

@gimpo

I wrote this last night but it doesn't seem to have posted it.. I don't know why.. Anyways...

Your solution seems to be the exact answer to my issue, even to the point that when you said this ...

Contents of the response are not fixed, the text can contain different kind of inormation (look here below the comment from my code). What is more important is that the resulting response-string can be chaotic; it can contain blank added blank spaces, special chars and sometimes the answer arrive with a big delay in time. When this happens, many ECUs have the strange habit to queue answer in a buffer, so when you issue a second request than the answer could contains also a part that is the answer to the first one (!)

I realized exactly what was going on, because I was sending ATSP 5 and didn't get anything, then when I sent 0100 I got "BUS-INIT:" Then the response I was detecting. I have a serial to usb converter on the way so I can do more diag's with my computer, but your code seems to be the solution.

My question on your code is this..
In the getRpm() function you called

Code: Select all

 getResponseAndCheck("6160");  // remember: this are hexadecimal numbers!

what is the 6160? I just want to see what my RPM is at all times, I'm not looking for a specific RPM. Also you have

Code: Select all

int position = bufferEndPositionOf("6130"); 

What is the 6130? Can that be left out or is that the length of the response you're expecting?

I'm not quite understanding those two things, I would be very appreciative if you could shed some light on that and help me out, it seems the ISO 14230-4 protocol is some what of an art form to deal with.

[gimpo]

Hi,

long time has passed. I don't remember exactly...
Anyway, as I remember, if you ask the ECU for something it responds by adding the exadecimal constant 0x40 to the reply (when the reply is successful). The constant is added by the "ECU service" responding to you.

For example:

1. you ask for RPM ("2130")

2. the ECU can respond:

a. 2130*6130NNNN**> (success! NNNN = the answer)
b. 2130*BUSINIT:ERROR**> (fail)
c. 2130*NODATA**> (fail)

So you have to scan the answer to see if it contains the "success code", in this case 6130 = 0x2130 + 0x40.

Yes, understanding ECU replies is a sort of hacking activity, it's a form of art. I strongly recommend you to find some PDF manual describing the KWP-2000 protocol.
If you want an headache, check the document I have attached.