DIY: Z3 Non-M gauge cluster to Z3M S54 Conversion

[JBanzhaf]

Joel, you're the man! The files you sent me fixed my cluster! I ended up doing more stuff than I needed to but at least I now have an understanding of how the cluster works. I do have another request for you but let me first tell you what I did (I think it's an interesting story):

1. Opened up the cluster and reflashed the internal EEPROM with the file you gave me, but there was no change - still showing code_1 (at the time I didn't know that _1 meant coding plug and _2 meant internal EEPROM).
2. Also reflashed the coding plug with your dump and voila! It worked - the errors were gone and I could see 130k miles (with a tamper dot of course).
3. Ran test 16.1 to sync the mileages and the tamper dot was gone.
4. However, the "brake fluid" light was on even though my brake fluid level was fine (and it wasn't on before the reflash). Figured the coding was not right because the data came from another car (there is a coding setting about using an inverted signal from the brake fluid level sensor).
5. Opened up NCS Expert to recode and of course, it showed a different VIN stored in the instrument cluster. Using the ZCS/FA data from another ECU (the EWS), I tried coding the instrument cluster to factory settings, but that failed (my guess is it failed at the step where it writes the VIN). However, it seems that it did successfully write the coding or part of it, so now the cluster was showing EEP_2 (which at this point I'm guessing means that some checksum doesn't match).
6. Using the ZCS data from the cluster itself (which happened to have the exact same FA data as mine), tried coding to factory settings and that succeeded. The EEP_2 went away and the cluster was working again. I think (but don't remember for sure) that the "brake fluid" light went out at this point as well. But the VIN stored inside was still incorrect.
7. So I looked at the dump for the internal EEPROM and found that (the last 7 digits of) the VIN seem to be stored between bytes 0x84 and 0x89, so I copied those bytes from my original backup dump into the dump you provided and flashed to the EEPROM. When I plugged in the cluster, it was immediately showing EEP_2. But at that point I knew that that probably meant the coding (or some checksum thereof) was wrong, so I tried recoding again with the ZCS data from the other ECU (EWS) and this time it succeeded... and also got rid of the EEP_2 error and the "brake fluid" warning and the cluster started working fine. So far this was the full result I was looking for.
8. After all this I realized that maybe my original data in my internal EEPROM was fine and it's only the coding that was wrong, so to test this (and for the sake of keeping my original configuration) I reflashed the internal EEPROM from my original backup without any modifications. Unsurprisingly, this caused an EEP_2. But after recoding with NCS Expert, that error was gone and everything was working fine.
9. Surprisingly though, my mileage was NOT showing the tamper dot. My guess is that during the prior repair that was done to this cluster they set the mileage exactly to 130k (because that is believed to be the estimated current mileage), and this is exactly the same value that you set in the coding plug, hence no tamper dot. Or do you think it could be something else? Anyway, the result is that I have a perfectly-working cluster with the correct VIN and coding configuration.

So the moral of the story is I didn't need to open my cluster at all - I just needed to take out the coding plug and reflash it with your file and then just recode the cluster via the OBD connection.

And now my request: I'd like to switch the odometer display from miles to kilometers (I'm in Europe, but the car is imported from the US). I changed the coding to switch it to km and it did briefly show the value in km (209215) but after the coding was done (and regardless of how many times I restart the ignition after that), it started showing 130001 km... which is the value in miles, but shown as km (maybe off by 1 due to some rounding error because of back-and-forth conversion?). I read somewhere that the US/UK clusters store the raw value in miles. So how would one go about setting the correct mileage in kilometers? Would it just mean putting the value 209215 in the coding plug EEPROM and syncing via test 16.1? If so, could you please prepare a new dump for me with that value? Thanks in advance - I really appreciate your help!

Regards,
Todor

Todor,

I sent you another PM with some more information, as well as an updated coding plug dump for converting to KM. All E36 cluster coding plugs store their odometer mileage in a dimensionless hex value. When you code it to KM, it keeps the same value and switches the display to KM. The hex value for the coding plug is only accurate to plus or minus one mile, as part of the algorithm equation divides the value by 2. This is why it's displaying 130001. Also, the internal EEPROM file I sent you was coded using NCS Expert for regular E36 brake fluid level sensors, as they are different to Z3's. As 99% of these clusters have gone into S54 swapped E36's, I forgot about that difference. So I sent you a file that needed one coding change made. Glad you got that figured out.

Thanks,
Joel

[todor]

PM Sent

Joel, you're the man! The files you sent me fixed my cluster! I ended up doing more stuff than I needed to but at least I now have an understanding of how the cluster works. I do have another request for you but let me first tell you what I did (I think it's an interesting story):

1. Opened up the cluster and reflashed the internal EEPROM with the file you gave me, but there was no change - still showing code_1 (at the time I didn't know that _1 meant coding plug and _2 meant internal EEPROM).
2. Also reflashed the coding plug with your dump and voila! It worked - the errors were gone and I could see 130k miles (with a tamper dot of course).
3. Ran test 16.1 to sync the mileages and the tamper dot was gone.
4. However, the "brake fluid" light was on even though my brake fluid level was fine (and it wasn't on before the reflash). Figured the coding was not right because the data came from another car (there is a coding setting about using an inverted signal from the brake fluid level sensor).
5. Opened up NCS Expert to recode and of course, it showed a different VIN stored in the instrument cluster. Using the ZCS/FA data from another ECU (the EWS), I tried coding the instrument cluster to factory settings, but that failed (my guess is it failed at the step where it writes the VIN). However, it seems that it did successfully write the coding or part of it, so now the cluster was showing EEP_2 (which at this point I'm guessing means that some checksum doesn't match).
6. Using the ZCS data from the cluster itself (which happened to have the exact same FA data as mine), tried coding to factory settings and that succeeded. The EEP_2 went away and the cluster was working again. I think (but don't remember for sure) that the "brake fluid" light went out at this point as well. But the VIN stored inside was still incorrect.
7. So I looked at the dump for the internal EEPROM and found that (the last 7 digits of) the VIN seem to be stored between bytes 0x84 and 0x89, so I copied those bytes from my original backup dump into the dump you provided and flashed to the EEPROM. When I plugged in the cluster, it was immediately showing EEP_2. But at that point I knew that that probably meant the coding (or some checksum thereof) was wrong, so I tried recoding again with the ZCS data from the other ECU (EWS) and this time it succeeded... and also got rid of the EEP_2 error and the "brake fluid" warning and the cluster started working fine. So far this was the full result I was looking for.
8. After all this I realized that maybe my original data in my internal EEPROM was fine and it's only the coding that was wrong, so to test this (and for the sake of keeping my original configuration) I reflashed the internal EEPROM from my original backup without any modifications. Unsurprisingly, this caused an EEP_2. But after recoding with NCS Expert, that error was gone and everything was working fine.
9. Surprisingly though, my mileage was NOT showing the tamper dot. My guess is that during the prior repair that was done to this cluster they set the mileage exactly to 130k (because that is believed to be the estimated current mileage), and this is exactly the same value that you set in the coding plug, hence no tamper dot. Or do you think it could be something else? Anyway, the result is that I have a perfectly-working cluster with the correct VIN and coding configuration.

So the moral of the story is I didn't need to open my cluster at all - I just needed to take out the coding plug and reflash it with your file and then just recode the cluster via the OBD connection.

And now my request: I'd like to switch the odometer display from miles to kilometers (I'm in Europe, but the car is imported from the US). I changed the coding to switch it to km and it did briefly show the value in km (209215) but after the coding was done (and regardless of how many times I restart the ignition after that), it started showing 130001 km... which is the value in miles, but shown as km (maybe off by 1 due to some rounding error because of back-and-forth conversion?). I read somewhere that the US/UK clusters store the raw value in miles. So how would one go about setting the correct mileage in kilometers? Would it just mean putting the value 209215 in the coding plug EEPROM and syncing via test 16.1? If so, could you please prepare a new dump for me with that value? Thanks in advance - I really appreciate your help!

Regards,
Todor

[JBanzhaf]

Hi there, I'd like to ask you for the EEPROM dumps from a Z3M S54 cluster and coding plug. I actually have a genuine Z3M S54 cluster (in my Z3M S54) but it's having issues with the coding plug and possibly other things. I had power spikes in the car and they may have fried something in the cluster. It shows CodE_1 which I believe means it can't read the coding plug (or its data is corrupted?). I wanted to see if I can rewrite the necessary data in the coding plug to fix that. So would you pls send the file to me? My latest known mileage is about 130000 miles. It's a US-spec car and cluster. By the way, it looks like PASoft BMW Scanner 1.4 can read from and write to at least one of the EEPROMs through the OBD port. When reading, it dumps a 512-byte dump... which I'm guessing is the coding plug. So maybe I can even try to write what you send me from there, instead of taking the coding plug out and using a programmer. Do you know if that's doable?

Thanks very much in advance!
-Todor

PM Sent

[todor]

Hi there, I'd like to ask you for the EEPROM dumps from a Z3M S54 cluster and coding plug. I actually have a genuine Z3M S54 cluster (in my Z3M S54) but it's having issues with the coding plug and possibly other things. I had power spikes in the car and they may have fried something in the cluster. It shows CodE_1 which I believe means it can't read the coding plug (or its data is corrupted?). I wanted to see if I can rewrite the necessary data in the coding plug to fix that. So would you pls send the file to me? My latest known mileage is about 130000 miles. It's a US-spec car and cluster. By the way, it looks like PASoft BMW Scanner 1.4 can read from and write to at least one of the EEPROMs through the OBD port. When reading, it dumps a 512-byte dump... which I'm guessing is the coding plug. So maybe I can even try to write what you send me from there, instead of taking the coding plug out and using a programmer. Do you know if that's doable?

Thanks very much in advance!
-Todor

[NamGrandPaa]

Newbie here

[NamGrandPaa]

I have a 3.0l z3 also

[NamGrandPaa]

Hopefully someone more knowledgeable would chip in

[NamGrandPaa]

I’m having the same issues hoping this thread would help

[NamGrandPaa]

How long have you been having this issues ?

[ValVal456]

If anyone is interested in changing the coolant gauge buffer, it start at 0xF4.
there isnt much of a buffer on the S54 EEPROM compared to the non m.

M54 Cluster Water Temp Gauge




S54 Cluster Water Temp Gauge

I tried changing the gauge calibration string on a friend 3.0l Z3. For some reason it doesn't work, as soon as I program my custom string in the 93S56 EEPROM the cluster shows EEP_2 error and none of the gauge works. I tried both UPA USB and Xprog, programming process ends succesfully with each one. I verified every flash by reading the eeprom afterward, no difference between programmed file and read file. Of course, if I program the stock EEPROM file back everything works fine again.

Here is the stock gauge string : 0F 21 32 4E 4B A7 73 A7 78 2A 7D 53 which is 15 50 75 115 120 125°C.
Here is the modified string : 0F 21 3C 4E 55 A7 69 A7 6E 2A 73 53 which is 15 60 85 105 110 115°C.

Seems to me that there is a checksum in the file because that's the only explaination that come up to me for the program to throw an EEP_2 error. I would like to understand because it's a useful mod on the E46.

[sda2]

Does anyone know where the speedometer end value is stored in the cluster dump? I found 0xB4 and 0xB5 to be LoHi HEX*10 = rpm

Coding index looks to be stored at 0x89

[JBanzhaf]

I tried all the 93S56 algorithms PASoft provided and none were anything close to the actual EEPROM read.

Yes. PASoft hasn’t been setup to work with Z3 CAN bus clusters. The algorithm it uses doesn’t correctly read or write to the EEPROM. Interestingly enough, the dump it provides combines both the internal EEPROM and the coding plug with a large section of FF’s between them. It is unable to correctly write to the EEPROM. This is also in part because some sectors of the EEPROM are read only over TXD bus. So far, the only way I’ve found to code these clusters is by manually writing to the EEPROM chip itself using a chip burner.

[armenh7]

From my first attempt at reading the EEPROM with PASoft, it struggles to get an accurate read. Lots of FF's and missing information. That was only with a single algorithm though. I'll need to try the rest and see what happens.

I tried all the 93S56 algorithms PASoft provided and none were anything close to the actual EEPROM read.

[armenh7]

Yeah I wonder. Or maybe PASoft?

From my first attempt at reading the EEPROM with PASoft, it struggles to get an accurate read. Lots of FF's and missing information. That was only with a single algorithm though. I'll need to try the rest and see what happens.

[et89]

Yes. although i haven't had time to continue. I'd like to reuse unused pins on the Cluster PCB and install external wifi antenna.
Hopefully i find some time within this month to finish it up. Although I'm not really in a rush.
Here is how it sits currently.

Nice! keeping it inconspicuous with the black faceplate and no M-logo.