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

[NamGrandPaa]

Newbie here

[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

[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]

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]

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]

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

Thanks very much Joel! I've been away from home for the holidays and that's why I haven't replied. Also, apparently I can't reply to PMs (I guess my account here is too new). Pls send me a PM with your email and I'll send you my original files - I certainly don't mind sharing those to help out the community.

Coding is not an issue for me - I can just redo it with NCS Expert at any point in time, but it seems like it does require the VIN to match. There's also the issue of the FA and other ZCS data... which in my case happened to be 100% the same as the data on the dump you sent me. And since the default coding is determined based on the ZCS data, I could also just code thw cluster using its own ZCS data even if the VIN didn't match (and that worked). But yeah, looks like switching the VIN in the dump and then recoding with NCS Expert works too.

Btw I also recorded other dumps at various steps in my process, so you can see which bytes get changed for which operations. I'll send you all of those by email.

-Todor