It turned out that the SCI-bus doesn’t need inverted UART logic to communicate. So the “74LS04” logic converter is not needed, therefore its two input/ouput pins have to be soldered together. It’s not a major PCB design fault, it works. Maybe I redesign the PCB if I run out of them.
I found out this logic error by trying to connect to the SCI-bus and there were no messages received, only “Frame Errors”.
After the fix the first request I tried was the fault codes stored in the PCM:
CHRYSLER CCD/SCI SCANNER V1.20 LD CCD INITIALIZATION: OK! SCI INITIALIZATION: OK! CCD-BUS IDLE DETECTION: OK! 1 MHZ CLOCK GENERATOR: OK! BUTTONS: OK! EEPROM: OK! STATUS = 0 READY FOR COMMUNICATION! SCI 4357588 10 3E FE 4C SCI 5361232 10 3E FE 4C SCI 6364760 10 3E FE 4C SCI 7368288 10 3E FE 4C SCI 8359148 10 3E FE 4C SCI 9362536 10 3E FE 4C
I simply sent the byte 0x10 every second at 7812,5 baud speed. The response consists the following:
[0] = 0x10 = Request echo, good thing to know to which request the PCM is responding
[1] = 0x3E = Fault code list, if there’s none then it continues with 0xFE
[2] = 0xFE = End of fault codes listing
[3] = 0x4C = CRC-8, also good thing to check if the message is received correctly: 10+3E+FE = 14C, 14C & FF = 4C
There’s a .PDF on the internet that contains error codes not only in the traditional OBD-II format but in HEX format too. You can downloat it below:
http://ftp.hamsk.ru/auto/OBD-2/docs/Chrysler_OBD2_codes.pdf
https://chryslerccdsci.files.wordpress.com/2016/06/chrysler_obd2_codes.pdf
There are older documentations that match the above pdf:
1995-1997:
95-97 MIL Codes 01
95-97 MIL Codes 02
95-97 MIL Codes 03
1998:
98 MIL Codes 01
98 MIL Codes 02
98 MIL Codes 03
The 3E error code is listed as P0132. The fault name is O2 SENSOR 1/1 HIGH and the description is Oxygen sensor 1/1 input voltage maintained above normal operating range / shorted to voltage.
This is most likely true because the key method returned with the 21 MIL code which indicates an Oxygen sensor fault. Also the fuel mileage is very poor, too (9-12 liters/100 km).
Chrysler Scanner 
Have you figured the packet ID for fuel level yet? I have been working on CCD for communicating to the gauge clusters and have everything figured out except for fuel level.
https://github.com/Alexia/CCD-CAN_bus/blob/master/CCDCodes.h
LikeLike
Nice code you got there!
It’s not confirmed yet but check out the 94 ID, I got all the four gauges in there.
94 XX YY CS
BCM to MIC Messages:
– YY: 00 = Fuel, 01 = ECT, 02,22 = VSS, 03,23 = RPM
– XX: Value
Note that the VSS (Vehicle Speed) and RPM gauge has multiple codes covering certain ranges (02: 0-70 km/h, 22: 70-140 km/h, didn’t get further; 03: 0-2000 RPM, 23: 2000-4000 RPM). The values are not precise, I’m recalling them from memory. Also the secondary codes’ values are going backwards, meaning 94 FF 22 CS means 71 km/h.
LikeLike
I gave that a try on my setup and no luck. My guess is that 0x94 is either specific to the BCM or OBD-I vehicles.
LikeLike
Try one of these:
MIC XJ; sc: MIC; 0x5dc:
SELF TEST: CCD; xmit: B2-22-E0-00-00; sc: MIC; 0x80002a25
A/C CLUTCH: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d04
A/C EMCC REQUEST: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d05
BEEP REQUEST: CCD; xmit: DA-00-FF; sc: MIC; 0x80004d07
BRAKE PEDAL: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d08
CLUSTER ALARM: CCD; xmit: DA-00-FF; sc: MIC; 0x80004d0a
CRUISE LAMP: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d0d
EMISSION REMINDER: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d10
ENGINE LAMP STATUS: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d14
LOCK DOORS: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d1c
OD LOCKOUT LAMP RQ: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d1d
OIL PRESSURE: CCD; xmit: 0C-00-FF; sc: MIC; 0x80004d23
SC OVERRRIDE: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d26
SPEED CONTROL: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d27
TORQUE CONVERTER: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d41
TRANS IN PARK NEUT: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d45
TRANS TYPE: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d46
UPSHIFT INDICATOR: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d49
US/METRIC: CCD; xmit: DA-00-FF; sc: MIC; 0x80004d4a
BATTERY VOLTAGE: CCD; xmit: 0C-00-FF; sc: MIC; 0x80004d51
COOLANT TEMP: CCD; xmit: 0C-00-FF; sc: MIC; 0x80004d54
ENGINE RPM: CCD; xmit: E4-00-FF; sc: MIC; 0x80004d5a
ENGINE TEMP: CCD; xmit: 8C-00-FF; sc: MIC; 0x80004d5e
FUEL TANK LEVEL: CCD; xmit: 25-00-FF; sc: MIC; 0x80004d60
VEHICLE SPEED: CCD; xmit: 24-00-FF; sc: MIC; 0x80004d64
PCM Monitor: CCD; xmit: 00; sc: MIC; 0x80005805
Fuel related messages:
FUEL LEVEL VOLTAGE: CCD; xmit: B2-20-14-0B-00; sc: Body; 0x80003a57
FUEL LEVEL VOLTAGE: CCD; xmit: B2-20-14-05-00; sc: Body; 0x80003a58
LOW FUEL WARNING: CCD; xmit: F1-00-FF; sc: Body; 0x80004c6b
WATER IN FUEL: CCD; xmit: A4-00-FF; sc: MIC; 0x80004d50
FUEL LEVEL COUNTS: CCD; xmit: 1C-00-FF; sc: MIC; 0x80004d5f
FUEL TANK LEVEL: CCD; xmit: 25-00-FF; sc: MIC; 0x80004d60
FUEL TYPE MSG: CCD; xmit: EC-00-FF; sc: Compass Mini-Trip; 0x80004e76
FUEL PERCENT MSG: CCD; xmit: 25-00-FF; sc: Compass Mini-Trip; 0x80004e7e
FUEL USED MSG: CCD; xmit: 44-00-FF; sc: Compass Mini-Trip; 0x80004e7f
There are DRB request messages (B2) which won’t drive the MIC, The CRC byte is redacted in these examples so you should calculate it and add to the end of the messages.
There are identical messages for multiple things. It’s because they are bit-encoded in the same message byte. There’s not much information about them yet.
LikeLike
I did not get anywhere with fuel level, but noticing the 0xA4 controlled more than just the two features I found I went back over it. It is a bit field for the most part.
This probably will not format correctly so here a link to the commit. I do not have any of the other features on this vehicle to test with so these two features is as far as I could get.
https://github.com/Alexia/CCD-CAN_bus/commit/0c9dcbfa9f48b30ae3e237777a1f8a3bd13b07bf#diff-c554ac50b521510381da970e15ba4153R57
/*
ID – Shift Light – Cruise Control
The payload is two bytes long with each bit indiciating a different message. Originally I thought that each byte controlled actually one function, but that assumption was wrong after prompts from laszlodaniel that 0xA4 was being used for more than two functions. Some single bits control individual features. However, in the case of the “shift up” light for manual transmissions I have only been able to toggle it by setting the first four bites of the first byte to on.
So far:
First byte:
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|—|—|—|—|—|—|—|—|
| | | | | | | | |
|—|—|—|—|—|—|—|—|
| Shift Light | | | | |
Second byte:
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|—|—|—|—|—|————–|—|—|
| | | | | | Cruise Light | | |
*/
LikeLike
I think the logic levels, frames, fields and pin outs are well defined in the Society for Automotive Engineering (SAE) document “SAE J2610-2002 Serial Data Communications Interface” – historically Chrysler adapted their previous DRBII compatible connector and protocol to a retro-active specification proposed to the SAE and assigned a number. After it was decided to move everyone to ODBII – Chrysler reacted by building add-on devices called “adapter modules” to help with the transition and so car dealers who had already bought a DRBII could service legacy vehicles and newer ODBII Chrysler vehicles with the same DRBII device. A similar approach was taken for retro-actively documenting the “messaging protocol” so the old SCI would “fit” within a documentation structure for ODBII such that SCI would be a proprietary “dialect” it was assigned “SAE J2190 Diagnostic Protocol for PCM Applications” and credited as the work of DiamlerChrysler Corporation (Chrysler Group) as a “proposed standard” but was never completed and published (it was abandoned). — The SAE makes money by selling copies of the published documents, but cannot provide you with unpublished documents. Both documents are available from a search engine in china called Baidu via a flash online reader. Its hard for an english reader to use, but there are buttons for revealing the entire PDF format of both documents, 20 pages and 61 pages respectively. I think the unplushed J2190 document would be most useful for you, from what little I have read of it, many of your discoveries and assumptions seem correct. Contact me if you would like some help accessing the documents, perhaps I could help.
LikeLike
According to page 12 of the J2610-2002 document (issued 2002-04) the “Tester receiver circuit” should contain a logic level inverter but in reality it doesn’t need one in my case. Strange.
I got the J2190 document too (issued 1993-06-25) with a different name and different page count (Enhanced_EE_Diagnostic_Test_Modes, 63 pages). It’s interesting but I couldn’t use it. The SCI-bus doesn’t behave like that.
It’s easier now because others reverse engineered the SCI-bus and not so long ago someone partially reverse engineered the most recent DRB-III database. It contains both CCD-bus and SCI-bus messages.
If you have access to some of the unpublished J2190 document then it would be good to read it.
Thanks for your message and help!
LikeLike
No, I don’t have access to any more than I think you do. The Jun93 document was the most relevant possibility. — It seems really strange though that it was submitted by Chrysler for it not to match the DRB-II protocol, since that was its intended purpose. It was cancelled in 2008 in relation to the newer ISO protocols taking their place.. and I think them being rolled into the LIN bus. I have three physical DRB-IIs sitting around. Perhaps I’ll hook them up to an ftdi and look at the protocol.. maybe lau and wireshark could help decode the protocol, though I am discouraged since you say its something completely different.. puzzling.
LikeLike
Ah. I read your DodgeIntrepid forum thread on wiTech. I think we’re on different buses and decades. I’m coming from DRB-II and 1989 Dodge Ram vehicle that only has the original SCI bus, none of the CCD or VPW flavors for communications. Your way down the Timeline after things got all unified and chip-ified. But that might explain the electrical difference. Chrysler had a bunch of [after the Patent] adapters to ‘tru-up’ the logic levels and make the connectors, sort of compliant/compatible.. later. DRB-III even got resistors in the cables to help things along.. it was all very analog. Hal Zotorski (?) was part of SAE and I suppose put J2190 together, so it had lots of wiggle room for extra-modes to support the original msg-request, msg-response protocol. I have no ideas about the CCD bus protocols, even if they are mutated versions of the SCI msg protocol across an addressable bus.. but that ‘definitely’ explains why it wouldn’t look similar.
LikeLike
You’re probably right. Those years make all the difference. I played with the CCD-bus for over a year, now I turn to the SCI-bus. The communication protocol is straightforward (simple UART) and there are lots of request messages to try since the DRB-III database has been partially reverse engineered. Some DRB-II requests are working with my 1995 Stratus though, for example the DTC listing (0x10).
I’m currently developing a C# program for my scanner to make it flexible with all these messaging. Until now I hard coded the requests into the scanner. It’s not so efficient…
LikeLike