SparkFun Forums

[sti robot]

I've been working with the OBD II UART device and it works wonderfully with standard PID's (with the exception of coolant temp, but it could just be the example car I'm working with).

I have successfully based some of my code around the code found in this thread: https://forum.sparkfun.com/viewtopic.php?f=14&t=38253

I am specifically interested in using a oil temp PID that is non-standard. The code is for a subaru brz/gt86/scion frs and according to people using the Torque android app the pid is as follows:
OBD2 Mode and PID: 2101
Minimum Value: -40
Maximum Value: 215 (this is just the maximum that this location can support, which does not mean the sensor can read that high)
Scale factor: x1
Unit type: C
Equation: AC-40 (no space between A and C; "AC" is the location within the response)
OBD Header: 7E0 (Auto also works, but seems to take longer)

However I'm not sure how to interpret this. So, I dug further and found this tidbit from people who use the scanguage-x, a commercial canbus capable obd II gauge:
Gauge Unit TXD RXF RXD MTH Note
Oil temp C 07E02101 010702E80324 3008 00010001FFD8 Required FW 4.05 or higher

Which leads me to believe that all I need to send to the UART device is a 07E02101, but this gives a response of "NO DATA".

I also understand that I need to increase the size of the rxData[] buffer that is used in the sample code linked above, but the "NO DATA" is observed directly as coming from the OBD II UART device.

Is this a CANBUS PID and I need to send it as $07E02101 or perhaps use the "SH" command and set the header to 07E then send the query of 02101? If I do that does that just set the header for that query or for all future queries until I change it?

[sti robot]

Serial.println("SH 07E");
Serial.println("02101");

gives me "STOPPED" and sometimes "?"

[skimask]

Which "OBD II UART device"?

[sti robot]

Oh, sorry. Its the wig-09555 made by SparkFun with the stn1110 chip.

[skimask]

You sure about that PID?
I've got $5C for oil temp.
And if you're sending "02101", that leading "0" might be tripping it up.

[sti robot]

Possibly. The issue is I'm trying to figure out what these inputs to another program mean in terms of actual instructions (or PID's) sent.

There is a standard PID for oil temp but it doesn't work with most cars. This car I'm working with in particular uses the nonstandard PID in the link below (but in the Torque App format).

http://www.ft86club.com/forums/showthread.php?t=23530

[skimask]

Right...I overlooked your mention of the non-standard PID. $5C is the standard PID. Disregard...

AT SH 7E0 - sets the header to $7E0
2101 - requests mode $21 PID $01

Should get a response with 7E8 and /X/ bytes of data behind it, which you should then be able to decode something useful out of it.

[sti robot]

Ok. I think I see the error of my ways.

I tried
SH 7E0
2101

I did not include the AT

[skimask]

You also had 07E, with the leading "0", rather than 7E0.

[sti robot]

I finally had time to test it out. It works. Thank you very much.

Now to pull the correct value out.

returns look like this:

Code: Select all

01F 0: 61 01 00 00 00 00 1: 55 66 54 45 5 5A 00 2: 00 00 00 00 0C 29 53 3: 21 21 00 3D 05 AD 09 4: 42 30 04 58 00 00 00 SEARCHI

So, the buffer is a little too large (that "SEARCHI" appears on the same line without a carriage return).

I know this return is correct because it matches the one someone else got in terms of length and format (http://pastebin.com/D1gkE1f5)

I could be wrong, but I think on line "4:" the "42" (position 29 as stated in the is what I'm looking for. So, sitting in my garage on a mild summer day the oil is at (66-40)*1.8= 46.8 degrees F? That seems about 10-20 deg low.

Another question, do I need to switch back to "normal" headers to get a normal obd II reading after this? If so, how do i do this: http://elmelectronics.com/DSheets/ELM327DS.pdf ? Page 24 says that using this command sets headers commonly used with CAN systems. Ok. But does this set the headers so it thinks everything I'm doing after that command is CAN or ?

Will AT SP0 set the header back to auto/search?

EDIT: I found out the answer is no (pg 39 of the above linked manual)

EDIT EDIT: 01F = 31, which means to expect a 31 byte response (at this point i'm more documenting than asking i guess). If you look at my sample response and the sample responses in the pastebin link, you will see that sometimes this means to expect 31 meaningful bytes but that there may be 00 padding on the end.

[skimask]

I finally had time to test it out. It works. Thank you very much.

I got lucky...that's all.

I could be wrong, but I think on line "4:" the "42" (position 29 as stated in the is what I'm looking for. So, sitting in my garage on a mild summer day the oil is at (66-40)*1.8= 46.8 degrees F? That seems about 10-20 deg low.

10-20 degrees low. I see you did the multiply for C to F conversion, but I don't see the 32 degree addition.
Furthermore, that output is probably offset by 40C. So, add 32F, subtract 40C... 40C - ~17C = 23C. That might be the difference.

Another question, do I need to switch back to "normal" headers to get a normal obd II reading after this? If so, how do i do this: http://elmelectronics.com/DSheets/ELM327DS.pdf ? Page 24 says that using this command sets headers commonly used with CAN systems. Ok. But does this set the headers so it thinks everything I'm doing after that command is CAN or ?

If it's on the same vehicle, shouldn't need to switch back to 'normal' headers, because your vehicle is always going to use "that" header. Otherwise, you'll want to know what the header was before you switched it, to switch it back. Or, just do a "FULL RESET" of the OBD chip. (I forget how at the moment, but it's in the datasheet somewhere)

Will AT SP0 set the header back to auto/search?

Don't remember, but there is a command somewhere to kick it back to the original auto-search pattern...

[sti robot]

Thanks for all the patient help.

The way it's written AC-40 is supposed to denote position 29, correct?

Does that mean mean the second entry on line "4:"? (skipping the header value 01F and the "line numbers")

If so that would yield 48-40 = 8 C or 46.4 F. That still seems low.

Edit: Its difficult for me to tell which position to take as the reading because all of the examples I'm reading are from non-can resources like this: http://www.obdsol.com/articles/obd-soft ... time-data/. In those examples the "A" position actually begins a position 6. The first two base 16 numbers are discarded because they are essentially headers denoting the response.

[skimask]

What type of sensor is the oil temp coming from?
If it's a thermistor type, can't remember the name for them, but they've got hundreds of K-ohms resistance at low temps, ranging to a couple of hundred ohms at higher temps (eg. ~200+ F).
Point being, at low temps, the thermistor types will run a needle gauge just fine, but trying to get a solid, accurate reading off one is a crap shoot.
I'd bet if you'd fire up the engine, get it up to operating temp, maybe take it out for a good hard drive, you'd find that the temperature would be much more reasonable.

[sti robot]

You might be right on that one.

On another note: That xgauge/scangauge stuff gets explained here. http://priuschat.com/threads/scanguage- ... dge.43139/

However, if 3008 is to believe then that is at bit 48 and is only 8 bits long (a single character).

Also, none of these ref positions in other peoples schemes really work if I don't know what they string they are receiving looks like. Does it include the header 01f? How about the first couple of bytes? Or are those discarded. I guess I'll just have to start recording and make myself a chart. Then get out the torque app and make the same chart under similar conditions and figure out which value (position) makes sense.

[skimask]

I guess I'll just have to start recording and make myself a chart.

That's what has usually worked for me. Grab a bunch of data, post-process it in a big ol' spreadsheet afterwards. Something like oil temp will obviously change in a predictable manner, eg. following coolant temp fairly closely, jump higher until heavy loads, drop under light loads, etc.
Can't go wrong with that plan.