CCD-CAN Translator

Chrysler's CCD (Chrysler Collision Detection) protocol is a proprietary communication protocol used by Chrysler vehicles to communicate between various electronic modules and control units in the car. It is an evolution of the earlier Chrysler Collision Detection Bus (CCDB) protocol. The CCD protocol is a two-wire serial communication protocol that uses a twisted pair of wires to transmit data between modules. It operates at a speed of 9600 bits per second (baud rate) and uses a master-slave communication structure, where one module serves as the master and the other modules are slaves. The CCD protocol uses a message-based communication system, where each message consists of a header, data payload, and a checksum. The header contains information about the message type, the destination module, and the length of the data payload. The data payload contains the actual data being transmitted, such as sensor readings or control signals. One of the main advantages of the CCD protocol is its ability to detect and report faults and errors in the communication system. Each module is constantly monitoring the communication bus, and if it detects an error, it will report the error to the master module. This allows for faster diagnosis and repair of faults in the system. The CCD protocol is used in a wide range of Chrysler vehicles, including cars, trucks, and SUVs. It is used to control various systems in the vehicle, including the engine, transmission, brakes, airbag system, and other electronic control modules.

Chrysler CCD and CANBUS (Controller Area Network Bus) are both communication protocols used in vehicles to enable communication between different electronic control units (ECUs) in the vehicle. However, there are some key differences between the two protocols.

Speed: CANBUS is a faster communication protocol compared to Chrysler CCD. CANBUS can transmit data at speeds up to 1Mbps, while Chrysler CCD operates at a speed of 9600 bits per second.

Message structure: CANBUS uses a message-based communication structure, where each message consists of an identifier, data payload, and other control bits. In contrast, Chrysler CCD uses a master-slave communication structure with a header, data payload, and checksum.

Fault tolerance: CANBUS is designed with fault tolerance in mind, which means it can continue to operate even if one or more nodes in the network fail. On the other hand, Chrysler CCD is less fault-tolerant and can experience communication errors if any module on the bus fails.

Flexibility: CANBUS is a more flexible protocol, as it allows for various configurations and topologies. It also supports multiple message types and a wide range of data rates. Chrysler CCD is a proprietary protocol designed specifically for Chrysler vehicles and is not as flexible.

Adoption: CANBUS is a more widely adopted communication protocol across different automotive manufacturers and applications, while Chrysler CCD is only used by Chrysler vehicles.

In summary, while both Chrysler CCD and CANBUS are communication protocols used in vehicles, CANBUS is a faster, more flexible, and more fault-tolerant protocol that is more widely adopted across different automotive manufacturers and applications.

The translator consists of three main components, the CAN controller/transceiver module, the CCD transciever, and an Arduino Mega 2560 based microcontroller. The CAN controller is the MCP2515 canbus module available from a variety of sellers, usually equipped with a TJA1050 transceiver onboard. The CCD transciever can be found as an either an original chip (CDP68HC68S1E) or as a completely re-engineered board from Daniel Laszlo available here. The Arduino Mega 2560 is available from many sources as a full size development board or a small form factor version. Using a mega 2560 is necessary due to the limitations of the CCD library only supporting the 2560 processor.

The tach can display up to ~8500 rpm before it returns back to zero, and the odometer incrementing is not tied to the speedometer, it’s a separate byte of data sent from the PCM. The decoding of the tach, speedo, fuel and battery voltage has been figured out in the past, but oil pressure and coolant temp was a bit tricky to decipher. I do not know what units they are supposed to be transmitted in, but I was able to graph my inputs vs the gauge’s values and come up with an absurd function to convert them to psi and °F respectively, with acceptable accuracy.

A thought that I’ve had which was also suggested by John Sharkey (@johnsharkey) was to remap some of the gauges to another data channel, like making the battery gauge display boost, or maybe the oil pressure gauge display AFR. It would be as simple as changing some addresses and scaling in the translator program and adding an overlay to the instrument cluster. The only obstacle I see right now, is that these small gauges react slower to input changes than the tach or speedo does. I’m not sure there is a way around this other than digging into the circuitry in the instrument cluster itself, but it is worthy of further thought.

I’m not the first person to crack the CCD code. There have been a number of people who have worked on decoding this protocol for their own reasons, but information is sparse, and projects are often left unfinished and forgotten. Daniel Laszlo has been an awesome source of both hardware and information, and information on his projects can be found here. If you would like to become a contributor on the project feel free to shoot me an email at AnthonyR@marstech.co.