[misguided_will]

Hi all,

when coding in options, does this count as "flashing" and something that the dealer can/will check and possibly use against you in the instance of a warranty claim?

is coding the same as "flashing" xhp, mhd and the like or are the footprints from flashing performance parameters elsewhere?

thank you!

[Billfitz]

Coding doesn't affect warranty, because it only enables, disables or alters options that originally came with the car. Third party hardware and software may be a different story.

[muniz_ri]

Originally Posted by misguided_will

Hi all,

when coding in options, does this count as "flashing" and something that the dealer can/will check and possibly use against you in the instance of a warranty claim?

is coding the same as "flashing" xhp, mhd and the like or are the footprints from flashing performance parameters elsewhere?

thank you!

Coding is not the same as flashing. Flashing is replacing the stock firmware with aftermarket modified firmware.

[IK6SPEED]

Originally Posted by muniz_ri

Coding is not the same as flashing. Flashing is replacing the stock firmware with aftermarket modified firmware.

Both update the unit and are recorded as the unit being modified as the count increases by one on every write/save.

BMW through ISTA knows the count every time they connect the car up to be diagnosed at the Dealership and the information is transmitted to the servers. They know what the count was the last time it was at a Dealership and how many times it was written to by a Dealership.

To assume differently is foolish.

[muniz_ri]

Originally Posted by IK6SPEED

Both update the unit and are recorded as the unit being modified as the count increases by one on every write/save.

BMW through ISTA knows the count every time they connect the car up to be diagnosed at the Dealership and the information is transmitted to the servers. They know what the count was the last time it was at a Dealership and how many times it was written to by a Dealership.

To assume differently is foolish.

On what basis did you conclude that coding leaves a trace?

[IK6SPEED]

Originally Posted by muniz_ri

On what basis did you conclude that coding leaves a trace?

It's well known that most electronic units, including these, have a count of the number of times it is written to.

The count increases by one every time a save/write is performed.

It increases by one whether you are saving 1 parameter or 100 when the save is written and saved to memory.

If you change 1 of 100 parameters and write/save after each one, it will advance by 100. If you write and save all 100 at the same time it will only advance by 1.

Again, it's the number of writes/saves to memory. Not how many parameters were saved/written to memory.

[HFW003]

Will I have coded four of my own cars and many others cars and, to the best if my knowledge at least and definitely with my cars, not once has there been an issue with a warranty claim from the dealer.

With the types of coding available there would be no need for a dealer to dig that deep into the relevant module to find any alterations to validate or deny a warranty claim.

Furthermore, in my experience, the dealer would have no idea a car has had any of the VO changed.

As Muniz said, coding is not flashing and in fact coding is not coding it’s just altering pre existing variables.

[capt_slow]

FDL coding wouldn't be detected. As it changes individual ECU options on the existing VO. If a dealer were to program your car that had only FDL coding, it would just blow your changes away and bring it back to default per the VO.

VO coding is another story. It's the feature set and options that the car had when it left the factory, that along with the I-Level is reported back to BMW by ISTA and the dealer network. Routine maintenance and a key read wouldnt detect a VO code change, but programming definitely will throw red flags. The VO code reported by the car will differ from the BMW database.

In the past when dealer spot VO coding, they usually slap you on the wrist, reset your VO to factory specs, and continue programming. Also note that the dealer will know that you coded your car if there are obvious signs: using a Rolls-Royce start-up screen on your iDrive is a dead giveaway.

[atzebmw]

One should not play down the FDL coding.
The whole coding options are not just for the own car.
There are many FDL coding options which are for other car series or models or equipments.
And also there are many codings which the dealer could see immediately.
I wouldn't risk the warranty and can only recommend to set all options to standard.

[sdbmwcoding]

Coding will not void warranty, just don't VO code. If you flash/update software on modules or VO code then your warranty can definitely be voided.

[IK6SPEED]

Originally Posted by sd*********

Coding will not void warranty, just don't VO code. If you flash/update software on modules or VO code then your warranty can definitely be voided.

Again, any write increases the count, VO or otherwise.

Not saying this will absolutely void the warranty, but that was not the question asked in this thread.

[justa3bmw]

I've been coding for over 10 years and never once heard of any type of dealer warranty denied claim or them actually even caring. I'm not sure what dealers you guys goto but I've always told them the cool things that can be done with coding and coded employee cars as well.

[Dang3r]

You want an example for denied warranty? Here goes: My ambient light went suddenly from more dark to nearly out during warranty. I had coded the brightness setting via iDrive menu w/o the small poti at the headlight switch.
Conclusion: Dealer detects coding in display and refuses warranty replacement of ambient light modules caused by assumed error caused by coding.
End.

[muniz_ri]

Originally Posted by Dang3r

You want an example for denied warranty? Here goes: My ambient light went suddenly from more dark to nearly out during warranty. I had coded the brightness setting via iDrive menu w/o the small poti at the headlight switch.
Conclusion: Dealer detects coding in display and refuses warranty replacement of ambient light modules caused by assumed error caused by coding.
End.

Would the dealer have detected that you had previously coded the lighting if you had reverted the coding back to stock?

i.e. the dealer would not be able to detect previously coded items if you revert back to stock before going in for service.

[Poochie]

Originally Posted by Dang3r

You want an example for denied warranty? Here goes: My ambient light went suddenly from more dark to nearly out during warranty. I had coded the brightness setting via iDrive menu w/o the small poti at the headlight switch.
Conclusion: Dealer detects coding in display and refuses warranty replacement of ambient light modules caused by assumed error caused by coding.
End.

The dealer doesn't care about coding, nor do they have an official method of detecting such changes, unless it's blatantly obvious the issue is related to the owner screwing around with the settings.

Only a microscopic fraction the general owners mess around with coding features, it's not even on their radar and some didn't even know it's possible for an end user to easily accomplish.

I had a bunch of stuff replaced under the warranty of my vehicle, from various dealers, including the seat frame, iDrive controller, to rear differential, not an issue with any of my changes.

I'm fact, when they reprogrammed my car, the LCI tail lights had a the 'bulb checks' reenabled, they gave me back the car with a bunch of faults and didn't say a thing about the retrofit or previous coding.

I'm assuming you shared more information than you needed to and they just decided to pass the buck to you because it's one; you now confirmed the fault is due to user error and two; it's an easy way for them to weasel their way out for doing the warranty work.

[sdbmwcoding]

Originally Posted by Dang3r

You want an example for denied warranty? Here goes: My ambient light went suddenly from more dark to nearly out during warranty. I had coded the brightness setting via iDrive menu w/o the small poti at the headlight switch.
Conclusion: Dealer detects coding in display and refuses warranty replacement of ambient light modules caused by assumed error caused by coding.
End.

Did you try to revert back to see if that would fix your issue? Almost sounds like you burnt out the led's or however the ambient lighting is configured. I would say that's pretty accurate to be honest. If I were to code an e92 that was under warranty to max angel eye brightness causing the bulb to burn out and the dealer checks the voltage on the h8 bulbs were at 13v+ then they're more than inclined to deny that. If your problem was merely a coding problem that could be fixed without any hardware changes then I don't see how they could have denied it unless you damaged hardware.

[Dang3r]

No, this is a known problem for F32 from 2013 to the mid of 2015, the LCI got other modules without this problem.
Has nothing to do with coding, just a BMW problem and reported here several times. If I had knew before that the dealer would came onto my codings, I had reverted this for sure. Next time.
You are in SD? Cool, saw that BMW garage near Gas Lamp Quarter and paid the guys a visit, nice older bimmers inside.