PCI Bus Documentation/Reverse-Engineering - DodgeIntrepid.Net Forums - Dodge Intrepid, Concorde, 300m and Eagle Vision chat
Reply
 
LinkBack Thread Tools Rating: Thread Rating: 1 votes, 5.00 average. Display Modes
post #1 of 54 (permalink) Old 04-16-2016, 08:51 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
PCI Bus Documentation/Reverse-Engineering

So I've been messing around with a little $10 Bluetooth OBD2 scanner and looking at all the data that travels along the PCI bus in the car. Here's what I've been able to document so far (note that it's plausible, albeit unlikely, that this may vary a little between model years and options, so just in case: this is on my '00 Intrepid ES 3.2L, which has OTIS and ATC in particular).

Code:
Known PCI bus data, sorted by header byte; descriptions and examples

0x10: RPM/MAP?
- [1..2] (Engine/Transmission Input)? RPM (*4)
- [3..4] Transmission Output RPM (*4)
- [5]    MAP (kPa)?
- [6]    CRC-8
::Example:
:: 10 26 84 0D 80 2C 6E
:: Input  RPM = 0x2684 / 4 = 2465.00
:: Output RPM = 0x0D80 / 4 =  864.00
:: MAP = 0x2C (44)
::BONUS!
:: With this info we can determine what gear we're in as well as vehicle speed!
::
:: First, some information we'll need.
::  1. 42LE Gear Ratios.
::     1st Gear: 2.84:1
::     2nd Gear: 1.57:1
::     3rd Gear: 1.00:1
::     4th Gear: 0.69:1
::     Reverse:  2.21:1
::     Final Drive: 3.89 for 2.7L, else 3.66 (unless swapped)
::     (Final Drive is stored in TCM, this is why you need a TCM
::      swap for an accurate speedometer if you swap final drives)
::  2. Tire Diameter.
::     26.2 inches is a safe assumption, go measure your own if you want a 100% accurate reading.
::     (This is why the speedometer reads slightly high when your tires lose tread)
::
:: Here's how we get it.
:: Current Gear Ratio (Approx) = Input RPM / Output RPM
:: In this case, 2465.00 / 864.00 = 2.853
:: We can safely assume this is 1st gear, so the true ratio is 2.84
::
:: Speed (MPH) = (InputRPM * TireDiameter * π) / (FDRatio * CurGearRatio * 1056)
::
:: So lets plug in our data:
::  (2465 * 26.2 * π) / (3.66 * 2.84 * 1056) = 18.48MPH
::
:: ALTERNATIVE FORMULA
:: Speed (MPH) = (OutputRPM * TireDiameter * π) / (FDRatio * 1056) * (MeasuredGearRatio / RealGearRatio)
::  (864 * 26.2 * π) / (3.66 * 1056) * (2.853 / 2.84) = 18.48MPH
::
:: No idea if one of these works better than the other for when the wheels lose traction.


0x1A: Cruise Control?
- [1] Throttle Position?
- [2] Stored/Set Speed (in km/h)
- [3] ?
- [4] ?
- [5] CRC-8


0x2B: HVAC Display
- [1] Status (Bitmask):
-------- 1 << 0: Face (Only)
-------- 1 << 1: Face & Floor
-------- 1 << 2: Recirc
-------- 1 << 3: Rear Defrost
-------- 1 << 4: Floor (Only)
-------- 1 << 5: Floor + Defrost
-------- 1 << 6: A/C
-------- 1 << 7: Defrost (Only)
- [2] ? 0x13 = Manual, 0x06 = Auto, 0x00 = Off
- [3] Temp (F)
- [4] CRC-8
::Examples:
:: 2B 02 13 45 2C
::  Status: 0b00000010; Face & Floor
::  ??????: 0x13; Manual????
::  Temp:   0x45, = 69F


0x2F: HVAC Control Broadcast?
- [1] ? ((Inverted) Bitmask)
- [2] ? ((Inverted) Bitmask)
- [3] CRC-8


0x33: Seatbelt
- [1] Status (Bool): On = 1, Off = 0
- [2] CRC-8
::Examples:
:: 33 01 B6 = Seatbelt Fastened! Good Job!
:: 33 00 AB = Seatbelt *NOT* Fastened. CLICK-IT OR TICKET B****


0x37: Shifter Position
- [1] Gear: P (0x01), R (0x02), N (0x03), D (0x05), AutoStick (0x06)
- [2] AutoStick Status?: 0x80 = AS Present? Gears Bitmask?
- [3] CRC-8


0x3D: Radio
- Varies greatly; Only showing full examples instead, w/o CRC byte
-- 3D 12 81 F1: Prev CD
-- 3D 12 81 F2: Next CD
-- 3D 12 83 23: FF Press
-- 3D 12 83 24: RW Press
-- 3D 12 83 25: FF/RW Release
-- 3D 12 83 26: Next Track
-- 3D 12 83 27: Prev Track
-- 3D 12 84 30: RND/Scan Off
-- 3D 12 84 32: Scan On
-- 3D 12 84 35: RND On


0x52: A/C Relay
- [1] Status (Bool): On = 1, Off = 0
- [2] CRC-8
::Examples:
:: 52 00 78 = A/C Relay Off.
:: 52 01 65 = A/C Relay On.


0x60: Headlight Switch
- [1] Dimmer Wheel (0xFF (max brightness) to... 0x13 (lowest brightness)?!)
- [2] Exterior Lights (Bitmask?)
- [3] CRC-8


0x72: Odometer
- 1/8000th of a mile increments. May need 0s padded on the left of the value if it's too short.
::Example:
:: 72 46 94 42 14 9C
:: 0x46944214 = 1,184,121,364
:: 1,184,121,364 / 8,000 = 148,015.1705
:: Result: 148,015.1705 miles on the odometer


0x80: Time. Reads like text (BCD format), e.g. 80 06 59 means 6:59
- [1] Hour (BCD Format)
- [2] Minute (BCD Format)
- [3] CRC-8
::Example:
:: 80 04 56 8C
:: Result: 04:56
:: Yes, "0x56" literally means 56. :)


0x8B: HVAC Fan/Temp Info
- [1] Fan Speed Position? 0x01 (LOW) - 0x0E (HI)
- [2] Temp (F)
- [3] CRC-8


0x8D: CD Changer
- Like Radio, this varies a lot. Still working out examples.


0xA0: DTE
- [1..2] Miles Til Empty (*10)
- [3]    CRC-8
::Example:
:: A0 02 C8 44
:: 0x02C8 = 712
:: 712 / 10 = 71.2 miles


0xF0: VIN
- [1]      Current VIN Index Position
- [2(..5)] ASCII VIN info @ Index
- [6]      CRC-8
::Example:
:: F0 01 32 45
:: F0 02 42 33 48 44 2E
:: F0 06 35 36 4A 37 FB
:: F0 0A 59 48 33 33 3D
:: F0 0E 34 37 39 36 7C
:: Assembled: 32 42 33 48 44 35 36 4A 37 59 48 33 33 34 37 39 36
:: Hex --> ASCII: 2 B 3 H D 5 6 J 7 Y H 3 3 4 7 9 6
:: Result: 2B3HD56J7YH334796
Some background info:
What Chrysler refers to as the "PCI Bus" is formally the SAE J1850 VPW standard, which has a data rate of 10.4kbit/s. To put that into perspective, modern CAN bus systems are usually 500kbit/s (over 48x faster). Therefore it should be expected that not everything that can be found on CAN bus systems will be found on our PCI bus. For example, power windows likely won't be available from the PCI bus. In general, if it doesn't save them any wires to put something on the PCI bus, you won't find it there. Meanwhile many CAN bus vehicles will put literally everything on the bus.

A common misconception is that data frames transmitted over a J1850 bus have 3 byte headers, so when people first try to look at this data they assume the 2nd and 3rd bytes are the 'target' and 'source' IDs for the data. The designers of these OBD2 Protocol translator chips often make this assumption too, unfortunately. However, the header can actually be either 1 byte or 3 bytes, depending on a bit being set in the first header byte. As far as I can tell, all data on our J1850 bus that doesn't originate from a scan tool uses the 1 byte header format. Important to keep in mind.

It is also possible for us to send, not just read, data on this bus ourselves:

Obviously though you can't simply remove something from the bus, so in this example the BCM is still sending the real odometer data to the instrument cluster. Even if I constantly send this custom odometer data myself over and over, the instrument cluster will still flicker briefly when it receives the real odometer data from the BCM (approximately once per second).

I'll share more info on how to read this data yourself when I can determine some better recommendations for the hardware necessary to do so.
MWisBest is offline  
Sponsored Links
Advertisement
 
post #2 of 54 (permalink) Old 04-16-2016, 10:27 PM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
FYI, it's possible to monitor a DRB-III just like everything else on the PCI bus. It'd be nice to figure out how to replicate some of its functionality so the average joe would be able to do dealer-level diagnostics and programming. If somebody has access to a DRB-III and is interested in doing this, please let me know!
MWisBest is offline  
post #3 of 54 (permalink) Old 04-17-2016, 02:54 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Managed to stumble across how to read some advanced data from the TCM. In this example, Clutch Volume Indexes.

Sample:
Input Frame (sent from scan tool to the TCM, including CRC byte at the end):
Code:
24 18 21 0B 01 00 59
Response Frame:
Code:
26 18 61 37 BC 00 50
In this case, we asked for the CVI of the L/R clutch, and the CVI response is 0x37 (55), very healthy and well within the acceptable range of 35 to 83 (lower numbers are better).


Here's a complete listing of the CVI query data for the various clutches, and the acceptable ranges listed in the FSM for the 42LE transmission:

L/R Clutch; Range: 35 to 83
Code:
24 18 21 0B 01 00 59

2/4 Clutch; Range 20 to 77
Code:
24 18 21 0C 01 00 D3

OD Clutch; Range 48 to 150
Code:
24 18 21 0D 01 00 5C

UD Clutch; Range 24 to 70
Code:
24 18 21 0E 01 00 D0
MWisBest is offline  
 
post #4 of 54 (permalink) Old 04-18-2016, 09:01 PM
Intrepid Newbie
 
Join Date: Feb 2016
Location: detroit
Posts: 36
Feedback: 0 / 0%
 
Quote:
Originally Posted by MWisBest View Post
So I've been messing around with a little $10 Bluetooth OBD2 scanner and looking at all the data that travels along the PCI bus in the car. Here's what I've been able to document so far (note that it's plausible, albeit unlikely, that this may vary a little between model years and options, so just in case: this is on my '00 Intrepid ES 3.2L, which has OTIS and ATC in particular).

Code:
Known PCI bus data, sorted by header byte; descriptions and examples

0x10: RPM/MAP?
- [1..2] (Engine/Transmission Input)? RPM (*4)
- [3..4] Transmission Output RPM (*4)
- [5]    MAP (kPa)?
- [6]    CRC-8
::Example:
:: 10 26 84 0D 80 2C 6E
:: Input  RPM = 0x2684 / 4 = 2465.00
:: Output RPM = 0x0D80 / 4 =  864.00
:: MAP = 0x2C (44)
::BONUS!
:: With this info we can determine what gear we're in as well as vehicle speed!
::
:: First, some information we'll need.
::  1. 42LE Gear Ratios.
::     1st Gear: 2.84:1
::     2nd Gear: 1.57:1
::     3rd Gear: 1.00:1
::     4th Gear: 0.69:1
::     Reverse:  2.21:1
::     Final Drive: 3.89 for 2.7L, else 3.66 (unless swapped)
::     (Final Drive is stored in TCM, this is why you need a TCM
::      swap for an accurate speedometer if you swap final drives)
::  2. Tire Diameter.
::     26.2 inches is a safe assumption, go measure your own if you want a 100% accurate reading.
::     (This is why the speedometer reads slightly high when your tires lose tread)
::
:: Here's how we get it.
:: Current Gear Ratio (Approx) = Input RPM / Output RPM
:: In this case, 2465.00 / 864.00 = 2.853
:: We can safely assume this is 1st gear, so the true ratio is 2.84
::
:: Speed (MPH) = (InputRPM * TireDiameter * π) / (FDRatio * CurGearRatio * 1056)
::
:: So lets plug in our data:
::  (2465 * 26.2 * π) / (3.66 * 2.84 * 1056) = 18.48MPH
::
:: ALTERNATIVE FORMULA
:: Speed (MPH) = (OutputRPM * TireDiameter * π) / (FDRatio * 1056) * (MeasuredGearRatio / RealGearRatio)
::  (864 * 26.2 * π) / (3.66 * 1056) * (2.853 / 2.84) = 18.48MPH
::
:: No idea if one of these works better than the other for when the wheels lose traction.


0x1A: Cruise Control?
- [1] Throttle Position?
- [2] Stored/Set Speed (in km/h)
- [3] ?
- [4] ?
- [5] CRC-8


0x2B: HVAC Display
- [1] Status (Bitmask):
-------- 1 << 0: Face (Only)
-------- 1 << 1: Face & Floor
-------- 1 << 2: Recirc
-------- 1 << 3: Rear Defrost
-------- 1 << 4: Floor (Only)
-------- 1 << 5: Floor + Defrost
-------- 1 << 6: A/C
-------- 1 << 7: Defrost (Only)
- [2] ? 0x13 = Manual, 0x06 = Auto, 0x00 = Off
- [3] Temp (F)
- [4] CRC-8
::Examples:
:: 2B 02 13 45 2C
::  Status: 0b00000010; Face & Floor
::  ??????: 0x13; Manual????
::  Temp:   0x45, = 69F


0x2F: HVAC Control Broadcast?
- [1] ? ((Inverted) Bitmask)
- [2] ? ((Inverted) Bitmask)
- [3] CRC-8


0x33: Seatbelt
- [1] Status (Bool): On = 1, Off = 0
- [2] CRC-8
::Examples:
:: 33 01 B6 = Seatbelt Fastened! Good Job!
:: 33 00 AB = Seatbelt *NOT* Fastened. CLICK-IT OR TICKET B****


0x37: Shifter Position
- [1] Gear: P (0x01), R (0x02), N (0x03), D (0x05), AutoStick (0x06)
- [2] AutoStick Status?: 0x80 = AS Present? Gears Bitmask?
- [3] CRC-8


0x3D: Radio
- Varies greatly; Only showing full examples instead, w/o CRC byte
-- 3D 12 81 F1: Prev CD
-- 3D 12 81 F2: Next CD
-- 3D 12 83 23: FF Press
-- 3D 12 83 24: RW Press
-- 3D 12 83 25: FF/RW Release
-- 3D 12 83 26: Next Track
-- 3D 12 83 27: Prev Track
-- 3D 12 84 30: RND/Scan Off
-- 3D 12 84 32: Scan On
-- 3D 12 84 35: RND On


0x52: A/C Relay
- [1] Status (Bool): On = 1, Off = 0
- [2] CRC-8
::Examples:
:: 52 00 78 = A/C Relay Off.
:: 52 01 65 = A/C Relay On.


0x60: Headlight Switch
- [1] Dimmer Wheel (0xFF (max brightness) to... 0x13 (lowest brightness)?!)
- [2] Exterior Lights (Bitmask?)
- [3] CRC-8


0x72: Odometer
- 1/8000th of a mile increments. May need 0s padded on the left of the value if it's too short.
::Example:
:: 72 46 94 42 14 9C
:: 0x46944214 = 1,184,121,364
:: 1,184,121,364 / 8,000 = 148,015.1705
:: Result: 148,015.1705 miles on the odometer


0x80: Time. Reads like text (BCD format), e.g. 80 06 59 means 6:59
- [1] Hour (BCD Format)
- [2] Minute (BCD Format)
- [3] CRC-8
::Example:
:: 80 04 56 8C
:: Result: 04:56
:: Yes, "0x56" literally means 56. :)


0x8B: HVAC Fan/Temp Info
- [1] Fan Speed Position? 0x01 (LOW) - 0x0E (HI)
- [2] Temp (F)
- [3] CRC-8


0x8D: CD Changer
- Like Radio, this varies a lot. Still working out examples.


0xA0: DTE
- [1..2] Miles Til Empty (*10)
- [3]    CRC-8
::Example:
:: A0 02 C8 44
:: 0x02C8 = 712
:: 712 / 10 = 71.2 miles


0xF0: VIN
- [1]      Current VIN Index Position
- [2(..5)] ASCII VIN info @ Index
- [6]      CRC-8
::Example:
:: F0 01 32 45
:: F0 02 42 33 48 44 2E
:: F0 06 35 36 4A 37 FB
:: F0 0A 59 48 33 33 3D
:: F0 0E 34 37 39 36 7C
:: Assembled: 32 42 33 48 44 35 36 4A 37 59 48 33 33 34 37 39 36
:: Hex --> ASCII: 2 B 3 H D 5 6 J 7 Y H 3 3 4 7 9 6
:: Result: 2B3HD56J7YH334796
Some background info:
What Chrysler refers to as the "PCI Bus" is formally the SAE J1850 VPW standard, which has a data rate of 10.4kbit/s. To put that into perspective, modern CAN bus systems are usually 500kbit/s (over 48x faster). Therefore it should be expected that not everything that can be found on CAN bus systems will be found on our PCI bus. For example, power windows likely won't be available from the PCI bus. In general, if it doesn't save them any wires to put something on the PCI bus, you won't find it there. Meanwhile many CAN bus vehicles will put literally everything on the bus.

A common misconception is that data frames transmitted over a J1850 bus have 3 byte headers, so when people first try to look at this data they assume the 2nd and 3rd bytes are the 'target' and 'source' IDs for the data. The designers of these OBD2 Protocol translator chips often make this assumption too, unfortunately. However, the header can actually be either 1 byte or 3 bytes, depending on a bit being set in the first header byte. As far as I can tell, all data on our J1850 bus that doesn't originate from a scan tool uses the 1 byte header format. Important to keep in mind.

It is also possible for us to send, not just read, data on this bus ourselves:

Obviously though you can't simply remove something from the bus, so in this example the BCM is still sending the real odometer data to the instrument cluster. Even if I constantly send this custom odometer data myself over and over, the instrument cluster will still flicker briefly when it receives the real odometer data from the BCM (approximately once per second).

I'll share more info on how to read this data yourself when I can determine some better recommendations for the hardware necessary to do so.
Which bluetooth scanner are you using? I was about to order one myself, but I came across so many horror stories about substandard chinese knockoffs and vehicles not being supported, I kinda backed off.
lukasjames is offline  
post #5 of 54 (permalink) Old 04-21-2016, 09:43 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Quote:
Originally Posted by lukasjames View Post
Which bluetooth scanner are you using? I was about to order one myself, but I came across so many horror stories about substandard chinese knockoffs and vehicles not being supported, I kinda backed off.
This is the one I'm using: Veepeak Mini Bluetooth OBD2 OBDII Scanner for Android with Power Switch

The problem is, with the car going down the road I am often running into issues. The data monitoring output starts getting messed up and eventually the entire thing disconnects. I haven't figured out yet if this is an issue with my laptop or with the scanner, I am in the process of making an Android app that connects to it and runs the stuff that I was doing manually from my laptop to rule it out.

In all likelihood the problem is a combo of the scanner and its Bluetooth interface. While this other one costs 3x as much, it's probably worth it: ScanTool 427201 OBDLink LX Bluetooth
That one uses an STN1110 chip instead of an ELM327 (or in most cases a clone of the ELM327), which is really superior, and still compatible with the plethora of apps that use the ELM327.

To accomplish my ultimate goal I'm going to need to create my own custom IC anyway, as none of these chips appear to be capable of using these 1-byte headers for sending data. In terms of general tasks like logging of data and regular scan tool stuff they're fine though.

Last edited by MWisBest; 04-21-2016 at 10:18 AM.
MWisBest is offline  
post #6 of 54 (permalink) Old 04-25-2016, 12:11 PM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Looks like I was slightly wrong about the 1-byte vs 3-byte header deal. I realized that the "H-bit" in the HVAC Display frame (header 0x2B) is 0 instead of 1, which is supposed to indicate that frame used a 3-byte header. Looking at the data in that frame clearly shows it is in fact a 1-byte header though.

After a good deal of searching I found the official SAE J1850 standard document (which I've attached most of), and on page 9 it indeed shows that there is another format of the 1-byte header where all 8 bits are used to form a message ID.

Here's the end result of this new nonsense:
  • If the H-bit is set to 1, you're definitively looking at a 1-byte header.
  • If the H-bit is set to 0, you might be looking at a 3-byte header, or you might be looking at a 1-byte header.
In other words, half the time the H-bit is utterly useless.
Who the hell came up with this junk?
Attached Files
File Type: pdf saej1850 (p1-11).pdf (135.9 KB, 17 views)
File Type: pdf saej1850 (p12-22).pdf (113.4 KB, 5 views)
File Type: pdf saej1850 (p23-33).pdf (92.8 KB, 7 views)
MWisBest is offline  
post #7 of 54 (permalink) Old 04-27-2016, 10:42 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Well I've got some great news.

The DRB-III scan tool uses a database file, and in a whopping 3 days, I have managed to start reading useful info from this file.

Here's an example:


There's still a long way to go, but the new goal is to get dealership-level diagnostics into the hands of us average home mechanics, for just the cost of a little Bluetooth or USB OBD2 scanner. (I plan to make all software and info related to this FREE and OPEN-SOURCE)
MWisBest is offline  
post #8 of 54 (permalink) Old 05-01-2016, 01:53 PM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Making more progress with the DRB-III database reader.



So at this point I'm now able to search for modules (e.g. BCM, TCM, etc), and then get a list of stuff that is supposed to work with said module. It's not perfect (for some reason it doesn't list some stuff that I have tested and am certain works), but it's nice that it takes some of the guesswork out of this process.
MWisBest is offline  
post #9 of 54 (permalink) Old 05-02-2016, 01:55 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Well this is certainly interesting.

The majority of the stuff I'm finding in the DRB-III database... is SAE J2190 requests.
Yes, this crap is (kind of) a DEFINED STANDARD.
This DRB-III database is mainly just an index, putting names and numbers next to all the data (because the names and numbers aren't totally standardized, but the various *functions* mostly are).
MWisBest is offline  
post #10 of 54 (permalink) Old 05-12-2016, 04:55 PM
Intrepid Newbie
 
Join Date: May 2016
Posts: 8
Feedback: 0 / 0%
 
Hey! Nice work! Finally there's a light in this vast darkness.

Do you have the yellow super card (CH8361) too? The database in it holds important informations about CCD/SCI protocol.
entropy is offline  
post #11 of 54 (permalink) Old 05-12-2016, 08:51 PM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Quote:
Originally Posted by entropy View Post
Hey! Nice work! Finally there's a light in this vast darkness.

Do you have the yellow super card (CH8361) too? The database in it holds important informations about CCD/SCI protocol.
I guess I should clarify: I'm just working with the 'database.mem' file that is included with the DRB-III Emulator software. This file is dated July 2007, and the final DRB-III update disc was released in January 2008, so it seems likely that the physical DRB-III device used this file too. There is CCD and SCI stuff in here as well, for example:


The DRB-III Emulator supposedly can work like all the cards too, there are separate exe's for e.g. Crossfire, Sprinter, ST22, and SuperCard2. But it only has the one database file for all of them, so I'm not exactly sure what the various cards really did.


As far as the physical protocol levels:

I think SCI should be fairly simple. Everything I've found points to it being basically like a standard 5V UART/TTL connection, possibly with inverted logic. Baud rate should be 7812.5 for a standard command/interrogate mode, and 62500 for a logging mode. I'll see if I can whip something up to test this.

CCD on the other hand looks somewhat foreign. IMO the best option is to just get an IC to interface with it, look up "CDP68HC68S1". Should be inside any computer module that uses CCD, or they seem to be for sale on eBay as well.
MWisBest is offline  
post #12 of 54 (permalink) Old 05-13-2016, 12:14 AM
Intrepid Newbie
 
Join Date: May 2016
Posts: 8
Feedback: 0 / 0%
 
Thanks! You've got everything right with the protocol levels.
I'm trying to reverse engineer the CCD/SCI bus for over a year. It looks like it can be done in a few days efficiently.
I knew for some time that the DRB request message would start with the B2 ID byte, followed by a target module byte and 2 parameter bytes. The response message would start with F2.

Can you please compile a list like this on the picture or walk me through the process to extract these informations? I don't have this database file though.

Edit: grammar

Last edited by entropy; 05-13-2016 at 01:49 AM.
entropy is offline  
post #13 of 54 (permalink) Old 05-13-2016, 01:53 AM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Quote:
Originally Posted by entropy View Post
Thanks! You've got everything right with the protocol levels.
I'm trying to reverse engineer the CCD/SCI bus for over a year. It looks like it can be done in a few days efficiently.
I knew for some time that the DRB request message would start with the B2 ID byte, followed by target a module byte and 2 parameter bytes. The response message would start with F2.

Can you please compile a list like this on the picture or walk me through the process to extract these informations? I don't have this database file though.

Edit: grammar
I'm planning on releasing this database reader program as open-source software soon, it's just still quite a mess and incomplete. At first it's only going to be the little console-like interface thing I'm demoing here, but the end goal is a proper GUI to browser the database and some actual API for it.

As for the database file itself... I'm not sure on how (il)legal it is for me to distribute it directly. I think what I'll probably end up doing is exporting it to some sort of CSV file and then bundle that with the program. While I highly doubt anybody would care about distributing the database file itself, the last thing a project like this needs is to be shut down by some stupid copyright infringement mess.

EDIT: Out of curiosity, is this your blog here? https://chryslerccdsci.wordpress.com/ (If not it's worth a look :P)

Last edited by MWisBest; 05-13-2016 at 01:55 AM.
MWisBest is offline  
post #14 of 54 (permalink) Old 05-13-2016, 02:06 AM
Intrepid Newbie
 
Join Date: May 2016
Posts: 8
Feedback: 0 / 0%
 
You've got a valid point. Was the database somehow encrypted? The CCD-bus is quite uncommon nowadays, as for the PCI-bus it is younger and commonly used in Chrysler vehicles.
Can't wait to see your work. In the meantime I'll test those commands that you printscreened.

Edit: Yes, that's my blog. Programming the scanner gives me a hard time but I'm getting along.

Edit 2: Wonder of wonders I got the database file. I completely forgot about a wiTECH installation on my system drive and there it was. Can you give me a starting point on how to interpret the data in it? I don't want to decode it like you, I just like to understand the internal data structure.

Last edited by entropy; 05-13-2016 at 12:09 PM.
entropy is offline  
post #15 of 54 (permalink) Old 05-13-2016, 02:46 PM Thread Starter
Intrepid Fan
 
MWisBest's Avatar
 
Join Date: Dec 2013
Location: Wisconsin
Posts: 120
Feedback: 0 / 0%
 
Quote:
Originally Posted by entropy View Post
You've got a valid point. Was the database somehow encrypted? The CCD-bus is quite uncommon nowadays, as for the PCI-bus it is younger and commonly used in Chrysler vehicles.
Can't wait to see your work. In the meantime I'll test those commands that you printscreened.

Edit: Yes, that's my blog. Programming the scanner gives me a hard time but I'm getting along.

Edit 2: Wonder of wonders I got the database file. I completely forgot about a wiTECH installation on my system drive and there it was. Can you give me a starting point on how to interpret the data in it? I don't want to decode it like you, I just like to understand the internal data structure.
The database file is just a strange proprietary format.

It's easier for me to describe it with code, so I'll just post excerpts of my code (C#).

There's a header at the top of the database which describes the tables in it (in terms of location in the file and the number/size of rows and columns)
Code:
/* Note: "this.reader" is a BinaryReader object, and this code
 * starts from the very beginning of the database file.
 * A 'ReadUInt32' for example assumes a little-endian 4 bytes,
 * e.x. 0x4CDF2400 is read as 0x0024DF4C.
 * A 'ReadBytes' on the other hand reads as-is. */
private void makeTables()
{
	uint fileSize = this.reader.ReadUInt32();
	ushort idk = this.reader.ReadUInt16();
	ushort numTables = this.reader.ReadUInt16();
	this.tables = new Table[numTables];
	for( ushort i = 0; i < numTables; ++i )
	{
		uint offset = this.reader.ReadUInt32();
		ushort rowCount = this.reader.ReadUInt16();
		ushort rowSize = this.reader.ReadUInt16();

		/* While technically the 'stated' code alone was correct, it had an issue:
		 * there are some columns with a size of 0! This is a waste.
		 * As such, empty columns are now removed and field IDs adjusted for that. */
		byte statedColCount = this.reader.ReadByte();
		byte[] statedColSizes = this.reader.ReadBytes( statedColCount );

		/* There's actually room reserved for 27 bytes after the statedColCount,
		 * so it is necessary to seek past whatever bytes that go unread. */
		this.reader.BaseStream.Seek( 27 - statedColCount, SeekOrigin.Current );

		List<byte> colSizes = new List<byte>();
		for( byte j = 0; j < statedColCount; ++j )
		{
			if( statedColSizes[j] != 0 )
			{
				colSizes.Add( statedColSizes[j] );
			}
		}

		this.tables[i] = new Table( this, i, offset, rowCount, rowSize, (byte)colSizes.Count, colSizes.ToArray<byte>() );
	}
}
There's a total of 28 tables. Some of them are slightly quirky, for example tables 26 and 27 (the last 2, I'm speaking in zero-index here) aren't really tables, they're just a big glob of null-separated strings, which are indexed from table 16. The first column in table 16 is a simple unique ID key, and the second column is interpreted like this:
Code:
int tableid = 27 + (int)( row.col[1] >> 24 ) - 1;
long stringOffset = row.col[1] & 0xFFFFFF;
/* to get the string, it seeks to this.tables[tableid].offset + stringOffset,
 * and reads chars until the first null byte is encountered */
So any table which needs a string/name (for example table 23, the 'transmit' table, with the names like 'ENGINE RPM' in the last screenshot I showed) has a column containing an ID of an entry in table 16, so to get the string you'd find the row in table 16 with that ID and get the string that row points to as shown above.

The main challenge is figuring out what each table is for. It's like looking at an Excel file with 28 sheets that contain only numbers. No sheet names, no column names, etc.

Oh also, there's 1 odd difference with endianness between the database file included with wiTECH (in that legacyDB folder) and the one included with the emulator by Controller Technologies (who seems to be the original designer of the physical DRB-III units as well): the bytes of columns are (generally) little-endian in the wiTECH file, but they're big-endian in the Controller Technologies file.

Last edited by MWisBest; 05-13-2016 at 02:49 PM.
MWisBest is offline  
Sponsored Links
Advertisement
 
Reply

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the DodgeIntrepid.Net Forums - Dodge Intrepid, Concorde, 300m and Eagle Vision chat forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

Member names may only be composed of alpha-numeric characters. (A-Z and 0-9)

!!ATTENTION ADVERTISERS!! If you intend on advertising anything on this forum, whatsoever, you are required to first contact us here . Additionaly, we do NOT allow BUSINESS NAMES unless you are an Authorized Vendor. If you own a business, and want to do sales on this site via posting or private message, you will need to follow the rules. Shops, Stores, Distributors, Group Buys without being authorized will see your account terminated.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid email address for yourself.

Email Address:
OR

Log-in









Random Question

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page
Display Modes Rate This Thread
Linear Mode Linear Mode
Rate This Thread:



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome