[Almaretto]

Originally Posted by Nezil

Ok, got it... There are quite a few more changes in the F15 FLE than we show on LCI F87.

Do you think there is any risk in trying the similar looking changes? It shouldn't break anything should it?

What was the history of how this played out with the Adaptive LED LCI F30? I assume they also tried FLE coding.

I would definitely not use F15 or other chassis changes. I would just just as guide for which sections/FDL's you might want to include.

LCI F3x lacks necessary hardware, so I never code NGHB on those.

[Nezil]

Originally Posted by Almaretto

I would definitely not use F15 or other chassis changes. I would just just as guide for which sections/FDL's you might want to include.

Of course... see next post.

LCI F3x lacks necessary hardware, so I never code NGHB on those.

Was this determined with ISTA testing for the tunnel, or just testing by others?

[Nezil]

Looking at the 72 differences between US and EU FEL ECU Coding, I can see a number of similar line items with the F15. The coding data itself is of course different, but the line items are similar.

Below is a list of the first items with lots of hex data, rather than single bytes. In Black are items only found in the F87, in Red, items only found in F15, and in Green, items found in both:

Stadt_V_Idx
SAE_Idx
H_plus4_Idx
Blendfreies_Fernlicht_Idx
Volles_Fernlicht_Lichthupe_Idx
DRL_Idx
POLI1_Idx
POLI2_Idx
POLI3_Idx
PLI_Idx
WELL1_Idx
WELL2_Idx
WELL3_Idx
WELL4_Idx
FMH_Idx
REMLI_Idx
HBBLINK_Idx
DWABLINK_Idx
PANICMODE_Idx
RAIDALARM_Idx
BLINKEN_Idx
SIDEMRKLGT_Idx

So far a lot of overlap, and nothing additional in F87...

And the single byte list with the same colour code:

HlPrjLabel_HlType
H1PrjLabel_H1HistoryNumber
H1PrjLabel_H1Rechtslenker
LmmIdx00_ErrorImpact
LmmIdx02_ErrorImpact
LmmIdx03_ErrorImpact
LmmIdx04_Intensity
LmmIdx04_TimeOn
LmmIdx04_TimeOff
LmmIdx04_ErrorImpact
LmmIdx05_Intensity
LmmIdx05_TimeOn
LmmIdx05_TimeOff
LmmIdx05_Priority
LmmIdx05_RampType
LmmIdx05_ErrorImpact
LmmIdx06_Intensity
LmmIdx06_TimeOn
LmmIdx06_ErrorImpact
LmmIdx06_Priority
LmmIdx07_Intesity
LmmIdx07_TimeOn
LmmIdx07_TimeOff
LmmIdx07_Priority
LmmIdx07_RampType
LmmIdx07_ErrorImpact
LmmIdx08_Priority
LmmIdx08_Active
LmmIdx09_Intensity
LmmIdx09_Priority
LmmIdx09_Active
LmmIdx09_ErrorImpact
LmmIdx10_Intensity
LmmIdx10_Priority
LmmIdx11_Intensity
LmmIdx11_Priority
LmmIdx11_ErrorImpact
LmmIdx12_Intensity
LmmIdx12_Priority
LmmIdx12_ErrorImpact
LmmIdx13_TimeOn
LmmIdx13_TimeOff
LmmIdx13_Priority
LmmIdx14_Intensity
LmmIdx14_TimeOn
LmmIdx14_TimeOff
LmmIdx14_Priority
LmmIdx14_ErrorImpact
LmmIdx15_Intensity
LmmIdx15_Active
LmmIdx16_Intensity
LmmIdx16_TimeOn
LmmIdx16_TimeOff
LmmIdx16_Priority
LmmIdx17_Priority
LmmIdx17_Active
LmmIdx18_Intensity
LmmIdx18_TimeOn
LmmIdx18_TimeOff
LmmIdx18_Priority
LmmReLut_LgtFct0
LmmReLut_LogLmpLow0
LmmReLut_Idx0
LmmReLut_LgtFct1
LmmReLut_LogLmpLow1
LmmReLut_Idx1
LmmReLut_LgtFct2
LmmReLut_LogLmpLow2
LmmReLut_Idx2
LmmReLut_LgtFct3
LmmReLut_LogLmpLow3
LmmReLut_Idx3
LmmReLut_LgtFct4
LmmReLut_LogLmpLow4
LmmReLut_Idx4
LmmReLut_LgtFct5
LmmReLut_LogLmpLow5
LmmReLut_LogLmpHigh5
LmmReLut_Idx5
LmmReLut_LgtFct6
LmmReLut_LogLmpLow6
LmmReLut_LogLmpHigh6
LmmReLut_Idx6
LmmReLut_LgtFct7
LmmReLut_LogLmpLow7
LmmReLut_LogLmpHigh7
LmmReLut_Idx7
LmmReLut_LgtFct8
LmmReLut_LogLmpLow8
LmmReLut_LogLmpHigh8
LmmReLut_Idx8

So here there are many more differences, and a lot more differences in F15 than F87.

There are a few other differences in F87 that aren't reported in the F15 document, but these appear to be power related things, with mentions of current binning, duty cycle etc.

Finally, two other differences that may or may not be relevant:

LM_ID_LT04
LM04_Name

The other relevant point to note is that the F15 document says to remove 8S4 and 5AP from the FA, and VO Code BDC_BODY (equivalent to FEM_BODY in F87) and KAFAS (equivalent to FAFAS2 in F87) or KFA depending on which is present, and both FLE.

As I stated earlier in this thread, removing 8S4 and 5AP from my FA results in no changes at all in KAFAS2 or FLE, and only differences in FEM_BODY. 2 of those differences appear when removing 8S4 and I can confirm enable VLD, and 1 difference appears when removing 5AP and is therefore related to NGHB.

This would indicate to me, that assuming no hardware limitations, changing the 1 item in FEM_BODY and the 34 items in FLE might enable NGHB in the US LCI F87 with adaptive LED and KAFAS2.

I guess it might be necessary to also set something in KAFAS2, but I'm unclear why this isn't being indicated by the EU VO coding.

Thoughts Almaretto? Care to be the guinea pig ZPrime

[Almaretto]

Originally Posted by Nezil

SIDEMRKLGT_Idx
LM_ID_LT04
LM04_Name

These have to do with amber sidemarkers.

[Nezil]

One other hardware related thing to post today, then I'm going to sleep!

I took some photos of the F87 LCI headlights this evening, whilst on, and at an angle so that the beam pattern coming from the lamp itself can be seen on the plastic of the front of the housing.

The dipped beam appears to be made of 6 or 7 segments. In dipped form, there is a center circle, made of two semi-circles, and four outer sections surrounding it:

When the lights move in the various VLD behaviours, this pattern doesn't change, it just moves left right, up or down.

In regular high beam, which is all I have currently, the beam moves back to the standard VLD disabled position (straight forward basically), and the bottom section of the beam pattern appears unchanged, but the top seems to now be wider, and formed of 4 sections:

I wouldn't say this was conclusive evidence for hardware compatibility by any means, but it's nice to see that the individual sections of the lamp are able to move as needed, potentially creating a tunnel... perhaps...

[Almaretto]

Code 1-34, except set try SIDEMRKLGT_Idx 00 00 00 01 00 00 00 00 00 00

[Nezil]

Originally Posted by Almaretto

Code 1-34, except set try SIDEMRKLGT_Idx 00 00 00 01 00 00 00 00 00 00

Will be trying this tonight after my kids go to bed. I've also got to enable C_HBA_EN in FEM_BODY. I might need to do something in KAFAS2 as you suggested earlier, but I'm not sure about that yet. Will test without first.

[Almaretto]

Originally Posted by Nezil

Will be trying this tonight after my kids go to bed. I've also got to enable C_HBA_EN in FEM_BODY. I might need to do something in KAFAS2 as you suggested earlier, but I'm not sure about that yet. Will test without first.

That would have been coded correctly with VO coding alone in FEM.

[Nezil]

Originally Posted by Almaretto

That would have been coded correctly with VO coding alone in FEM.

True, but I'm well past VO coding FEM_BODY. There are a lot of other useful things you can change in that ECU and VO coding would loose all of that. Far easier to use the NCD compare and see what I need to change, and make that change manually.

After the issues I had initially, I now have backups of factory stock, and of each .ncd file every time I make a change. These are all stored locally, and in the cloud.

[Nezil]

OK, I've just got back from testing, and I have some good news, and some bad news...

The good news is that the coding (34 items suggested by Almaretto and 1 additional item in FEM_BODY; I didn't change anything in KAFAS2, because there were no differences between EU and US for that ECU) didn't appear to break anything. My headlights didn't melt, and VDL worked exactly as it had previously, which is to say, great.

The NGHB, activated with the Auto High Beam button, does certainly do something. High beam comes on a lot more often, and I can clearly see the high beam moving around, right and left independently, and for the most part, seems to be working.

The most common behaviour I noticed, was the driver side high beam not on (because of on-coming traffic), and the passenger side high beam on, but pointing quite far out to the right.

In one or two situations, I experienced the opposite behaviour, where I went to pass a car, but there was no on-coming traffic. In this case, the driver side high beam was on, but the passenger side not.

Most of the time in these single sided behaviour modes, I could see the light cut off at some point in the trunk level of the car in front, just as it would be with regular dipped beam. Lower cars though, like the Mini, and I can't say for sure if this would happen with regular dipped beam, there did seem to be some illumination into their cabin.

What I think might not be working, is tunneling. This is the rarest behaviour to see, because you need to have a single car in front of you, and no on-coming traffic. Only in this case should the headlight beams part, and give you a tunnel around the car in front.

I tried hard to get into a situation like this, and I'd say it's inconclusive if it's working correctly or not. In most cases, I could clearly see a shadow of the car in front as we went under bridges etc, which lead me to believe that it wasn't tunneling correctly. Having said that, most of the time the interior of the car in front wasn't illuminated at all.

I didn't get flashed at all during my ~45 minute drive, but I think I might have caused some drivers to move over. This could have been because I was dazzling them in their rear-view mirror, but it could equally well have been because I was following pretty close at times to test the different NGHB behaviours.

It's pretty cool to see all of this happening, but I'm not convinced it's safe to use yet, so I've reverted back to stock + VLD for now.

Almaretto, would you be able to give some assistance in getting the test beams up in ISTA? ZPrime, where have you got to? We were supposed to be going through this together ;-)

[ZPrime]

Nezil It's cold in my garage... Hard to get the motivation to go out there and screw around when I can barely feel my hands. I also have been hooking the car up to a battery charger when playing with coding, which is more hassle than anticipated.

I also ran into all sorts of weirdness with E-sys and my coding laptop when I just tried to enable Euro parking lights... strange stuff with the descriptive text not appearing in E-sys for some reason. I think i may have resolved this by uninstalling and re-installing both esys and the Launcher, but I haven't gone back out to the car to screw with it again.

I'm really sad that I can't set my indicators to blink 5x; for some reason all of the coding guides mention this but fail to mention that it's apparently impossible on newer releases of car firmware.

The european parking light definitely works though, and it's exactly what I was hoping for. Literally one entry to change in FEM_BODY. Turn off car, move indicator stalk, and the rear parking light and front angel eyes on that side of the car illuminate. The cluster even gives you a warning that you've left the light on.

I also haven't had my break-in service yet, and I'm wary of doing any major coding changes for fear that it will cause problems with any software updates they need to do (i.e. cluster software update/recall to fix the failure-to-turn-on bug).

I'm probably going to turn on VLD after your positive experience there though.

[Nezil]

Originally Posted by ZPrime

Nezil It's cold in my garage... Hard to get the motivation to go out there and screw around when I can barely feel my hands. I also have been hooking the car up to a battery charger when playing with coding, which is more hassle than anticipated.

I also ran into all sorts of weirdness with E-sys and my coding laptop when I just tried to enable Euro parking lights... strange stuff with the descriptive text not appearing in E-sys for some reason. I think i may have resolved this by uninstalling and re-installing both esys and the Launcher, but I haven't gone back out to the car to screw with it again.

I'm really sad that I can't set my indicators to blink 5x; for some reason all of the coding guides mention this but fail to mention that it's apparently impossible on newer releases of car firmware.

I also haven't had my break-in service yet, and I'm wary of doing any major coding changes for fear that it will cause problems with any software updates they need to do (i.e. cluster software update/recall to fix the failure-to-turn-on bug).

I'm probably going to turn on VLD after your positive experience there though.

Definitely make sure your E-Sys is working properly... I'd hate for you to have issues there.

I've kept backups of my car and before the break in service I plan to reset all the coding back to stock. It's less than a 5 minute job, and I have records of everything I've changed and I figure it's safest to put it back that way before it goes in, particularly, as you said, because of the cluster issues.

I've not found the battery issue to be that important. E-Sys allows you to code off-line, so the actual time spent in the car is minimal. In most situations I don't even start the engine, just put the ignition on, because I know I'll be done in less than a few minutes.

I'm interested in the Euro parking lights... what behaviour is it that's different from ours and how do you enable parking lights after coding?

[ZPrime]

I edited my post after you quoted me, the Euro parking light thing is described in there. It's designed to be used on an unlighted street, to help make the car more visible to traffic.

You're looking for
FEM_BODY - 3060 - PARKLICHT_MOEGLICH
Flip it to the reverse of whatever you are now (I think it defaults to nicht_aktiv in the US and you just have to change to aktiv)

My parents' house is right by a curve on an unlit street, and occasionally cars blow through it pretty quickly (marked at 25mph). My brother and I usually park in the street when we visit our parents, to avoid tree sap and/or so we don't block each other in the driveway. The side light feature helps make the car more obvious in case someone is not driving in their lane correctly...

I actually used it on Thanksgiving, it was cool.

Ohio law actually specifies that a car should be parked with parking lights lit if it's on a dark street; the Euro coding tweak allows you to just light the outer side of the car rather than the whole thing. Ironically, my local police apparently know nothing of this law, because they have come and knocked on the door at the house when my brother and I leave cars parked with the light on, telling us that it "draws attention from thieves" and other silly BS.

[Nezil]

Originally Posted by ZPrime

Turn off car, move indicator stalk, and the rear parking light and front angel eyes on that side of the car illuminate. The cluster even gives you a warning that you've left the light on.

Ah yes... I remember this from when I lived in England! I'm embarrased to say I'd forgotten about it entirely but you just brought it all back. It's a cool feature, might add it myself...

[Nezil]

I thought this would take a bit longer than it did, but I have some video captures from my dashcam that I can share...

First off, an example of the NGHB high beam to the right behaviour. In this clip, you can see the beam come on, go off, move around etc.

This next video gives an example of where I think the tunneling isn't happening. From around 18 seconds, I come up on another car, and I seem to have full high beams on it.

[ZPrime]

Nezil
When you turned on VLD, did you "manually" make the changes via FDL coding?
Or did you edit the FA directly to remove 8S4 option, and then VO-code (which should basically do the same thing?)

[Nezil]

You're right that VO coding would achieve the same thing, but it also sets the ECU back to factory default, and you've already coded a lot of other things in FEM_BODY.

What I find is the best approach is to create a set of 8S4 removed VO coded .ncd files offline, and then use ncd compare to see what changed between that, and the factory backup that you made of your car before you started, or you created using verify coding if you forgot.

This will tell you what changed when you removed 8S4 and only what changed. You can then edit the latest .ncd file that you're using manually and add those things.

That's what I do anyway.

[ZPrime]

So if I'm going to remove 8S4... and I haven't done anything with FEM_BODY, is there any reason not to just VO code instead, and then go back and FDL code to make my other changes?

Or is 8S4 only a few items in FDL anyway?

[Nezil]

Originally Posted by ZPrime

So if I'm going to remove 8S4... and I haven't done anything with FEM_BODY, is there any reason not to just VO code instead, and then go back and FDL code to make my other changes?

No, no reason at all, except for the knowledge of what has changed, which I personally like to know.

Or is 8S4 only a few items in FDL anyway?

Also correct, only 2 things I think actually. I can't remember off hand exactly how many things, but not more than 3 for sure.

[Almaretto]

Originally Posted by ZPrime

So if I'm going to remove 8S4... and I haven't done anything with FEM_BODY, is there any reason not to just VO code instead, and then go back and FDL code to make my other changes?

Or is 8S4 only a few items in FDL anyway?

No reason. Though, it is only a few FDL changes.

[ZPrime]

So on the flip-side of this, if I remove 8S4 by just doing FDL coding... shouldn't I also alter the VO/FA on the car to reflect that it isn't there anymore? If the FDL codes to remove/revert 8S4 are set, but the FA still includes the 8S4 option, doesn't that make the coding on the car "wrong" or "invalid" if BMW techs were to need to scan it for some reason?

I know there is an analogue to this in VW/Audi world; when you add or remove a module in a car, you have to update the CAN Gateway to reflect the addition or removal. If you don't, everything will generally still work, but the CAN Gateway will throw an error when scanned that it is "coded incorrectly."

[Almaretto]

Originally Posted by ZPrime

So on the flip-side of this, if I remove 8S4 by just doing FDL coding... shouldn't I also alter the VO/FA on the car to reflect that it isn't there anymore? If the FDL codes to remove/revert 8S4 are set, but the FA still includes the 8S4 option, doesn't that make the coding on the car "wrong" or "invalid" if BMW techs were to need to scan it for some reason?

Do not overcomplicate things. The car does not care what is or is not in VO. Either load modified FA and VO code or FDL code, not both.

You want factory FA to remain just that (ie untouched).