Decoding OBDII trouble codes

[HenrikOlsson]

Hi,
This compiles (to 122 words for a 16F628) but I've got no hardware to try it out, "should" work though ;-)

Diag VAR BYTE[5]   ' Array for complete message

DTC_High VAR Byte  ' Upper byte of message
DTC_Low VAR Byte   ' Lower byte of message

i VAR BYTE         ' General purpose

'Get the top two bits of the high byte and shift it down so
'it becomes 0-3. Then convert to the correct character.
i = (DTC_High & %11000000) >> 6  ' Temp now 0-3 (borrow Diag[1] for this op)
Lookup i, [32,19,18,37], Diag[0]

' Now extract the next four "digits" in the same way.
Diag[1] = DTC_High & %00110000   ' Isolate bits 4,5
Diag[1] = Diag[1] >> 4           ' Shift down to bits 0,1
Diag[2] = DTC_High & %00001111   ' Isolate bits 0-3
Diag[3] = DTC_Low & %11110000    ' Isolate upper four bits
Diag[3] = Diag[3] >> 4           ' Shift down
Diag[4] = DTC_Low & %00001111    ' Isolate lower four bits


' Now, if Diag[0] is 32 we add 48 to it and it becomes 80 which
' is the ASCII code for "U". If Diag[1] is 2 we add 48 to that
' so it becomes 50 which is the ASCII code for "2" and so on.
HSEROUT["Error code: "]
For i = 0 to 4
  HSEROUT[Diag[i] + 48]
Next

/Henrik.

[retepsnikrep]

Very nice thanks I'll study that.

[retepsnikrep]

Much appreciated Henrik that seems to work very well.

I will post my pbpro OBDII code for ISO9141 vehicles when finished for those who may want to make their own reader?
All been done before probably and much better than i have done it i'm sure, a good learning experience for me though.
My gizmo now reads DTC codes, send/receives PID's and can clear codes etc. All using the trusty 12F683

[Demon]

I bought an OBD-II reader thinking I could get access to as much information as my mechanic; I was wrong.

My reader reported no codes while his Snap-On unit went into detail about individual wheelspin and pointed to a problem with the sensor in one of the front wheels.

Is it possible for us to get into that much detail? Or is there some sort of "licensing" lock-out preventing us to such detailed information?

[retepsnikrep]

OBDII readers are not created equal, there are lots of manufacturer specific codes that can only be obtained at vast expense or reverse engineering.

[Demon]

Can I chose another answer?

That's what I was afraid of. That the Snap-On and other professional tools have a catalogue of codes that is not accessible to the public.

Cause right now that OBD-II codereader is not very useful. It tells me that me catalyser is finished, no surprise on a 2002 Buick Rendezvous with over 200K km. It wouldn't even report a generic code for the ABS while the light came on in the dash.

That's where the Snap-On tool shined, it had info on each individual wheel sensor.

[Demon]

You are right when it comes to manufacturer specific codes. Just looking at ScanXL, there's different software add-ons by manufacturer. I have a Buick Rendezvous and it's staggerring how many more codes I can get to and the ABS ones that interested me are here (ScanXL links to Palmer for their references):

http://www.palmerperformance.com/sup...m_enhanced.php

Engine Parameters, 2100 parameters
Transmission Parameters, 491 parameters
Fuel Pump Parameters, 15 parameters
ABS Parameters, 304 parameters
Airbag Parameters, 69 parameters
Hybrid Battery Parameters, 56 parameters
Hybrid Powertrain Parameters, 186 parameters

And this is the subset that I probably have in my OBD-II reader:

Generic OBD-II Parameters, 229 parameters

I cannot see myself trying to reverse-engineer formulas for each individual sensor, the task is staggerring. The only good thing is that I have a Buick and my wife has a Pontiac, so the codes would work for both cars.

Robert