Golf MK7 Coding and adaptations

[hullll09]

ty that worked

[voshue]

Hello i am new at coding and these things. I bought light and rain sensor. When i trying to code light sensor , fault vehicle light occured. i delete fault but problem occured again. Pls help me how can i fix this. What i should do.

[dv52 (Australia)]

voshue: hmm........... not sure how you expect your question to be answered - but it's not possible to help because you have provided no specific information about this problem!

What is the actual fault message - what type of "rain sensor"- what model mk7 - what country - what value did you attempt to force into the long-code string?

Think about what data you would need to answer your own question - then include that information

Don

[grupoisimar]

buenos dias

como desactivar la proteccion de componentes cuando cambias la unidad principal de radio

EDIT:

good morning
how to disable component protection when you change the radio head unit

[dv52 (Australia)]

grupoisimar

Deleting Component Protection (CP) errors is NOT possible using OBD11.

Assuming that the "radio head" isn't hacked - you need to connect the car to VW's central server (it's called FAZIT) to delete any CP error in the official manner. This type of data connection is only possible by registered VW agents - like dealers and accredited independent workshops.

I'm aware that there are some service providers that can unofficially hack the module to delete CP errors using a remote connection on the car via software like Teamviewer. I won't comment on this practice

Don

[mr-fix]

Aug 8, 2022 0:14:12 GMT dv52 (Australia) said:

I'm aware that there are some service providers that can unofficially hack the module to delete CP errors using a remote connection on the car via software like Teamviewer. I won't comment on this practice

Don

Just to add a little bit more information: usually those hacked modules still trigger CP error codes both in 0x5F and 0x19. The hack just bypass the visible part of CP which is warning message on the display and/or sound channels lock.

[quailallstar]

Mar 19, 2022 4:23:21 GMT tristanr said:

I was recently snooping around in dashboard control module and did an output test of the various ‘chimes’ (5 in total) the instrument cluster speaker can make.

one of them was the Audi ‘door open’ chime.

curious if anyone knows anything about changing the default ‘door open’ alarm on a mk 7 to the one that sounds like an audi.. labeled ‘Acoustics 2’ in my case          

This piques my interest. I would like to hear if anyone has additional information about this. dv52 (Australia)

[dv52 (Australia)]

quailallstar : Hi again!!

Yes, I'm aware of the 5 x sounds in the "Gong" facility of the hex17 module. My assumption is that these are reference sounds that are available in all these modules and that one of the 5 x options is selected by software whenever needed (i.e. depending on the circumstances)!

However, AFAIK ( and I'm more than happy to be told otherwise), I don't believe that Gong-option selection is available in either long-code, or adaptation channel programming. Instead, my strong hunch is that Gong-option selection is coded into the far more fundamental module programming space - firmware!

If I'm correct (and I think that I am correct), yes it would be possible to select different gong-options for the various events that caused the hex17 module speaker sound using OBD11's EEPROM facility. However, the exercise would need an in-depth knowledge of how the module firmware was structured and in particular, which memory address locations to alter.

I certainly don't have this knowledge - but I'm aware of the ground breaking work that is being undertaken by our colleague mr-fix - see video below:

Don

[newty]

I am with you here. I never saw any Coding to change the Chimes.

I think there is a closed sound module, including a memory and and a speaker output, which is used on a variety of clusters throughout VAG, which is certified once and for all and manufactured for various cars of all brands.
Same applies when it is software, one well tested module, used for more than the Golf.

Using EEPROM to write Datasets is more complicated. You will need the factory Dataset, modify it and recalculate the checks.
The Cluster is also a very bad control units for first tries. Since is contains all immobilizer data, it will be a little more tamper resistant (or be stubborn after changes) and could prevent you from starting the motor after all...

[fabbromix]

Greetings to the whole community,
I did some research here on the forum if the oil level function could be activated via OBDeleven in my Golf 7 Alltrack (MY 2016) but unfortunately I can't find anything.
Could any of you tell me if this function can be activated in my MIB2?
Possible coding or link where to view everything.

Thank you.

[vwjap]

Nobody’s found oil level, even though the settings are in the adaptions

[vwjap]

dv52 (Australia) that’s interesting, wonder if vim could be activated via editing the eprom

[dv52 (Australia)]

vwjap: hmm......... Theoretically, my guess would be yes - but the same issues apply. Meaning that understanding the programming flow in the module dataset to the extent that the correct memory locations could be identified would be problematic! Well beyond my knowledge level - but there are many, very-intelligent folk on these forums!!

Don

[mr-fix]

Aug 25, 2022 21:57:24 GMT vwjap said:

dv52 (Australia) that’s interesting, wonder if vim could be activated via editing the eprom

Yes.
Connect with 5F, go to EEPROM, starting address: 0x000240, data length: 30 (dec), read.

You will get something like this:

00 00 06 02 06 02 00 00
00 14 06 02 FF 00 FE 00
FF 00 06 02 06 02 FF 00
00 07 45 34 BD C7

And here's a dataset that has VIM lock removed:

FF 00 06 02 06 00 00 00
00 00 FF 00 FF 00 FF 00
FF 02 FF 02 05 00 FF 00
00 00 30 34 97 5B
You will notice that some values changed from 00 or 06 to FF. This means that some locks are now triggered not at 0km/h or 6km/h, but at 255km/h. Not sure which byte is what, as there are different speed thresholds for different features (video, mirrorlink, backup camera, parking sensors, wiper settings...).

Also last 2 bytes is checksum, which you can calculate yourself after you edit your EEPROM dump.
Do it with with crccalc.com/ with settings from the screen shot (as an example I calculated checksum for the original dump). Notice that you need to input the dataset without the checksum. So 30-byte long dataset = 28 bytes of data, 2 bytes of checksum. 28 bytes go into the calculator co calculate missing 2 bytes.




So here's how to save 100 credits and remove VIM with DIY method.

[vwjap]

Fantastic write up, I did this a while back, can’t remember what tools I used but I remember after the security patch it messed up my way in to the unit and I had to use the app after that,
I’m defo gunna steal that 😂🤣😂 just to confuse others on other forums 😂🤣🤷‍♂️ Thanks mr-fix

Although I might change 255 to 199 because as I understand there could be problems with 255, so instead of FF it would be C7

[vwjap]

Also could this be used to add parameters to the dataset in other units? Like the PACC in the front camera or TJA (presume you’d have to look at the datasets from VCP to see the differences and the addresses?) mr-fix

Very interesting stuff I got to say

[mr-fix]

if the control unit parameterization/dataset is well documented, you can do it.
Exception is gateway, which will not allow you to read values (security reasons).

About TJA or LaneAssist timeout - you can look for OEM datasets and custom ones, compare diffs to check which bytes are related to the feature that you are after.

[vwjap]

Dont the vcp people keep most of their stuff under tight restrictions?
I’ve never been on the vcp forums (think their closed to non vcpers) but hardly ever read about datasets anywhere

[vwjap]

So just looked at my dataset (think it’s just VIM no MIM) and it’s

C7 00 06 02 06 02 00 00
00 14 06 02 FF 00 FE 00
06 02 06 02 06 02 FF 00
00 07 45 35 08 2F

So I’m thinking 0x000240 is VIM and if you have mirrorlink enabled 0x000250 is mirrorlink

[dv52 (Australia)]

mr-fix & vwjap : Gentlemen - thanks for the dialogue.

This is exactly the purpose of forums like this; the furthering of the forum-community's knowledge via the disparate skills of its individual members (and it always starts with high-intelligence forum colleagues like both of you )!!

So, I'm desperately trying to follow the hypothesis. Maybe it's because of my feeble brain, or perhaps the problem is my lack of understanding of the suggested protocol, but I need your help -please.

Let's start with the table below which contains data from both of your posts:

Hopefully, the table is self explanatory - but if not, a brief explanation of the column headings follows:

• Mr-fix Data is taken from Mr-fix post
  
• • OLD HEX=the non-VIM Byte-string
  • VIM HEX =the VIM Byte-string

• vwjap Data is taken from vwjap reply
  

• • OLD HEX=the Byte-string from his hex5F module (which is non-VIM)
  • VIM HEX = see explanation below
    
  
  

• <-VIM=FF? = The cells that are colored black are the Bytes in which (Mr-fix Data) VIM HEX = FF

Now, if I understand correctly, mr-fix is suggesting (I think) that those Bytes in VIM HEX (Mr-fix Data) which equal FF are the reference keys for VIM tweak.

As indicated by the black colored cells in my table - in VIM HEX (Mr-Fix Data), the following 7 x Bytes =FF:

• Byte # 00, 10, 12, 14, 16, 18, 22

So again if my understanding is correct (maybe it isn't?), the last column in my table VIM HEX (vwjap Data) has the Byte numbers above from vwjap 's hex5F module substituted with the value FF (if the Byte values weren't already FF) and of course, a new 2 x Byte Cyclic Redundancy Code is calculated using CRC-16/CCITT-FALSE method

What part of my methodology as described above is not correct? And are there really 7 x different elements (i.e. read "Bytes") in this memory location dedicated to VIM related cut-off speeds?

Don

[vwjap]

I think it’s a bit more simple than that dv52 (Australia)
First line which you called byte 00 (which is address 0x000240) non vim this is set to 06 which is 6kph, mr-fix vim setting is FF which is hex for 255, which translates to 255 kph, and my one is set at C7 which is hex for 199 which translates to 199 kph, now I used mib2high toolbox a while ago to set this, and there was a warning saying that setting vim over 200 kph can cause problems on some units, so I’m pretty sure as that is the only 199 in my eeprom that 0x000240 is VIM
As mr-fix said the other 06 settings would be for other speed settings for stuff like rear camera and other stuff that uses speed to shut off or start up (6kph off 2kph on?),
Now as a guess (and a total guess as I don’t use mirrorlink) mr-fix has set his mirrorlink to 255 (FF) and mine is still 6 kph and the only other difference is address 0x000250, so I’m guessing 0x000250 is mirrorlink but I could be wrong

[mr-fix]

This is how I see it:

First of all, bytes 12, 14, 22 are set to FF or FE from factory, so whatever they are referring to, it's not ViM or MiM or AndroidAuto in Motion...
Something else is set to FF (255km/h) by factory, so we can ignore those bytes for now. Those bytes are clearly not limiting ViM, MiM, AAiM.

This leaves us with bytes 00, 10, 16, 18.
byte 16 in my original dump is set to FF, and in vwjap dymp is set to 06. Difference might be caused by regional requirements of the destination country, car specs (MHI2 vs MST2), production year.

If you want to investigate this further, you could change just one of those bytes to FF (or C7), write it to MIB, and check which feature is not unlocked while vehicle is in motion.

Also keep in mind that my original example (goth datasets) are not from the same vehicle. Sorry for the confusion.
Original hex dump is from my car, vim hex dump is a generic ViM that is shared between message boards and MIB2 groups. I believe it will work on any unit, but the proper way to remove ViM, MiM, AAiM is to read original dataset, alter only related bytes, calculate checksum, write back to unit. This way you are sure that you are changing only ViM, MiM, AAiM settings and not other setting (for example regional requirements for RVC, or navigation data input lock while in motion.).

[vwjap]

So looking a bit further into this here’s some of the speed info all ribbed from jillebs toolbox

[vwjap]

So maybe

C7 00 Vim
06 02 car menu speed limit (but I have this disabled in adaptions)
06 02 DAB slideshow
00 00 DAB update rate 1
00 14 DAB update rate 2
06 02 mirrorlink
FF 00
FE 00
06 02
06 02 SMS editor speed limit
06 02 radiotext speed limit
FF 00 radiotext refresh rate
00 07
45 35
08 2F check sum

Again all just guess work, I’ll try and look in the scripts to get a better idea at a later date

[mr-fix]

Great that you mentioned this tool.
Take a look into the source over here: github.com/jilleb/mib2-toolbox/blob/master/Toolbox/GEM/mqb-vim_advanced.esd
(all credits to jilleb and olli991):

byte 00 - Video Speed limit (km/h)
byte 01 - Video Speed Hysterese (km/h)
byte 02 - Car Menu Speed limit (km/h)
byte 03 - Car Menu Speed Hysterese (km/h)
byte 04 - DAB Slideshow Speed limit (km/h)
byte 05 - DAB Slideshow Speed Hysterese (km/h)
byte 06 - DAB Slideshow Update rate #1 (s)
byte 07 - DAB Slideshow Update rate #2 (s)
byte 08 - User Manual Speed limit (km/h)
byte 09 - User Manual Speed Hysterese (km/h)
byte 10 - Road Guide Speed limit (km/h)
byte 11 - Road Guide Speed Hysterese (km/h)
byte 12 - Web Browser Speed limit (km/h)
byte 13 - Web Browser Speed Hysterese (km/h)
byte 14 - Destination input Speed limit (km/h)
byte 15 - Destination input Speed Hysterese (km/h)
byte 16 - Bluetooth/MirrorLink Speed limit (km/h)
byte 17 - Bluetooth binding Hysterese (km/h)
byte 18 - SMS Editor Speed limit (km/h)
byte 19 - SMS Editor Hysterese (km/h)
byte 20 - Radiotext Speed limit (km/h)
byte 21 - Radiotext Speed Hysterese (km/h)
byte 22 - Radiotext refresh rate (s)
byte 23 - Reserved
byte 24 - Reserved
byte 25 - Reserved
byte 26 & 27 - ASCII representation of dataset version
byte 28 & 29 - checksum

[dv52 (Australia)]

Gentlemen: Excellent development work - thanks for the additional insights!! 

Interesting that speed limits have associated Hysteresis values. I'd just never thought about it - but it makes sense to have a different switch-off speed (stops the limit from "hunting")

Don

[erikos0311]

Hi there,
Noob here, So I have a 2016 ROW GTE that i installed the 7.5 LED tail lights and are now planning on selling the car and put the original led tail lights it came with. Problem is I cannot find my notes with the old coding to I can re-code the tail lights to original format. Is there anyone that has the stock coding for this car? 2016 ROW GTE? I use the regular OBD11 for this. and the car came with the additional wires, so all i have to do is take the pins out and replace the pin clips to the older ones.

[vwjap]

You know virtually every one is different right?
Did you take a backup when you originally got the car? It will be in there
If not Do you have the same account? Look in the history at about the time you did it, it will tell you what you did

[erikos0311]

Alright, well I’m out of ideas, I think I need to start from the beginning. Is there anyone that can provide me with the OEM coding for a either the ROW Mk7 LED tail lights. (Original the GTE came out with) or the ROW MK7.5 (Variant LED taillights)(NOT dynamic) I had installed the 7.5 dynamic tail lights a while back and decided to go back to either the OEM mk7 tail lights or the MK7.5 (variant led taillights) reason I need them back to stock is because at one point, after switching back to the older twilights, I was not able to get both of the inside taillights to work. So after many attempts, I’ve lost my way back. Sooo… any advice or help would greatly be appreciated. my car is a Scandinavian 2016 GTE hybrid MK7.

[vwjap]

Like I asked before, did you make a backup before putting the new lights in? Did you use OBDeleven to code the new lights?