Hi all, new to these forums. Hoping i can get some answers! This is more or less my first look into auto electrical systems so I’m still learning a lot.

N.b. My car is a 2004 Honda Accord Euro. I understand there may be minor differences compared to the TSX, so figured I’d mention just in case.

I’ve been toying with the idea of creating a custom gauge cluster for my car. In my mind, this would involve gutting an existing gauge cluster and fitting a suitable LCD display. This display would be controlled by either a Raspberry Pi or Arduino, which reads the relevant data from the connector that would have connected to the OEM cluster.

I have two main concerns about this. First is the difficulty of reading the data. Are the wiring, data, and protocols for this well understood? E.g. Is there literature from Honda regarding this? Failing that, does anyone here have an idea of how difficult it would be to interpret the data? E.g. very unusual encoding?

My second concern is how this might impact other systems in the car. My first thought was that it appears to simply display information to the driver, but I suppose it may be more complicated than that. Is it known whether other systems in the car rely on the gauge cluster?

Any tips or advice on this would be greatly appreciated. Thanks!

 

late model vehicles (2008 and newer) will have CAN BUS communication which is what it sounds like you're imagining. I am relatively certain that even the euro spec for 2004 in your case would not have CAN BUS.

A factory service manual will have most of the info you need to put together a list of the I/O you'll need to incorporate in your design.

I'm guessing an Arduino/microcontroller dev board is going to be the best fit here. so long as you plan on simple graphics on the display.

it may be feasible to use the existing PCB in the OE cluster as a base to add your modules so some of it's benefits are retained.

 

TSX is in fact CAN for the gauge cluster. Only the fuel gauge is still analog.

Honda does not provide any documentation on the CAN signals.

The gauge cluster is also the CAN gateway between F CAN and B CAN.

 

Good info, thanks for the correction.

OP: in that case you'll want to look into "CAN BUS sniffing" to start decoding the signals to and from the stock cluster.

 

Decoding and reverse engineering the check sums on the data packets if you want the rest of the CAN modules to believe you.

It's a long road. Completely possible and a fun project. Opens the door to more modern vehicles. Same stuff, just slightly different.

 

Thanks all, that sounds promising but it will assuredly be a long road for me. I’ve been reading up on CAN and have some likely naive questions.

From what I understand, all nodes on a CAN system receive all messages from other nodes, even if it is not relevant to it - it will simply ignore irrelevant messages, and only respond to messages that are relevant to it.

I’ve also seen that this is communicated over two wires, a high and low line from which the voltage difference represents data bits.

First, does the above sound right? If so, why are so many wires required for the cluster connector?

See below frame capture from a video of removing a similar Honda Accord cluster

​​​​​​​


There are ~30 wires here. With my understanding of CAN as described above, this seems excessive, so I’m lead to believe I’m misunderstanding something fundamentally here.

I would think that a pair of high and low CAN lines would be able to handle all the information that are fed to the cluster, and the cluster simply needs to filter out different message types to determine how to operate the physical gauges and lights accordingly. 12V wire as well, and the analog lines for the fuel as mentioned in this thread, this still falls well under ~30 wires.

So what am i missing?

 

You are correct about the CAN.

This is Honda's very first attempt at CAN if I am not mistaken. So it's not 100% all things displayed are CAN.

The gauge cluster also does more than a single CAN network. It is also the dimmer for the interior lights, it has connections to the blinkers, doors, seat belts, and immobilizer system.

To replace the TSX cluster will be a much more challenging task as it's both old systems and new systems.

 

I see, I guess it acting as the F-CAN and B-CAN gateway means that other systems rely on the OEM cluster, or something that can reproduce its behaviour.

In that case, I’m thinking that it may be simpler to leave the original circuit board in place, and instead read the information I need from the board’s outputs. I.e. taking the gauge and LED voltages from the board and using them as inputs for the microcontroller.

I’ll have to take apart a gauge cluster to see what kind of space I’ll actually have to do this.

 

Why not pull the data direct from CAN?

There is far more data available than what the cluster displays.

 

I’m mainly deterred by the complexity of it, but I’m still looking into this.

Do we know how compliant the early Honda implementation of CAN is with the modern standard? E.g. would off the shelf CAN transceivers and shields for Arduino and RPi work?

Is there some documentation for the message IDs that Honda used in their implementation? I’m not experienced with reading raw data streams, so if I have to try to decipher proprietary messages myself, this endeavour becomes monumentally more difficult for me.

Even trying to find which pins on the cluster connector or terminals on the PCB carry CAN high and low is proving difficult for me. E.g. this pinout confusingly does not show any CAN pins, but a number of pins for “gauges and indicators”:



I have a copy of the electronic service manual, but it doesn’t have detailed schematics for the gauge control module that show anything about its CAN system.

I would love to be able to read the CAN data directly since there’s a lot more information, and would be a lot less crude than reading the varying output voltages for the motors that control the needles. If it turns out to be non viable though, reading the voltages is unfortunately my only other option.

 

CAN protocol is industry standard. The data in the messages is not industry standard. Your standard CAN interfaces will be able to see the data and send data.

There is no or very little public documentation of the CAN messages and checksums for this vehicle.

This whole project is going to be one for you to reverse engineer.

The CAN network is X80 and X70 in your pin out.

 

https://honda-tech.com/forums/acura-...-help-3365726/

 

Thanks Ryan, I’m going to try to reverse engineer it and see how I go. I’ve sourced a spare cluster (going to keep my original untouched just in case), and have other parts coming in the mail. Will definitely share my progress, really hoping this little project turns out as I’m imagining!

Can I ask how you know X70 and X80 is CAN H/L? Was this through prior trial and error on your part or is this documented somewhere?

Edit: Found this circuit diagram for the charging system of 2003 Accord L4 which confirms it:

 

I have printed copies of the factory service manual and factory electrical troubleshooting manual.
.

 

Have gotten around to hooking up a Raspberry Pi 4B and a MCP2515 CAN HAT up to those pins on the cluster. Unfortunately I'm not yet able to receive the CAN messages through the candump utility yet. Not sure what's up with that. Have set bitrate to 500000, and tried disabling/enabling the 120 ohm resistor on the CAN HAT (it's toggled by moving a jumper between one of two positions). This CAN HAT also allows to select logic voltage between 3V3 and 5V - the Pi couldn't initialize the interface when set to 5V, though my understanding is that it doesn't really matter whether it's set to 5V or 3V3 since it's a differential signal.

Will keep fiddling around, double-checking connections and what not.

 

Okay got candump to work! Looks like I had it wired up wrong. The pins in the pinout diagram I shared above are numbered. The cluster's PCB also has numbers printed on the board for this connector. The numbers on the pinout and on the PCB do not correspond to each other. The colours described on the pinout (for most of the wires anyway, including CANH and CANL) are accurate, with CANH and CANL being slightly thicker than the other wires for whatever reason.

Time to sink in some unknown number of hours into deciphering Hondanese.

 

Wow this is brilliant, truly standing on the shoulders of giants. Thank you and thanks to Euro-R_Spec_TSX. I'm able to read RPM and speed through CAN now!

During a short log, the below identifiers came up. 12C and 0C8 are certainly the RPM and speed as per your link.

• 064
• 090
• 0A6
• 0C8
• 0D4
• 12C
• 188
• 1C0
• 1F4
• 224

You mentioned that fuel is analog. Do we know what else we can and cannot expect to be represented in CAN? I see in the link that 064 are for some of the indicators, how about other indicators and engine temp?

 

Is B-CAN in this car really CANBUS? It seems to consist of only a single wire which seems to preclude it from being defined as such. Is it still digital data being sent through, but with the signal difference being between that wire and ground?

 

B CAN might be UART. Never looked into it. Wasn't needed for my projects.

 

For the fuel level, am I right in understanding that the fuel sending unit is wired directly to the gauge cluster? If so, presumably I should be able to use a multimeter to read resistance across specific pins on the gauge cluster connector to get values for the fuel level?
I've tried doing this periodically over the past few weeks at different fuel levels but haven't been able to reliably do so, so just wanted confirmation if I'm on the right track.

 

Yes, that is correct. Fuel gauge is analog directly to the gauges.

There is a spec out there for the ohms at empty and full. I know it's in the ETM. Probably also in the service manual.