Decoding OBDII Comms


Closed Thread
Results 1 to 13 of 13

Hybrid View

  1. #1

    Default Decoding OBDII Comms

    I'm working on some serial comms traffic and trying to work out how a value is being derived from some hex data.

    I'll give you an example, we have two data bytes $88 + $77 being transmitted in response to request for temperature data.

    From these two bytes it generates a temperature value of 29C, now only one of the bytes may be being used of course.

    A few more clues.

    "This is showing the value of Motor Power Inverter Module Temperature Sensor.
    Temperature of motor power inverter module is calculated at Motor Driver Module.
    [Operating Range]

    -40[°C] - 120[°C]
    -40[°F] - 248[°F]

    I though there might be an 0-5v 8bit dac involved in here somewhere and it's sending a voltage value from the sensor which is being converted in the software using some formula to the 29C

    Any ideas on how that 29C is derived from that data?


    Ditto on another temp sensor data serial chat we get $77 + $41 and it generates the value 36C on screen?

    Same clues as above and same sensor range.

    BCD? It doesnt appear to be ASCII? It doesn't appear to be a simple ofset etc?

    Hoping for a PB genius to give me some clues?

  2. #2


    Did you find this post helpful? Yes | No

    Default Re: Decoding OBDII Comms

    Bump no ideas from the PBP collective?

    I'll dig out another data sample with a different temp so we can see the change and perhaps establish the relationship.
    I suppose it could be some sort of look up table?

  3. #3
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,605


    Did you find this post helpful? Yes | No

    Default Re: Decoding OBDII Comms

    Hi,
    No, it's really quite hard (for me at least) to "translate" something like that with just one sample as a reference. If you could get 5 samples or something like that over a range of temperatures (and what they should correspond to) it might be easier - not saying I'm the man to pull it off though....

    However, it would seems to me that this sort of stuff should be documented somewhere, I mean isn't OBDII a "standard"? Doesn't it have a protocol specification?

    /Henrik.

  4. #4


    Did you find this post helpful? Yes | No

    Default Re: Decoding OBDII Comms

    Here is another example this is reporting amps.

    The data is two bytes. How is the amps being derived from those two bytes?

    $FF $A6 = -4.5A
    $00 $5F = +4.6A
    $01 $16 = +13.6A
    $01 $61 = +17.1A

    I suspect the sign is in the first byte.

    In the bottom example I was thinking 1 x 128 + $61 = 225 then do something to get 17.1?

  5. #5
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,605


    Did you find this post helpful? Yes | No

    Default Re: Decoding OBDII Comms

    Hi,
    It looks like you have a simple scale of ~20 counts per ampere.
    $005F is 90 in the decimal, 90/4.6A=19.5 counts per Amp
    $0116 is 278 in decimal, 278/13.6A=20.4 counts per Amp
    $0161 is 353 in decimal, 353/17.1A=20.6 counts per Amp

    $FFA6 = 65546 which in two complements is -89, 89/4.5=19.8 counts per Amp

    Average that out a bit and I'd call it 20 counts per ampere.

    /Henrik.

  6. #6


    Did you find this post helpful? Yes | No

    Default Re: Decoding OBDII Comms

    Thanks Henrik that fits in with some other tinkering i have been doing. More data to follow.

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts