CAN bus to CCD bus Protocol Translator(Chrysler PCM Simulator)

[Alexia]

I am working on a new project lately to be able to drop a Haltech Elite ECU into my 1997 based MJ without losing the stock gauges or other CCD bus operated modules. This is accomplished by translating CAN bus messages from the Haltech into CCD bus messages simulating the stock Chrysler PCM. It removes the need to keep the stock PCM in place to run any systems and removes wiring/sensor complexity from running two engine computers. As well, this would simplify any CAN bus controlled engine swap, such as a GM V8, by only needing to plug in a little box between the data lines to retain the stock gauge cluster.

Current implementation status:

• Chrysler CCD bus Packet IDs - Only missing fuel level. Everything else works including odometer/tripometer incrementing.
• Haltech CAN - In progress - Haltech is kind enough to provide full documentation to anyone that asks. Needs quality assurance testing and validation on my MJ when the wiring is finished.
• GM CAN(GMLAN) - I have a copy of the GMLan Bible. I would need to obtain an GM ECU or borrow a GM swapped vehicle for a few weeks. Otherwise implementing GM support will be as easy as Haltech support.

Example of controlling the gauge cluster over USB.



Testing how fast the gauge cluster can respond to data packets. The needles visibly stop moving when hitting the processing limits of the gauge cluster's microcontroller. The fastest I can get the gauge cluster to respond is 20hz or one update every 50ms. This might actually be faster than how fast the stock PCM updates.

[gradon]

Awesome!
Back when I dyno'd 193whp and 231wtq, the shop wanted me to buy the Haltech standalone ecu because the stock pcm was lean. I love watching MCM with the Haltech guru.


Sent from my iPhone using Tapatalk

[Alexia]

Originally Posted by gradon

Awesome!
Back when I dyno'd 193whp and 231wtq, the shop wanted me to buy the Haltech standalone ecu because the stock pcm was lean. I love watching MCM with the Haltech guru.


Sent from my iPhone using Tapatalk

That is part of the problem I having now and why I am doing all this to switch. The stock PCM will be fine, then lean out, and then suddenly go balls to the wall dumping fuel in trying to correct it. Waiting for one of the two tuners in the USA who know how to flash JTEC PCMs, plus the cost, is not worth it in comparison to the cost and flexibility of an aftermarket ECU.

[xeroOTG]

Do you have any technical details? I have been working on something like this for a TDI swap, and there's also a thread on thespeedfreaks.net that I've been following. Id love to help, as this is something I've been working on in the background for almost a year now. You've made it further than I have, seeing as how you have moving needles.

[Alexia]

Originally Posted by xeroOTG

Do you have any technical details? I have been working on something like this for a TDI swap, and there's also a thread on thespeedfreaks.net that I've been following. Id love to help, as this is something I've been working on in the background for almost a year now. You've made it further than I have, seeing as how you have moving needles.

Repository is right here:
https://github.com/Alexia/CAN-CCD_bus

I have an unpushed branch with more Haltech CAN bus work on my laptop, but I am waiting to push it until I have it tested on my MJ. Which is waiting for my slush fund to recover to make a part purchase since I am about to drop several thousand in repairs on my LJ.

[xeroOTG]

How are you driving the CCD bus? Are you using any of the older SPI to CCD
Intersil chips or driving it directly with the teensy? Ill pull your code when I get home, it looks great!

[xeroOTG]

Oh, you were looking for fuel level? The link I dropped earlier has documented the fuel CCD address for a Durango.

// Fuel ID 37 [HEX-25] (ID-DATA-CRC)
// DATA range 1 ~ 253 + Error handling.

[Alexia]

Originally Posted by xeroOTG

How are you driving the CCD bus? Are you using any of the older SPI to CCD
Intersil chips or driving it directly with the teensy? Ill pull your code when I get home, it looks great!

Teensy is handling the serial level logic to a CAN bus transceiver. Yes, the CAN bus transceiver is being used to drive the CCD bus.

Originally Posted by xeroOTG

Oh, you were looking for fuel level? The link I dropped earlier has documented the fuel CCD address for a Durango.

// Fuel ID 37 [HEX-25] (ID-DATA-CRC)
// DATA range 1 ~ 253 + Error handling.

I have been trying 0x25, but none of the values I looped through have made the XJ gauge cluster respond to it yet.

[xeroOTG]

I finally got home from work and got a chance to clone your repo. I'm looking at CCD::doUpdateLights() and I noticed you set the airbag status. In my engine swap, I was planning on retaining all of the CCD modules (OHC, airbag, gauges) so I am more concerned with emulating the messages provided by the ECU than anything else. Since I plan on retaining the airbag controller, I would be concerned about leaving it on the CCD bus if the address used for airbag status is shared with your code. Is this message provided by the ECU or by the airbag controller?

Either way, I like what you have here. I was going the approach of using an Intersil CCD chip over SPI. Your approach of using a CAN transceiver and handling the rest in code seems to actually involve fewer IOs, less interrupts, and has a lower component count. Do you think there is potential for bidirectional communication with your approach of using a CAN transceiver as the physical interface?

Do you have anything you would like help with on this project?

[Alexia]

Originally Posted by xeroOTG

I finally got home from work and got a chance to clone your repo. I'm looking at CCD::doUpdateLights() and I noticed you set the airbag status. In my engine swap, I was planning on retaining all of the CCD modules (OHC, airbag, gauges) so I am more concerned with emulating the messages provided by the ECU than anything else. Since I plan on retaining the airbag controller, I woulc be concerned about leaving it on the CCD bus if the address used for airbag status is shared with your code. Is this message provided by the ECU or by the airbag controller?

Either way, I like what you have here. I was going the approach of using an Intersil CCD chip over SPI. Your approach of using a CAN transceiver and handling the rest in code seems to actually involve fewer IOs, less interrupts, and has a lower component count. Do you think there is potential for bidirectional communication with your approach of using a CAN transceiver as the physical interface?

Do you have anything you would like help with on this project?

Setting/changing the air bag light status is purely optional. My eventual plan is to have a build system where people type in their platform code, what modules they are retaining, and other options. So if someone selects "no air bag module" it would compile the firmware to turn off the air bag light so they don't see it turned on in the dash.

The CAN transceiver I am using does not work to receive on the CCD bus. It applies power the CCD bus, but CCD is designed to be powered from one source. In the case of the XJ the power source is the gauge cluster.

I actually want to rework the code slightly to use a middleware style so that messages broadcasted on one bus are reflected to any bus. The first iteration will be purely one way CAN to CCD.

[Alexia]

Originally Posted by xeroOTG

Oh, you were looking for fuel level? The link I dropped earlier has documented the fuel CCD address for a Durango.

// Fuel ID 37 [HEX-25] (ID-DATA-CRC)
// DATA range 1 ~ 253 + Error handling.

BOOOOOOOOOOOOOOOYAH THAT WORKS! Every time I tested 0x25 for a packet ID I had been using 0x00 or 0xFF. Which is empty and open circuit which displays empty. However, whenever testing other values I would start with 0x00 then set it higher. Since the XJ gauge cluster buffers that value automatically it can take five to ten minutes to reach that new point. Patience in testing never came to mind in that case.

[xeroOTG]

Originally Posted by Alexia

BOOOOOOOOOOOOOOOYAH THAT WORKS! Every time I tested 0x25 for a packet ID I had been using 0x00 or 0xFF. Which is empty and open circuit which displays empty. However, whenever testing other values I would start with 0x00 then set it higher. Since the XJ gauge cluster buffers that value automatically it can take five to ten minutes to reach that new point. Patience in testing never came to mind in that case.

That's great news! The same post indicated that the low fuel light was a fixed range of the fuel level (0x35 - 0x01), not programmable. When you indicate a low level, does the fuel light Illuminate?

[Alexia]

Originally Posted by xeroOTG

That's great news! The same post indicated that the low fuel light was a fixed range of the fuel level (0x35 - 0x01), not programmable. When you indicate a low level, does the fuel light Illuminate?

I did not test the exact values, but the light does turn on automatically after a ten second delay in the expected low fuel range.

[zluster]

VERY cool.

I have a couple of aftermarket ecus and access to some others that use the same form factor as the stock ECU......but are fully programmable and configurable....and talk CANBUS.



128pin version:




Now thats great for using those, but you come onto a good use as well, the diesel KJ ecu runs on canbus, so to spit out data for the CCD bus is perfect.

Alternatively I could use TJ PCI cluster.....I think one of these should work.

[xeroOTG]

Originally Posted by Alexia

The CAN transceiver I am using does not work to receive on the CCD bus.

So I've been reading datasheets for the MCP2551 and the SN65HVD230, both look like they are capable of providing a physical interface capable of receiving on a CCD bus. When I look at the architecture diagram of the Intersil CPD68HC68S1, the CAN differential receiver implements similar function, minus arbitration detection, collision detection and idle detection. Outside of your published code, have you attempted to monitor the RxD pin while transmitting? I have a SN65HVD230 coming snail mail, so I cannot test this theory for myself.

I think the function of the Intersil could be implemented in software, bringing duplex communication into your project. Arbitration detection, collision detection and idle detection all are well documented in the CPD68HC68S1 datasheet, I just don't think I am up to the task of implementing them.