Quote:
Originally Posted by VTENGR
When you code anti-dazzle you're doing two things. I don't know your baseline knowledge of coding so I'm going to boil it way down - I'm not trying to offend you.
The first thing you do is you remove the "decode anti-dazzle" option from the car. This essentially is telling the car that you have anti-dazzle. this is called VO coding.
The second thing you do is you "CODE" all the ECUs that control anti dazzle - because according to them, they still think the "decode anti-dazzle" is still one of your features (VO coding), so you have to update the ECU for your new feature list. This is called FDL coding.
VO coding is the parent code - FDL is a slave code. So if you change a VO parameter, you can simply update the FDL and it will follow the VO code. Alternatively you can simply FDL code every module in every ECU that's required to achieve the same thing.
Luckily the anti-dazzle is a VO code parameter so you don't need to FDL code each module.
Since you have gone through the steps to remove this feature, the car now thinks anti-dazzle is part of your option package - so every subsequent update will follow that parameter.
The optimization is where FDL coding is requiring. Since FDL is a slave to VO, any changes you make by FDL will be lost when BMW updates the software.
I hope this made sense and was easy to understand - there's a lot more detail to it but this is the broad brush of what's going on.
|
Seems to me that based on VTENGR quote below, if the VO code for anti-dazzle is done, it will be permanent even after a software update push. Because he said VO is the parent, and then he said "so every subsequent update will follow that parameter:
"Luckily the anti-dazzle is a VO code parameter so you don't need to FDL code each module."
"Since you have gone through the steps to remove this feature, the car now thinks anti-dazzle is part of your option package - so every subsequent update will follow that parameter."