Cluster Mods

[Occams_Razor]

Cluster Mods - Welcome

enable the "welcome" cluster message

Done this today on my full FIS sport cluster, you change address 417 and change 02 to 6B

*******************************************************

using vagtacho and the hex editor program XVI32.

*******************************************************

A big thanks to graeme86 for drawing my atention to this


__________________
2003 VW Golf TDI PD 130,jazz blue, xenons,Allard FMIC, Turbodynamics stage 2 hybrid VNT 17 turbo(MD 376)221bhp, uprated sachs clutch. Aligators custom remapp

 

[Occams_Razor]

Cluster Mods - Addresses for Welcome & Miles to Empty

0417 should say 02 ("welcome" message off) which you change to 6B ("welcome" message on) as posted above.

0416 is used to enable the "miles to empty" feature.

If the "miles to empty" is turned off (i.e not displayed in the MFA menu when you scroll through), then the figure is C1

To enable the "Miles to empty" display, change this figure to E1

These are known correct values for my full pixel MFA Euro cluster R32 which has part number 1J0 920 846 F

They may or may not be in the same addresses on other clusters.

graeme86
Veteran Member

 

[Occams_Razor]

Cluster Mods - Byte Swap Caveat

Graeme depending what software you have used to read the EEPROM, sometime the bytes can be swapped over, ie 0416 might be 02 instead of C1. I think all Immo III VDO FIS cluster have the same addresses. All the ones I've seen.

aRd
Member

 

[Occams_Razor]

Cluster Mods - Address are Hex Address - Please Annotate!

Please remember that those addresses are hex addresses. They really should be notated as such to avoid confusion. I'm getting used to the C/C++ notation, which is "0x" followed by the four-digit hexadecimal number, but you may also see it written as the four-digit number followed by "h".

Miles to empty is at 0x0416 (or 0416h), and the welcome message is at 0x0417 (or 0417h).

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Cluster Lighting

What he said.^^^

I have trolled up some more stuff on the German forums:

Drumroll please.....

You can have the cluster lighting come on when the ignition is on, independently of the light switch.

Not only that but you can also select which parts light up:

Any combination of the needles, the number scales and the displays (clock and odometer part)

Audi S3's come with this feature which I believe can be switched with VAGCOM. The VW cluster (IMMO 2 or IMMO 3 only) require the hex codes to be amended.

The thread is still developing so stay tuned:

http://www.gti-tdi.de/board/thread.php?threadid=1320&threadview=0&hilight=&hil ightuser=0&page=10

And then there is this (may have to be registered to view this forum):

http://www.r32-club.de/showthread.php?t=6151

graeme86
Veteran Member

 

[Occams_Razor]

Cluster Mods - Cluster Lighting - 1 Byte Change!

Quote:
Originally Posted by Nihilator
But if it's just a byte change, that'd be über-kewl.

Hey, guess what? It's just a byte change!

I did it tonight, and it works on my 1J0 920 926 F (IMMO-III VR6 MFA). I changed the byte at 0x01ED to "3F" (from "30"), and now my whole instrument cluster (faces, needles, and displays) lights up when I turn the key to "ignition on."

mtltdi, I actually tried "X9" to get just the needles to light up...that worked, too, and looked pretty cool in a dark car at 1:00am. With the ignition on, only the MFA, the needles, and the idiot lights that remain on when the ignition is on but not started were lit.

Gotta PM LeeNouks on gti-tdi.de and thank him. And thanks to you, graeme86, for bringing it here!

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Cluster Lighting - Hex Talk

I'm glad someone here understands all this "hex talk"

I wasn't 100% on what codes were actually needed to do this, hence my reference to the German forum.

LeeNouks (Big thanks )post said:

Quote:

1ED auf X3 für Displays ohne Zeiger und Skalen
1ED auf X5 für Scalen ohne Displays und Zeiger
1ED auf X7 fürScalen und Displays ohne Zeiger
1ED auf X9 für Zeiger ohne Display und Skalen
1ED auf XB für Zeiger und Displays ohne Scalen
1ED auf XD für Zeiger und Skalen ohne Displays
1ED auf XF für alles Aktiv

Das X steht fuer eine x-beliebige Ziffer welche keine Auswirkung auf das Ergebnis hat; also belassen werden kann was drin steht.

Zeiger = Pointers,Skalen = Numerical scales on the gauges and Displays refers to the clock and odometer display windows only btw

My IMMO 3 cluster has 30 in position 0x01ED as well, so you can leave the "3" part and put the suffix digit e.g. 3F and everything works. But could you put "XF" as well and it would work also????

I wonder if you could clarify this for us hex noobs???

I think LeeNouks explains it in his quote at the bottom, but I can't get a precise translation of it:
"Das X steht fuer eine x-beliebige Ziffer welche keine Auswirkung auf das Ergebnis hat; also belassen werden kann was drin steht."
The best I can get is: X which stands for x any figure no effect on the result has; thus it can be left what is in it.
Sounds like you can put any figure at all in the "X" position and it has no effect on the programming - the critical digit is the second part.

Also, just to clarify how the feature works:

Ignition on - selected cluster lights come on whilst driving without switching on lightswitch. Dimmer switch (rheostat) has no effect on cluster lights.

If you turn on lightswitch then all dashlights come on as per normal. Dimmer switch then operates as normal.

Is that Correct??

And finally, this all has me wondering... This feature can be enabled with VAGCOM on Audis, by changing the cluster softcoding, so would it be possible to alter the hardcoding of the VW cluster to enable a softcoding change thru VAGCOM..if you get my meaning?

graeme86
Veteran Member

 

[Occams_Razor]

Cluster Mods - Cluster Lighting - "X" = Arbitrary Number

No, "X" is not a valid hex character. Plus, it wouldn't say that the first digit of the byte has *no* effect, it only has no effect on this mod. I'm sure the first digit does something, so changing it from whatever it was originally is not a good idea.

A good way to interpret that is: "The X stands for an arbitrary number that has no effect on the result, and so can be left as it stands."

I haven't tried the dimmer switch to verify that it has no effect when the lights are off. It may behave differently in clusters with US software vs. clusters with euro software, since we've got daytime running lamps. It might also behave differently cars with and without MFA/FIS, because cars *with* MFA/FIS have the light sensor that may act to dim the backlighting.

Other than that caveat, what you wrote sounds correct to me.

Yes, what you say makes sense, but I would have no idea where to look for that. Activating some byte in the software may allow you to go to a specific adaptation channel to change this on your own, but that's far beyond the scope of my abilities.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Software & Hardware Needed

Quote:
Originally Posted by TDi110
Ok you guys have got me hooked onto this. What I need to know is what I need to do all this stuff and possibly where to get it from.

I figured I need a program such as Vag Tacho?
What lead do I need?

Can I use my 3rd party vagcom lead?

Any help would be appreciated.

TDi110

Vag Tacho is more than just software, it's the hardware you need, too.

Only two tools will work, that I know of, unless you're good at desoldering surface-mount IC's. Either Vag Tacho or VAGdashCOM, and I don't believe Vag Tacho is particularly reliable.

--Chris

PS-- I think I'm going to turn off my "displays" (clock and odometer). I need something to remind me to turn the headlights on at night, and since I can't see the backlight on those two particularly well in the daylight, they're good candidates.

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Cluster Lighting/Dimming

Quote:
Originally Posted by Nihilator
Sorry...I tested it (incompletely) and forgot to report back.

When the headlight switch is off, the cluster lights are bright, although it didn't occur to me to check if they were at their brightest, or if they were at all controlled by the light sensor.

When the headlight switch is on, the cluster lights dim with the interior lights, and are subject to the rheostat.

--Chris

Update:

I reprogrammed it so that the odometer and clock are off when the headlights are off. It does serve to remind me to turn the lights on, although not having the radio and Climatronic screens lit does, as well.

And I like that the needles, being lit, are easier to see now in the daylight.

After some testing, I have some slightly surprising (to me) results to report.

When the headlight switch is off, the cluster backlighting is at its brightest, except for the MFA, which is bright, but still subject to the light sensor. If you shine a light directly in the light sensor, the MFA will brighten up to compensate, but the other instrument cluster lights do not seem to be affected.

When the headlight switch is on, the cluster lights dim, along with the rest of the interior lights, according to the rheostat position. Interestingly, the light sensor makes not *just* the MFA dim and brighten, but the rest of the instrument cluster lights as well! It's most obvious when you rheo the lights all the way to their dimmest, and then shine a light directly into the light sensor...the whole cluster slowly brightens.

How about that chit?

And I'll bet you *anything* there's a byte you can change that will alter *that* behavior as well. So that, say, the cluster lights are *always* subject to the rheostat or are never *ever* subject to the rheostat. It just hasn't been found yet, I'm sure.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Half Height?

Quote:
Originally Posted by ARBY
Is all this on the half-height clusters as well, or just the full height?

Both, I'd guess, but I've only tested mine. It's a half-height. 1J0 920 926 F with late-model Passat (R32-type) speedo and tacho faces.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Rebooting

Quote:
Originally Posted by Nihilator
Both, I'd guess, but I've only tested mine. It's a half-height. 1J0 920 926 F with late-model Passat (R32-type) speedo and tacho faces.

--Chris

I just did mine today and it operates as exactly as Nihilator described.

I have a full height FIS R32 cluster.

I also had to disconnect the battery after programming to enable the new features. Is there another way to get them to kick in without doing that?

graeme86
Veteran Member

 

[Occams_Razor]

Cluster Mods - Fuel Consumption Fudge Factor #1

Quote:
Originally Posted by digifant_gli
So then basically, we have covered the code for the welcome message, instrument lighting and.....is that it?

There's another one I forgot.

In IMMO-II clusters, you could go to an adaptation channel to set the fuel consumption fudge factor...the one that is used to calculate the fuel economy that shows up in your MFA or FIS cluster. (Other people have noted that there's an offset setting available for the fuel gauge needle...that is NOT what I'm talking about here.) They took the ability to change this out of the IMMO-III clusters, but the fudge factor is still there in the code.

It's located at 0x0145 in my 1J0 920 926 F. Chances are it's located in the same relative vicinity in other MFA or FIS clusters. By default it reads "64", which is a hex number that translates to 100 in decimal. Moving that number up or down will supposedly alter the calculation for fuel economy, but I don't know which way is which. In IMMO-II clusters, it had a range of 85 to 115 (decimal), and could only be moved in increments of 5. It may or may not be the same for IMMO-III clusters.

And it may not even work. I haven't had a chance to play with it at all, I only had the opportunity to look for it and note where it was. Therefore, a big YMMV on this one.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Fuel Consumption Fudge Factor #2

I've got an IMMO-II cluster (1J0 920 925 D) here at my desk right now. It's Adaptation channel 03. The standard is 100%, range is 85% to 115%, and Ross-Tech's label file says it's in increments of 1%, not 5% as I said above. However, I get an error when I try to increment it by anything other than 5%...it only tests correctly when I use 85, 90, 95, etc. Ross-Tech may have gotten their label file wrong.

Switching to an IMMO-III cluster (1J0 920 926 FX), I see adaptation channel 03 is not available. My guess as to why it was removed: either people were using the adaptation channel to misrepresent their fuel mileage when reselling their cars, or VW was tired of answering questions as to why it didn't jibe with real-world mileage.

--Chris

PS-- ARBY, it's still adjustable...just not with a VAG-COM.

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Fuel Consumption Fudge Factor Explanation

This fudge factor for mpg has come up before:

Here is full post:
http://forums.tdiclub.com/showthread.php?t=111362

The interesting bits on how the fudge factor works are mainly here:

http://forums.tdiclub.com/showthread...=111362&page=6

and

http://forums.tdiclub.com/showthread...=111362&page=8

Just need a few hex to decimal conversions to try out.

graeme86
Veteran Member

 

[Occams_Razor]

Cluster Mods - Fuel Consumption Fudge Factor #4

Tried to kill two birds with one stone today.

My odometer has been reading about 0.8% short, according to my GPS. In addition, my MFA economy readings have been reading high by about 4%.

So I changed my K-value down 1% (from 3528 to 3493...fewer impulses to the mile will raise the number of miles odo'd per mile traveled), and changed the MFA fudge factor from 100 to 105. The K-value change will set the odometer correct, but will *also* (I guess) raise the error in the MFA by another 1%, so the 105 should bring it down by 5%.

I'll report back in a few tanks and let you all know how it worked.

Interesting note: Now that I've changed the K-value, my cluster coding has changed from 05232 to 05230. The final "2" used to indicate a fixed K-value of 3528. Since there is no coding value for 3493, it's reverted to "0" on its own. "0" usually means that the cluster receives the impulse readings through the CAN-bus.

I have to remember not to recode the cluster with the trailing "2".

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Odometer Correction

Quote:
Originally Posted by Nihilator
My odometer has been reading about 0.8% short, according to my GPS. ...

So I changed my K-value down 1% (from 3528 to 3493...fewer impulses to the mile will raise the number of miles odo'd per mile traveled),...

--Chris

After about 100 miles, the error in the odometer had swung to 0.3% in the opposite direction...my car's odometer was reading about 0.3% too high, in comparison to my GPS. So I went back in and changed my K-value to 3503. Another hundred miles and it was within 0.1% of the GPS.

Unfortunately, every time I changed the K-value, it resets the cluster's trip information, so I had to wait until today to start the data collection for the fuel consumption test.

Again, I'll check back in to let you know how it went.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Speedometer Error Correction

Okay, so we figured out how to adjust the speedometer scale, too. It's really involved at the moment, and I'm sure there's an easier way, but I can now get rid of that infernal 3.5mph speedo error!

http://www.gti-tdi.de/board/thread.php?threadid=2158

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Speedometer Error Correction #2

It's going to be a pain, though. After determining what the new values are supposed to be for the scale's eight two-byte words (not tough), they have to be written to the cluster, as there's no adaptation value for this. Well, maybe there is, but no one's pointed it out yet.

Then I have to recode the cluster to remove the checksum error. But recoding the cluster will wipe out the changes I've made to my K-value, so I'll have to go back and make *that* change again!

Then there's there's 2,000 miles worth of long-term fuel economy accuracy checks.

In the end, though, I'll have a cluster that accumulates miles *accurately* ( <0.05% ), calculates fuel economy *accurately* ( <1% ), and displays speed *accurately* ( <0.5% ). Why VW couldn't do this in the first place is beyond me, but I'll be pleased as punch to get it working the that way. After only 49,500 miles.

Worth noting: I've only filled once since changing the fuel consumption fudge factor, but my trip odometer + distance till empty figure has been consistent at about 430. Hasn't varied much beyond 10 miles from that figure at any point. Noice!

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Speedometer Error Correction - Results!

My speedometer is DEAD ON ACCURATE now. I love it. It was worth the hassle.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Speedometer Correction - Results! #2

Quote:
Originally Posted by Nihilator
Then there's there's 2,000 miles worth of long-term fuel economy accuracy checks.

In the end, though, I'll have a cluster that accumulates miles *accurately* ( <0.05% ), calculates fuel economy *accurately* ( <1% ), and displays speed *accurately* ( <0.5% ). Why VW couldn't do this in the first place is beyond me, but I'll be pleased as punch to get it working the that way. After only 49,500 miles.



--Chris

Update:

After over 1800 miles, everything (odometer, speedometer, fuel economy calcs) is as close as I could possibly hope it to be.

I kinda wish my economy were a bit better (all you diesels, just zip it!), but oxygenated fuel and cold temps are the bane of gassers. It'll be back up to 31 in the spring.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Linear Coolant Temp Gauge

By the way folks, I now have a linear coolant temp gauge in my MKIV instrument cluster. The gauge as it comes from the factory is programmed to sit at dead center, on 190F, for all coolant temperatures between (about) 182F and 207F. This is certainly reassuring, especially to non-enthusiasts, but I wanted my gauge to show *actual* temperature, dammit!

I found the line-and-a-half of code that specifies the response curve, altered it to be completely linear, and reinserted it. It still needs some tweaking (because at the same time, I went from 1J0 gauge faces to sport edition 1J5 faces), but now my coolant temp gauge will move in response to every change in coolant temperature! Rockin'!

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Linear Coolant Temp Gauge #2

Yeah, I want more info on the coolant temp mod. It's always bugged me that the needle doesn't vary a bit once it's pointing staight up, even though I KNOW there's gotta be some variances happening.

Let us know the secrets, GrandMaster Chris!

Nuje
Member

<Sigh...> Fiiiine.

In my cluster (a 1J0 920 926 F), there are two sets of six two-byte words. The first set is located at 0x02D4 to 0x02DF. The second set is at 0x02E0 to 0x02EB. Translated to decimal and plotted against each other (first set of six as x-values, second set as y-values), you get this:

Change the two middle y-values so they're in a straight line with the point before and after them, and you get this:

Translate the decimal values back to hexadecimal, and reinsert them in the cluster code. Done.

It's not perfect. I think the coolant temp sensor has a non-linear response curve itself, because event though I now have a linear curve in the EEPROM, a plot of coolant temp (as measured with VAG-COM) vs. gauge needle location (i.e. lowest end, 1st tic, 2nd tic, etc.) isn't linear. Still have to work on making it *exactly* right, but for now, it's great.

--Chris

Nihilator
Veteran Member

 

[Occams_Razor]

Cluster Mods - Warning! Warning!

I hate to say this, because I so want to do it to mine , but these eeprom mods really should only be done by someone who knows what they're doing. If you have to ask a lot of the basic questions about how it's done, that should be a hint that you should find someone to do it for you.

I've screwed around w/my cell phone and there are warnings all over the web sites saying "you're responsible if you hose your phone".

[/soapbox]
Now on with the modding!

SilverGhost
Veteran Member

 

[Occams_Razor]

Cluster Mods - Linear Coolant Temp Gauge - Explanation

Quote:
Originally Posted by Nuje
Ummm....thanks Chris. But, uh...like....umm...what does that mean?

I did a eeprom dump of my cluster (1J5 920 846 C), but how do you know which six "two-byte words" to look for? How do you decide what does what looking at the hex?

From 0x002D0 to 0x0030F, my "words" look like this:
E0 03 10 04 F0 00 90 01 50 02
60 03 E0 03 10 04 10 00 10 00
8C 02 8C 02 8D 04 09 05 87 8A
77 00 78 1E 00 27 88 2F 10 38
98 40 20 49 A8 51 30 5A B8 62
40 6B 0A 00 2A 00 46 00 60 00
78 00 8E 00

Dazed and confused in hex-land....

It looks like the 2-byte words are big-endian format... The bytes have to be swapped then converted to decimal before graphing. Then use the slope-line formula (remember highschool algebra?) to calculate the new points for a linear fit. Convert back to hex and swap the bytes to get the new word values.

Here is a raw EEPROM dump from my 1J5 920 946C cluster starting at address 0x02D4:

F0 00 90 01 50 02 60 03 E0 03 10 04 38 00 38 00 AE 02 AE 02 AA 04 25 05

Here is the processed data showing the before and after mapping:

In other words I'll have to edit the EEPROM dump and change the byte values as follows:

Address Before/After
0x02E4 AE/A9
0x02E5 02/01
0x02E6 AE/B3
0x02E7 02/03

I'll load these values into my cluster in a few days and let you know how it works.

It looks like the mapping may be different on almost all clusters. The one thing that is common is that they all seem to have a flat-spot in the midrange values.

TD

TeleDawg
Veteran Member

 

[Occams_Razor]

Quote:
Originally Posted by Nuje
Two questions:
1) How did Chris find out/discern that the 0x02D4 and 0x02E0 areas were the ones that affected the temp. gauge display?

It was an educated guess. I knew roughly what to look for, and where, from previous work with the speedometer and fuel scales. And I have hundreds of EEPROM dumps to compare against each other, so that helped.

Quote:
Originally Posted by Nuje
2) Regarding messing with the eeprom: if one were to do something "bad" (write some bogus values), would it fry the cluster? Would it be possible to write back the original values to the changes by simply loading a saved copy of the original eeprom?

It likely would not "fry" the cluster, although it's very slightly possible you could lock yourself out of the cluster and not be able to re-write the original dump to it. Highly unlikely, though...Once I received a cluster that was essentially completely wiped clean of all data from the EEPROM, and after a try or two I was able to write the dump from a similar cluster onto it, making it useful again.

--Chris

Nihilator
Veteran Member