PCI and OBD

unixxx · 02-15-2006, 09:39 PM

I was checking out the service manual for my 05 Jeep Liberty to figure out how to control my factory Sirius satellite radio without buying the Sir-Alp1. The manual showed something of particular interest. All of the modules in my car communicate via Daimler Chrysler's "PCI" interface which the service manual says is based off of the J1850 VPWM standard (confirmed by the OBD-II (DLC) connector pinout: Pins 2, 4, 5, 16). The service manual also showed the PCI wire connecting to a pin on the ODB-II port which according to Elm's site is the data pin for ODB-II. Could I tap into this PCI bus using the Elm322 RS-232 interpreter and potentially write data to it? The factory radio controls the satellite receiver using this same bus. If I could tap into it I could change the satellite channel from my PC (and maybe even get song information). I was just curious if:

A: The Elm322 supports writing proprietary manufacturer specific codes (such as satellite radio channels)

B: All of these "PCI" buses in the car are connected to each other (all of the components are connected in a daisy chain fashion)

C: I can actually access the main "PCI" bus from the OBD-II "PCI" wire.

Some useful information:

Quote:

The DaimlerChrysler Programmable Communication
Interface (PCI) data bus system is a single wire
multiplex system used for vehicle communications on
many DaimlerChrysler Corporation vehicles. Multiplexing
is a system that enables the transmission of
several messages over a single channel or circuit. All
DaimlerChrysler vehicles use this principle for communication
between various microprocessor-based
electronic control modules. The PCI data bus exceeds
the Society of Automotive Engineers (SAE) J1850
Standard for Class B Multiplexing.

Quote:

The Data Link Connector (DLC) is an industry standard
16-way connector that permits the connection
of a diagnostic scan tool to the Programmable
Communications Interface (PCI) data bus for interfacing
with, configuring, and retrieving Diagnostic
Trouble Code (DTC) data from the electronic modules
that reside on the data bus network within the vehicle.

Sorry for so many questions, but this could be an extremely cool project; almost every function in the car is controlled by messages sent across this bus.

unixxx · 02-16-2006, 04:10 PM

It seems that my vehicle's PCI bus extends the J1979 message standard (the J1979 standard has a 3 byte message header and has no in-frame response bytes):

Messages Header (1-3 bytes)
Data Bytes (multiple bytes)
Cyclic Redundancy Check (1 byte)
In-Frame Response (multiple bytes)

CTDHokie · 08-08-2006, 10:17 AM

Have you had any luck with this, sounds interesting.

unixxx · 08-08-2006, 12:25 PM

I've built half of the interface, but have been too busy with other things lately. I'll be back on it in a little while.

szpigun · 08-10-2006, 09:51 AM

hi, where i can get a ELM PRODUCT in USA?

unixxx · 08-10-2006, 10:34 AM

You guys have sparked my interest again. I ordered mine from Canada and it got here within a week. Shipping was less than $10.00. I got the best version they make (it's compatible with three different car interfaces) and it cost about $30.00.

mgswed · 02-23-2007, 05:33 PM

Quote: Originally Posted by unixxx

I was checking out the service manual for my 05 Jeep Liberty to figure out how to control my factory Sirius satellite radio without buying the Sir-Alp1. The manual showed something of particular interest. All of the modules in my car communicate via Daimler Chrysler's "PCI" interface which the service manual says is based off of the J1850 VPWM standard (confirmed by the OBD-II (DLC) connector pinout: Pins 2, 4, 5, 16). The service manual also showed the PCI wire connecting to a pin on the ODB-II port which according to Elm's site is the data pin for ODB-II. Could I tap into this PCI bus using the Elm322 RS-232 interpreter and potentially write data to it? The factory radio controls the satellite receiver using this same bus. If I could tap into it I could change the satellite channel from my PC (and maybe even get song information). I was just curious if:

A: The Elm322 supports writing proprietary manufacturer specific codes (such as satellite radio channels)

B: All of these "PCI" buses in the car are connected to each other (all of the components are connected in a daisy chain fashion)

C: I can actually access the main "PCI" bus from the OBD-II "PCI" wire.

Some useful information:

Sorry for so many questions, but this could be an extremely cool project; almost every function in the car is controlled by messages sent across this bus.

unixxx, do you have a wiring diagram on how you plan to use the elm322. All I can find are big circuits and i would just like to convert the OBDII signal to rs232. Thanks, -MG

chewwtoy · 03-04-2007, 07:05 PM

It's important to note that not everything can be controlled by way of the vehicle bus. The software running on the device that you are trying to control has to support control over the vehicle bus (in this case the PCI bus). So even if you can transmit messages on the bus you have to know which ones to send and what data you need to send with it. Its a difficult task that many businesses who products rely on this type of reverse engineering spend months doing and don't always get what they want. So be prepared for a long a difficult road.

To get you started you should find out how to control modules using transmit messages. There are two types of messages on a vehicle bus: Normal Messages (messages that are transmitted between ECUs) and Diagnostic Messages (messages that use a high level protocol to get information or control an ECU). To control your radio you may need to use a combination of both. To find out which method will work, you must connect your tool to the ODB II connector and press buttons on the radio and try to find ** IF ** there is a message that is sent out with the status of the radio. If you are unable to find one, then you will need to use a diagnostic request to control the radio. Now you have to start studying. You need to find out how to properly format a diagnostic request to control the ECU. There is a service (or mode) that is designated for device control. Once you know how the ID and service of the message you must find out which sub function and data which is typically 3 bytes of data. Thus you need to go through 256 * 256 * 256 possible combinations of request!! That's why it may take some time to find out how to do it and in the end the ECU may not support controlling it via diagnostics.