that's not BCD, it's hex.

Each Hexidecimal number(0-F) represents 4 bits of information, 2 per byte.
It looks like they are encoding floating point numbers, but I'm not sure what encoding is being used.

 

The OBDII packet consists of a header, data and crc byte(s).

83 F1 11 61 F0 FF D5

datalen = 3
data = 61f0ff
checksum = d5

The data is encoded differently for each PID you read out.

Have a look at http://www.lightner.net/lightner/bruce/Lightner-183.pdf

 

Not CAN. It looks like ISO 9141/KW2K bus traffic.

83 F1 11 61 F0 FF D5

83 = Priority/Type/Length
Bits:
7:6 = 10 = priority
5:0 = payload length in this case 3 (the data payload starts after the source address byte -- see below)

F1 = Target address ("F1" is a test tool address, Durametric in this case)
11 = Source address (ECU "11")

61 F0 FF is the data
61 is the SIDPR (positive response service ID) (in this case it is 21 or'd with 40. (don't ask) "21" is a special service number. The test tool uses this service number plus an offset (1 byte) to request the data at that offset.

F0 = the offset. "F0" is in the range "manufacturer defined conditional response where the condition is pre-defined in the module -- multiple conditions may be defined".

FF = the data...

D5 is the Crc

So:
83 F1 11 61 F0 C7 9D = data is C7
84 F1 11 61 F0 00 01 D8 = data is 00 01 = 0001
84 F1 11 61 F0 AA 10 91 = data is AA 10 = AA10
83 F1 11 61 F0 55 2B = 55
83 F1 11 61 F0 1D F3 = 1D
83 F1 11 61 F0 9F 75 = 9F
83 F1 11 61 F0 16 EC = 16
84 F1 11 61 F0 E7 3E FC = E7 3E = E73E
84 F1 11 61 F0 0B 00 E2 = 0B 00 = 0B00
84 F1 11 61 F0 08 00 DF = 08 00 = 0800
84 F1 11 61 F0 E1 FE B6 = E1 FE = E1FE
9E F1 11 61 F0 DA 84 9E 84 08 04 A8 50 00 54 B8 50 F2 F4 58 8A 88 40 F2 F2 64 8A 88 20 E6 FC 46 32 35 = DA 84...

 

Thanks so much for your help guys. Knowing which are the data bits of the message is an enormous step forwards!

In the example above, C7 = 995 (when a straight hex to decimal conversion = 199), so that's my next challenge to work out!

Cheers.

 

You have several one byte OBD2 data items to select from. Coolant temp for instance. Remember it is one C per bit with an offset of -40C.

Thus if "199" was coolant temp it would be 199 - 40 = 159C and that's 318F. Too hot. So it is not coolant temp.

Probably not intake air temperature either.

Not vehicle speed.

Not engine load.

Not timing.

Not fuel pressure.

Not throttle posiiton.

In fact the data may not represent any of the general OBD2 data parameter data. The same goes for the rest of the records/frames.

We have no record of the request made and even if we did we do not know what the offsets in the requests refer to and what affect the 'F0' has on the data returned, the scaling for instance.

 

There are 10 people in the world, those who know binary, and those that don't....

 

Interesting,

I'm a developer as well.
Also have a Durametric.

Reading all this, it's pretty hard to get known values combined with known parameters.

Just reading the bus is no fun...

I played around with the Durametric.
Their tool is ok, but there must be more values which they do not address...

 

This is an interesting thread. So what information is missing that would help to understand the data?

 

The offset that was supplied in the query for the data, what the offset refers to, which piece of data, and what "F0" means.

As I touched upon in an earlier post about that "F0": "manufacturer defined conditional response where the condition is pre-defined in the module -- multiple conditions may be defined".

 

995 / 199 = 5



Sent from my SAMSUNG-SGH-I727 using Tapatalk 2

 

Good observation. I've tried that against the other codes though and they don't seem to be quite so straight forward.

There has to be some floating point in there somewhere to get the fractional part of some of the values.

I've got to zip out shortly, but will have a look at this tomorrow - now the data bits are known this will hopefully be easier to crack. I still highly suspect that it is BCD displayed in hex - one of the binary bits would be a positive/negative indicator.

Glad people are finding it interesting - who knows what we'll be able to do with our cars if we crack it!!!!

Also, FYI, the 995 was a pressure reading.

Cheers.

 

If you're just doing it for fun, that's one thing. But OBD-II is a very well known protocol:
(don't peek if you're trying to do it as an exercise)
OBD-II PIDs » OBD-II Resource

That said, let us know if you find a way to read the oil temperature...which I can't seem to access with Torque Pro.

 

The OBD protocol on the Cayman does not return the Oil temp. I downloaded some open source C# code a while back and was able to get common values like coolant temp, speed, rpm, etc but oil temp did not return a good value. I have since gotten an AIM Solo DL which attached to the CAN bus and it does return the oil temp.

 

Porsche does not publish this info -- except to at least one tool maker and probably under a very tight NDA -- and is one of the few auto makers that does not even make this available for a price.

Thus there are probably a lot of values Durametric doesn't obtain. IIRC -- and I do not know how I came by this memory in the first place -- Durametric reverse engineered a PST2 diagnosis computer (or newer possibly to support newer models of Porsches) to learn some of the info it uses to obtain what values it does.

 

How can it not publish the info? OBD-II is an industry wide spec. Most of the info does appear when I hook up a generic OBD-II reader using Torque pro so at least that part conforms to the spec. Maybe there are some specific things Porsche would not want people to know...for example the difference in mapping between a Cayman S and R that gives the extra 10HP.

 

They have to support the standard OBD-II PID's which are emissions related. They do support some other common ones but not many from what I could determine. Porsche uses CAN bus internally which has access to everything but is not published for anyone to use. It can be reverse engineered which some have done like Durametric, AIM, ...

 

Yes,

Was at the OPC today.
My lights where always on and the light switch only lit the interiour guages when switched on.

They said the whole switch is programmable.
But I couldn't find it in de Durametric....

 

Hi,

Sorry I haven't posted these sooner - life has been manic.

Here are a couple of sets of ODB request, response and value combinations a camshaft reading:

Request 1: 87 11 F1 2C F0 01 01 02 06 20 CF
Response 1: 84 F1 11 61 F0 0B 00 E2
Durametric value 1: 0.1719

Request 2: 87 11 F1 2C F0 01 01 02 06 20 CF
Response 2: 84 F1 11 61 F0 08 00 DF
Durametric value 2: 0.1250

If people think that it will help, I will get complete combinations for all of the previously posted responses (unfortunately I didn't note these all down at the time).

G.