I sent my Passat's cluster to Cluster's by Litke to have him replace the MFA screen, when I got it back, the needles were backlit whenever the key was on (rest of the cluster backlighting remains off until you turn on the lights), the needles do a min to max sweep when you first key it on, and my cruise control light now only comes on when I engage cruise instead of just on when the main switch is set to "ON".
Well, that sent me down a rabbithole, poking around on the old Nefmoto website to find this handy reference:
http://nefariousmotorsports.com/forum/index.php?topic=7964.msg74241#msg74241
This is *only* for VWK501 and 503 software clusters. Sorry Immo II owners, you're left out yet again.
After some further research to find how the needle sweep is performed, it turns out it only applies to MFA screen and full FIS screen-equipped clusters. I guess the lower end clusters don't support it.
Graeme's webspace has the tutorial on how to do the needle sweep for those clusters. Again, have to differentiate if you have
501 or
503 software first, and then there's further differentiation on each of those pages depending on a more specific variation of the chip/software the cluster has--he walks you through each.
But, happily, the other hacks mentioned do indeed work on standard 501 and 503 non-MFA/FIS clusters. The better half has a 2003 Jetta wagon and it now features full time backlit needles and a cruise control light that only comes on if SET cruise and is actively engaged. The moment cruise gets canceled for any reason, the light goes back off.
I've also been poking around howtos on making the coolant temp gauge more linear. Finding out you need to graph on an x and y plot two lines of code. On 501 software clusters, it's the first 12 bits started with 0x2E (0-A) as your Y axis, 0x2D (4-E) as your X axis. Only really need to modify 2 pairs of bytes in the middle of 0x2E line (two bytes make up one decimal value of the mapping--and it's read from right to left). If you want it 100% linear, you really could just copy 0x2D4-0x2DE and paste it to 0x2E0-0x2EA. Inspired by the post
found here--but not totally sold on how a simple straight line was made...
Or, if you'd prefer some minor amount of buffering on the low end--where the needle doesn't even start moving until the engine has adequate temp--leave the first 4 bytes alone, and also leave the last 4 alone, only modifying the 4 bytes in the middle (0x2E4-0x2E7).
This keeps the not as linear moves on the extreme ends of the scale, which I kind of like, but you can make the range in the middle perfectly linear. What I mean by that is the needle stays pegged on cold while the engine is warming up, it's more useful info to me to only have it start to come off the full cold mark only when the engine actually has adequate temp in it to not have to be so easy on it vs. a linear reading that might move much sooner on that end of the scale.
Likewise on the high end of the scale, as you start to get above 108 C, the needle will start to move a fair bit faster to the high end. The original mapping basically has it so the needle is practically dead in the middle from the mid 70 C range to just above 108 C. And since there are only 6 values to set the curve of the needle's response, it makes some sense to keep the gauge's original behavior on the extreme ends of the scale, but make the middle operating range more linear.
This is how that would look plotted on a graph:
View attachment 143441
Original mapping on the top graph, lower graph just has the two sets of middle bytes changed to be 1:1 with the X axis. Effectively, you could take the decimal value of the two bytes and divide them by 8 and you'd actually get the temp value in Celsius.
So, originally on the cluster shown, it was 761 on the one axis while it read between 592 and 861 decimal values. Divide by 8, you get what that is in Celsius.
592 = 74 C
864 = 108 C
761 = 95.125 C
So, in the case of this 501 software cluster, you'd convert (Windows calculator has a "programmer" mode that makes conversions super fast and easy) the following addresses:
0x2E4: 50 (originally F9)
0x2E5: 02 (originally 02)
0x2E6: 60 (originally F9)
0x2E7: 03 (originally 02)
Values in hexadecimal, not decimal. The EEPROM reads *pairs* of bytes in this case--the byte pairs are read in reverse (right to left) but the pairs are ordered from lowest to highest, read left to right, somewhat confusingly because there's a mix of both left to right and right to left ordering going on... heh
So, you're reading the first value we're changing, starting with 0x2E5 plus 0x2E4 in that order. The second value is 0x2E7 plus 0x2E6 in that order. When you read left to right, they read F9 02 in both pairs of bytes in the original calibration in this instance. But the EEPROM reads them as 02 F9. So, if you enter F9 02 into the "Programmer mode" Windows calculator to convert to decimal you'd get 63746! That's definitely not right. If you enter 02 F9 and convert to decimal value, you get 761 of the combined two bytes--that's more like it.
So, bytes 4-5 is being read as 0250 by the EEPROM, even though the order you normally read them as 5002 left to right.
0250 in hex to decimal is 592. If you got them reversed and the EEPROM reads it as 5002, that would be 20,482. lol. So yeah, important to get it right!
Might have to play with this as each car may actually center their gauge a little different, the two clusters I've looked at for the temp mapping were setup noticeably different. The values in 0x2D seem to remain constant, but how the gauge is setup to respond to 0x2E sometimes varies a little.
I did dump the entire cluster eeprom and back them up with KW1281test before modifying. But, now that I better understand what I'm looking at, I can go in and change individual byte addresses to effect the change I'm after. I did modify, in a hex editor, the two files I have and saved them to try on the respective vehicles in question instead of modifying the individual byte addresses, but when you get the values spelled out for you, it's sometimes faster just to change the handful of addresses you want individually than it is to dump the entire thing and then reupload the complete file.