DRB Protocol Information?

[BlueShadow]

Ive read through some notes and spreadsheet regarding the DRB protocols and threads on the topics which has gotten me going (thanks to Morris, Rob, Frank for that).

Now I have more specific questions, Ill start with just a few so as to not have a mile long post...

-When I send 0x10 (retrieve error codes) to the SBEC, I get a list of bytes, some would correctly correspond to the standard codes, but some don't, two examples from different ecus in base10: 58, 62, 14, 57, 3, 10, 5. other one: 47, 10, 14, 31, 37, 13, 27, 11. Both are followed by 0xFE, but then there is another byte, 0xDF in the first instance, 0xCC in the second.
So, since 3, 10, 5, 58 etc aren't the normal codes, what are these numbers? What is the DF, CC about?

-When I send 0x17 (clear codes command) with the engine off I get 0xFF (error). On the one SBEC actually in a car, engine running, issuing the same code causes the SBEC to reply with 0x00 repeatedly until powered off. What am I missing?

-Issuing 0x1A 0x01 (switch test) on the SBEC on my desk, returns a byte which when read in binary displays switch states correctly. Doing the same on the SBEC in the car activates the ASD for a moment and returns no byte?

If it matters, the SBEC in the car is one of Robs cals, both are SBEC-1s. The Actuator test modes are working though, yay :thumb:

Sorry for so much information, Ive got lots more questions, but most curious about this for now. Hopefully someone has some answers, Thanks in advance.

[ShelGame]

Ive read through some notes and spreadsheet regarding the DRB protocols and threads on the topics which has gotten me going (thanks to Morris, Rob, Frank for that).

Now I have more specific questions, Ill start with just a few so as to not have a mile long post...

-When I send 0x10 (retrieve error codes) to the SBEC, I get a list of bytes, some would correctly correspond to the standard codes, but some don't, two examples from different ecus in base10: 58, 62, 14, 57, 3, 10, 5. other one: 47, 10, 14, 31, 37, 13, 27, 11. Both are followed by 0xFE, but then there is another byte, 0xDF in the first instance, 0xCC in the second.
So, since 3, 10, 5, 58 etc aren't the normal codes, what are these numbers? What is the DF, CC about?

The 0x10 DRB mode should send 8 bytes back - 4 'pending' error code bytes and 4'stored' error code bytes. Each bit has a meaning.

Here's the 'key' for the 'stored' code, but the bit meanings are the same for the 'pending' codes:


ErrorBitRegisterStored0
b22_bit7 = $000000 ; 44 Loss of FJ2
b22_bit6 = $000000 ; 45 Overboost
b22_bit5 = $100000 ; 46 Battery Volts High
b22_bit4 = $010000 ; 47 Battery Volts Low
b22_bit3 = $001000 ; 51 Lean condition
b22_bit2 = $000100 ; 52 Rich Condition
b22_bit1 = $000010 ; 53 Prom Checksum
b22_bit0 = $000001 ; 54 Distributor Sync
ErrorBitRegisterStored1
b23_bit7 = $000000 ; 33 AC Cutout Relay
b23_bit6 = $000000 ; 34 Speed Ctl Solenoid
b23_bit5 = $100000 ; 35 Radiator Fan Relay
b23_bit4 = $010000 ; 36 Wastegate Solenoid
b23_bit3 = $001000 ; 37 Barometric Read Solenoid
b23_bit2 = $000100 ; 41 Charging System
b23_bit1 = $000010 ; 42 Auto Shutdown Relay
b23_bit0 = $000001 ; 43 Ignition Coil Control
ErrorBitRegisterStored2
b24_bit7 = $000000 ; 22 Coolant Temp Sensor
b24_bit6 = $000000 ; 23 Charge Temp Sensor
b24_bit5 = $100000 ; 24 Throttle Position
b24_bit4 = $010000 ; 25 AIS Motor
b24_bit3 = $001000 ; 26 Injector Current Limit Not Achieved
b24_bit2 = $000100 ; 27 Injector Driver interface
b24_bit1 = $000010 ; 31 Purge Solenoid
b24_bit0 = $000001 ; 32 Exh Gas Recirc Solenoid
ErrorBitRegisterStored3
b25_bit7 = $000000 ; 11 Engine Not Cranked Since Battery Disconnected
b25_bit6 = $000000 ; 12 Memory Standby Power Lost
b25_bit5 = $100000 ; 13 MAP Pneumatic
b25_bit4 = $010000 ; 14 MAP Electrical
b25_bit3 = $001000 ; 15 Vehicle Distance Sensor
b25_bit2 = $000100 ; 16 Battery Voltage Sense
b25_bit1 = $000010 ; 17 Engine Running Too Cool
b25_bit0 = $000001 ; 21 Oxygen Sensor



The 'pending' codes come out first, so a value of 5d (=101b) for the 7th byte would represent stored codes for EGR (32) and the Injector Driver Interface (27).



-When I send 0x17 (clear codes command) with the engine off I get 0xFF (error). On the one SBEC actually in a car, engine running, issuing the same code causes the SBEC to reply with 0x00 repeatedly until powered off. What am I missing?

Erasing the error codes only works while the engine is running. I don't know why they made that limitation. You should be able to send the 0x17, and a reply of 0xE0 3 times means that the codes were cleared. Not sure why you get a 0x00 back...

EDIT: Sorry, that's backwards - the engine must be off to clear the codes. It looks like it must be off, and you have to wait about 4 seconds before you try to erase the codes. A 0x00 return means you didn't wait long enough or the engine is running.


-Issuing 0x1A 0x01 (switch test) on the SBEC on my desk, returns a byte which when read in binary displays switch states correctly. Doing the same on the SBEC in the car activates the ASD for a moment and returns no byte?

Double check this one, it shouldn't make any difference if it's in the car or on the bench.

[RoadWarrior222]

Subscribed to impress chicks by h4XX0ring my car with windoze terminal :D

Actually, I've got a little "pocket computer" gizmo, circa '80 with 6K or so of RAM... with BASIC... just wondering if I could make it do something useful with this.... it already has a 5V serial interface!!!1111...

Sharp EL-5500III

Though come to think of it, I dunno if it's got serial code in ROM and whether I'll take five and a half Kb to shove the bits in and out.

[BlueShadow]

Rob,
Thank you! That makes sense about the error codes, I don't know why I thought it worked the other way.

Whats the difference between pending and stored? Are pending codes ones currently causing fault, stored ones that are not current faults, but stored in memory?

With the ECU on the bench and the one in the car, with engine off, power on for 1minute+ it fails to clear the codes. Ideas?

Its two ecus I have been testing. The one on my bench is a stock un-socketed one, the one in the car that was behaving oddly is socketed with one of your cals. I don't see why it would be doing that incorrect switch test compared to the stock one?

Again, excellent info, thanks!

[ShelGame]

Rob,
Thank you! That makes sense about the error codes, I don't know why I thought it worked the other way.

You thought it went the other way probably becuae so did I and that's what I had in my DRB spreadsheet.


Whats the difference between pending and stored? Are pending codes ones currently causing fault, stored ones that are not current faults, but stored in memory?

Honestly, I'm not sure. In newer cars, it takes more than 1 bad reading to set the permanent code. I always assumed it worked like this, but I honestly have read the error code stuff enough to know for sure that this is what it's doing.


With the ECU on the bench and the one in the car, with engine off, power on for 1minute+ it fails to clear the codes. Ideas?

Not really, I'll have to look at the code a little more. I remember from this morning that it does look at one other value (a counter I think). I'm not really sure how it uses that.


Its two ecus I have been testing. The one on my bench is a stock un-socketed one, the one in the car that was behaving oddly is socketed with one of your cals. I don't see why it would be doing that incorrect switch test compared to the stock one?

What cal exactly is on the chip? If it's an old T/SBEC cal, that might have something to do with it. There was some funky things going on in there until middle of last summer.

[BlueShadow]

I'm not sure what cal you used for it, but I ordered it somewhere around Feb2011, so could be what you refer to. That would then explain the switch test and maybe the infinite loop of 0x00 when I tried to clear the codes on that one?

If you can remember what needs to be done to clear the codes (even on the stock ecu) that would be great. No luck so far on the stock one after waiting / power on/off/on/off/on/off/on... So I'm a little stumped.

Thanks again, surely more questions will come as I dig more. Would like to make a basic drb-like module with reasonable functionality since we have a few TM cars - and it would be a neat project.

[wowzer]

have you made any more progress on this? would like to see if you have all the protocols and timing worked out.

[BlueShadow]

Looks like Rob had most of it figured out. I was able to get the ATM mode working fine on a stock ecu, but couldnt read out the codes correctly. The returned bytes would come out in different orders, and I could not figure out why. Could be the hardware I was using was too slow, but not sure

[bifurkas]

Hi to all! My name is Anatoly, I live in Russia, drink vodka and feed the bears on the street:D In addition i have a JEEP Wrangler 1994 with Mopar SBEC, so I have a some questions about it. When i send 0x10 to the SBEC, I get 1010FE1E or 10102CFE4A or ...How does it translate into code names? Thanks in advance for reply. PS: Sorry, my English is very bad.

[RoadWarrior222]

Well I could be wrong but what I'm understanding is that the hex chars in that are 8 bytes as above,

Taking 1010FE1E and converting to binary by pairs, you get
00010000
00010000
11111110
00011110

Which referring to above table which is specific to other models, (Though some might be similar) seems your battery is low and just about everything is unplugged. The guys at cherokeeforum.com or other jeep forums might have more idea.

[bifurkas]

What does the converting to bin? ShelGame (http://www.turbo-mopar.com/forums/member.php?141-ShelGame), how to use the 'key' for the 'stored' code? I do not understand! What is the 'stored' and 'pending' codes? Please help.

[wowzer]

Hi to all! My name is Anatoly, I live in Russia, drink vodka and feed the bears on the street:D In addition i have a JEEP Wrangler 1994 with Mopar SBEC, so I have a some questions about it. When i send 0x10 to the SBEC, I get 1010FE1E or 10102CFE4A or ...How does it translate into code names? Thanks in advance for reply. PS: Sorry, my English is very bad.

bringing this back from the dead.

i was using my drb ii with the logic analyzer on my smec to try to figure out some of the routines to incorporate into mpscan to simulate the drb stuff. when i had the drb return the dtc codes i got the bytes 05 20 22 15 fe 6a. after looking at the code it appears the system goes thru all 8 error code bytes and only sends back the values for bytes that are not equal to 0. the 0xfe signals the end of the error code listing and 0x6a is the checksum that is calculated by adding up all the error code values including the 0xfe and then adding 0x10 to it.

my question is: there were 4 error codes returned (this was using my smecstim by the way) by the drb ii as well as indicated by the analyzer byte stream as noted above. the drb said the codes were (not in any specific order):

1) injector #1 control circuit error
2) skip shift solenoid error
3) o2s stays at center
4) charging system voltage too low.

how does that match up with the bytes returned? in particular what is byte 0x05?

[ShelGame]

Those are the 'mask' codes. At least, that's what I call them.

Basically, that hex value is the offset used in the SMEC code to lookup the code number to report out to the scantool, and to flash to the dash. There can be many different offsets (and therefore diagnostics) to set a given error code. Some have 4 different diagnostics to set a code. But, the specific offset can tell you a lot about what software set the code.

Anyway, the code 0x05 is for the low battery volts.
0x15 --> code 27 Injector driver interface
0x20 --> code 21 Oxygen sensor
0x22 --> code 16 Battery Voltage Sense

Here's the key file that I use.

[wowzer]

thanks rob - helps alot. although the drb skip shift code is a bit funky. it recognized the ecu correctly (89 turbo 1 smec) so i'm surprised it gave this code description.