RoninTT

I might be wrong but here goes:

The CAN bus is basically 2 wires(a twisted pair, in order to keep EM noise down). They are a differential pair so that one is the + and one is - (this also keeps a lot of noise out of the system). EVERYTHING that uses the CAN bus is sharing these two wires. This is why it's extremely difficult to just hack the cluster. If you hook into it's CAN connection, you are really hooked into the ENTIRE car, power window controllers, climate control, engine management, etc... Also, I believe the cluster might be requesting data from the ECU, which makes this all that more difficult. I might be wrong on that point but it's a *potential* problem. Information flows on the bus in the form of packets, which are just streams of bits. A programmable CAN controller can be purchased from Microchip for about 5 bucks that filters out the CAN packets you tell it to, and outputs just the data (no packet envelope or anything) via a +5v serial Tx line. It also has a serial Rx line that it reads, and then transmits the data out onto the CAN bus. I've used PIC microcontrollers hooked up to an RS232 level translator, hooked up to a serial port on a desktop running a terminal. You can easily send and recieve messages using the computer via this method.

Now, if I wanted to program the display to show, say boost, I would first need to get the boost data from the CAN bus. This would most likely be in the form of a request to the ECU for boost and then catching the boost packet as it gets sent across the bus (I think CAN controllers use filters of some sort instead of normal address decoding logic, but that doesn't change anything). You need to know how to request the information and then grab it when it gets sent. You can get around all this by using a stand-alone boost sensor.

The hardest thing to do is display the information. The most non-invasive way I've come up with is to program some sort of packet generating hardware that would go between the CAN and the cluster. If you knew which packets the cluster is capable of using, you could place whatever data you wanted into one of those packets and send that to the cluster via an isolated CAN bus, thus tricking the display into thinking it is displaying what it should be. It needs to be isolated so you can gate which packets from ECU make it to the cluster (switching between outside temp and oil temp, letting the coolant level warning make it to the display). Also, you don't want to be transmitting onto the car's CAN. If the cluster needs to be able to send requests back to the ECU, you can re-transmit them from the isolated CAN to the car's CAN.

Of course you could always hack the display itself but, like I said earlier, the company who manufactures the clusters wouldn't give me any info on the display. I don't particularly want to sit and try to figure out how to address each pixel in the display. I'd put in a new display before I'd do that.

What was the original question again? :-)

RoninTT

Thanks for the CD player head unit info, that's what I wasn't sure of.

Uncle Silvio

I have actually had a stand alone CAN system running with just 2 nodes using Microchip parts. As far as the addressing goes, I think each node has its own address that is transmitted with each packet. This is done because certain nodes have a higher priority than others(like airbag vs. window controls). Most CAN transceivers have address filters like you said that filter out the packets that are not needed by the given node. I could be wrong but I am just shooting off at the mouth. Let me know if you plan on doing anything with this. I don't have a scope at my house right now so I can't do anything. I might get one in the spring and then maybe. ;-)

RoninTT

with a functional display but haven't had much luck. I always thought that the ODBII port was CAN and I figured I would just plug in there but now I know that's not the case. I don't really want to have to take my car appart or hack into the wiring on it to get to the CAN bus so I'll need to come up with another way of testing. We should be able to test this stuff on a computer running a terminal emulator since the Microchip controller can output a standard serial datastream (assuming an RS232 level translator is used). Hopefully the bits can be dumped to the screen and no scope will be neccessary. As of now, the weather's too damn cold to be sitting in my car in the evening, hacking away. Unless I can think of a good benchtop method for experimenting, this project will have to wait for spring or summer.

If you wanna collaborate, send me an email...

lombardo@engineer.com

My name's Dave.

Uncle Silvio

I'll keep your email handy. :-)