Quote:
Originally Posted by VipinLJ
I had some free time today to try and "decode" the three sets of hex values under 360A.
In my car, bronze has been changed to red. Bronze and white is red map spotlights/door handle & pocket lights/footwell lights and blue dash/door strips. Now the issue we had was, when the ambient light is set to the bronze white (red blue) option on the idrive, the map lights wouldn't turn on until we switched it to another color and back again. The work-around I found was to reduce the intensity of the red by a notch so that the map lights turn on as well. While it wasn't very obvious, there was a slight pinkish hue to the red and it was bothering me a wee bit (though it didn't bother me initially). I wanted it to be pure red.
andy5468 and Joedeejay gave me an idea. Since coding became significantly faster with a wired enet cable and USB c adapter (I wouldn't have done it if I was using obdlink), I thought I'd try and decode the values. I decided to replace bytes 18,19,20, 23,24,25, 28,29,30 individually with 90,E0,90 to see which lights turned white and which stayed red.
My findings:
1. Bytes 18,19,20 - door handle and door pocket lights
2. Bytes 23,24,25 - Footwell lights
3. Bytes 28,29,30 - Map lights front and rear (small spot lights next to the dome lights)
So I replaced bytes 18,19,20 and 23,24,25 with FF,00,00 and left bytes 28,29,30 as is (FE,0A,0A). Result is pure red lights in easily visible areas (door handles, pockets, footwell) and a map light that always turns on (though with a slight pinkish hue noticeable only to me and not the others in the car since they aren't crazy like me).
|
Nice catch. I can confirm that ANY of the three colors (RGB) set to FF with all 0000 in the other bytes results in the built in ambient lighting on the roof function module not working until switching colors.
I was able to replicate the issue with 00FF00 and 0000FF for the other solid / non mixed colors.