pcmhacking.net

Hi guys,
I'm in the process of repairing a dash cluster manufactured by Kansei to suit a 1997 Nissan Navara D22 2.4L Petrol. These dash clusters were very common and used across a variety of Japanese vehicles, nissan honda etc. I've been doing a lot of digging online and it seems failure is very common, but repair can also be very easy.
The cause of failure seems to be because the PCB is pretty well fully enclosed and not in anyway cooled. Over time and heat cycles they develop micro cracks / cold solder joints. The PCB is single sided and uses a lot of through hole components. I believe if it was double sided the extra solder through the PCB hole would probably reduce the failure rate. Once they have developed the first problem they corrupt the contents of the serial EEPROM (93C46 in a DIP 8 package). Once they have failed they do all sorts of weird things. Needles get stuck, fuel and temp gauges go to above full or below empty at times, odometer is lost and reads 999,999km, or they simply don't work at all.
This makes them easy to fix as long as you have a good BIN file to flash back onto the EEPROM once you have re-soldered everything. Luckily there is plenty getting around online if you look hard enough.

Anyway back to the cluster I'm attempting to fix. I actually have 4 identical clusters supplied, all of which were faulty. They fail that often that they have tried 4 second hand clusters before I offered to try and fix one. The latest one they had all worked except the fuel gauge and speedo was intermittent. After re-soldering a couple I found one that mostly worked, except the temperature gauge shot up above hot from a couple of minutes after start until its almost at operating temp, and then returned to the normal position.

I pulled all the EEPROM's and read them. Looking at them all side by side its obvious to see what ones are corrupt and where they are corrupt. I also found a good working BIN file online and comparing that to them proved my thoughts. I've got enough information to repair the 2 bad bytes in this file and call it a day, but I've also found where I believe the odometer reading is stored and would like to change it back to what it should be if I can.

There is only 6 bytes that are consistently different between all 5 dumps I have, and they are all in the same location. Literally all other bytes are identical between the 4 Australian D22 dumps I have (except the few locations in them where it has been corrupted and gone to 0xFF). All the other bytes are also identical to the dump I found online, except another 6 bytes which are very slightly different (maybe one of the gauges has a different calibration for a different market or something?). The location also matches where I found someone saying it should be located on a Russian website (which was difficult to read at times with google translate). So I'm pretty confident I've narrowed down where its located, but I cant work out how to calculate it and crack the code. Here's what I have


Advertised online as 201,149km:
0x38 0x80 0xC7 0xF1 0x3F 0x80

There's 2 values here which I've seen and confirmed on the cluster with my own eyes, one is 360,082km and the other 318,704km. However I believe I may have mixed them up and cant confirm which is which:
0x3F 0xF0 0x07 0xF0 0xF8 0x81
0x00 0xF0 0x07 0xFE 0xC7 0x81

I've got this value which I haven't seen in a working cluster, but I believe is OK and not corrupt:
0xC0 0xF1 0x3F 0xFE 0xC7 0x81

And I've got his value which I know is definitely corrupt (shows 999,999km in cluster):
0xC7 0xFF 0x00 0x8E 0xFF 0xFF


I did read something about similar clusters having a "small counter" as well as the actual KM counter (the small counter counts up to one KM) which might be some of the bytes above. Other similar later model clusters I've found information about (may have been a 1999-2000? honda cluster) have the odometer value stored 3 times identically in 3 different locations, and the odometer value is 3 bytes long, but I'm confident these are the only 6 bytes it could be stored in this model cluster (the value might only be 3 of the bytes though).

Who's smarter than me who could point something out I'm missing, it's the first time I've done something like this and it would be great to fix it properly back to the correct mileage.

Cheers

Here was a helpful video I found on repairing them:
https://www.youtube.com/watch?v=X8I91AY0CFo

The Navara cluster I have is pretty well identical (it has a tacho and reads KM/h etc). The PCB definitely looks identical.

The 6 pin programming adaptor he sticks in the back goes through onto 6 pads on the PCB which are directly connected to the EEPROM and reset pin of the main IC. I haven't got his adaptor or software so I un-soldered the EEPROMs and used my TL866 to read them.

I've also attached a partial circuit diagram (comments are in russian) I found elsewhere online

Not much to add here sorry, but I have repaired some of these in the past up to the point of the corruption issue.

I wish this sort of info was around years ago.

I'm thinking that there's a market for selling these on ebay

I found the solution to the odometer value.
There's an old program Tachsoft v23.1 getting around if you search hard enough online. It calculates odometer hex values for all sorts of makes and models and shows where in the bin they are located. Tested it on the bench and it works. Values aren't spot on for whatever reason, probably something to do with how it is calculated, but they end up within a few KM and seems to always work (doesn't spit out 999,999km).
Apparently the algorithm is a common Denso one, and all 6 bytes are the odo value (not just 3 of them).

Now to completely assemble one of these clusters and put it back in the vehicle and see how it goes

I wouldn’t be surprised if one of the values is a checksum and if invalid displays 999,999km.