E36 Cluster EEPROM/Coding Plug
 

Hey guys,

Just checking in really quick. A question for the experts...

My question is - does anyone know how all the information that is coded on the coding plug behind the cluster?

Situation is:
My gauge cluster is showing the wrong RPM, as per the norm when it comes to engine swaps.

I got several M3 gauge clusters with coding plugs, and I also have pigtails for the cluster, for testing things out or connecting to it.

My 318ti has the S52 motor from a 1999 convertible, its got the Motronic MS41.1 DME w. EWS delete.

My car has ~162k miles on it right now. One of the M3 clusters has ~78k miles, the other - ~138k. I want to maintain real mileage on whatever cluster ends up being installed in there.

I want to know if I can take my 318ti plug, put it in an E36 M3 cluster and 'align' it so that the mileage form my coding plug would be coded to the cluster - test mode 9, I believe.

However, I am afraid that if the coding plug contains engine information, the 318ti coding plug would thereby adjust the way the cluster interprets the RPM information from the DME and it will once again start being read incorrectly.

Does anyone know how the EEPROM for the coding plug store the information? Or if the aforementioned method would just make it work?

I originally wanted to use a microcontroller to alter the physical signal from the crownwheel, but once I knew how to make that solution work, I wanted to implement a more elegant solution by keeping it all OEM.

I have been through and through trying to get the damn PROGMAN/SSS/DIS to work to no avail - I got INPA and EDIABAS to connect and interact with the car via the FTDI OBDII adapter, but I couldnt get the rest of that virtual machine crap sorted out to the point of it working, and even when I got DIS to run, and saw all of the coding options, I didnt see any for the gauge cluster coding, so I figured, if I could just swap the coding plug and it would work, that would be ideal, or perhaps someone could think of another way of doing it, in which case, please do not hesitate to mention it here! :)

Thanks a ton!


GAUGE CLUSTER INFO (P.S.)
The coding plug behind the gauge cluster is an 8-pin EEPROM chip P/N 93C46. It communicating to the gauge cluster via UART or something along those lines.

The gauge cluster itself is very straightforward. Most of the bulbs switch on directly. The detailed explanation of all the features can be found here: http://www.bmwmotorsports.org/BMW_do...1driverino.pdf on pages 6-20

The parts you cant really find anywhere I found through interfacing the gauge cluster to a microcontroller - it is that the speedo and the tach are controlled by a 50% duty cycle square wave signal. The M3 cluster tach can receive the signal from 35-400Hz, which linearly represent about 600-8000RPM. Signals below 35Hz end up screwing with the gauge big time, and I havent tried much higher frequency signals, but that's the baseline.

The Speedo is also controlled by a similar 50% duty cycle square wave, but the frequencies end up being about 33-350Hz, which linearly represent 0-160MPH.

I have posted information about both those signals, often and on, over the years, on various forums. If you need more precise information, let me know. The vehicle speed signal should not be an issue, as all E36 clusters expect the same signal.

Thanks john! I think I may have used your very data to connect an arduino to the cluster! :) I looked in a lot of different boards for that info.

My biggest question was - how is the data stored on the coding plug, and whether it keeps the number of cylinders in the car. So that if I could just take the coding plug from my car and align the miles to an m3 cluster, whether that would work ok with it,or not.

Thanks again! :)
Artem

Just went through a bunch of your and others' posts on this matter, I think I will try and swap the coding plug to an m3 tomorrow and see if I could match the miles on the cluster with it. Based on some of the things people said they were going to do just that, but I could never know whether it worked or not I the end, as no results were ever posted :-/

I will post the findings tomorrow if it makes everything work or not! :)

Yeah, well, some are not very good about keeping old posts. One, which I have pretty much given up on, I can only view the last 250 of my almost 3000 posts. You might say they are losers. Literally. :tongue:

What is stored is the central coding key (ZCS), a long string of bits with the specifics of the car. I have not read of anyone who has decoded it. The mileage is kept elsewhere in the EEPROM and is straightforward to change if you know the address.

If you have the patience, you might consider feeding a high vehicle speed signal into a cluster and clocking up the miles. At 155 mph, you would only need about 6 and 22 days to advance your two M3 clusters. I bet you can clock them even faster: for a few days, I had a bad speed sensor I could excite to wrap the needle on my cluster so that it was pointing straight down. I did not realize it could go that far. :cool:

Hahaha, good point on advancing them :) I did notice that the mileage went up when I played around with the speedometer!

The biggest thing I was hoping to avoid is that red mileage mismatch dot which appears when the ZCS/mileage isn't aligned right (?) I think... So I was wondering if it would appear if I was off by a fraction of a mile (since I would be able to stop the climb once the mileage reads the exact number xxx,xxx - but somewhere else I would imagine the cluster keeps track of the other digits... Or does it not really matter at that point?

I'm just hoping to avoid making an irreversible move that would throw a red dot or render something else unusable.

I would not think you would have any trouble. The cluster compares the distance stored in each of the two EEPROMS, one on the main PCB and the other in the code plug, and displays the red dot if they differ. You would be changing both so they should not.

You raise a good point. If I were doing this, I would probably cycle the switched-power input on and off, say, once an hour, to periodically update the two EEPROMs. You might excite a software bug or a plausibility check if you try to advance the stored distances in one big step.

Hmm, alright - I will try on one of the clusters, to use my original coding plug, run the cluster test and align the miles, and if that screws up the tach,I would just do the mileage advance with the second cluster.

I think I would just time it and send it the signal continuously for a period of time, to climb about 500 miles, taking a break afterwards, and loop it over, based on exactly how long it would take at maximum speed that it would take.

I'll see if it's possible to send it a higher value and just run it as-is, stopping maybe around 160k, to slow down and get it to the exact number slowly.

Thanks again! I'll try to post something here tomorrow or the day after :)

You are welcome.

Since everything here is digital, you might as well count off the pulses as you send them to the cluster until it has received

4712 x 1.6093 x {however many miles you want to add}

You could cycle the switched power input, say, every 2 million pulses or

2 000 000 / 4712 / 1.6093 = 264 miles

EDIT: To play it safe, I would not pulse the input at more than roughly 330 hz – the equivalent of 250 km/h (155 mph).