[Rotary Rasp]

I remember someone asking this a few weeks ago so I thought i'd give it a shot.

It's actually very easy. I've attached a screen shot of the HEX code that needs to be changed. The HEX file on the left is single blink and the HEX on the right is triple blink. Just change the highlighted characters to any value you want and reflash using the modified NETTODAT file. I changed mine to six blinks.


13 = 4 blinks
17 = 5 blinks
BB = 6 blinks
(thanks srwatters)

[ctuna]

Whats the logic behind this the value changes by a count of 8 for
a 3 blink change . I guess I don't understand the bit mapping or weighting. What is the final value for a 6 blinks?

[Rotary Rasp]

Originally Posted by ctuna

Whats the logic behind this the value changes by a count of 8 for
a 3 blink change . I guess I don't understand the bit mapping or weighting. What is the final value for a 6 blinks?

BB = six blinks

I don't follow the logic either.... but it works.

[ctuna]

How did you zero in on that location at all ?

[fdriller9]

I could have sworn you can do this through the BC menus.

[NiVeDh]

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

I could have sworn you can do this through the BC menus.

Using the BC stalk or iDrive, you can only activate or deactivate triple-blink, not change the number of blinks.

[wrickem]

Wow that's a lot of blinks for a lane change!

[fdriller9]

Originally Posted by NiVeDh

Using the BC stalk or iDrive, you can only activate or deactivate triple-blink, not change the number of blinks.

Ohhhh gotcha. I quickly skimmed this thread. My bad.

[Rotary Rasp]

Originally Posted by ctuna

How did you zero in on that location at all ?

The very scientific method of trial and error. I can't think of any other way until someone figures out the logic or tries all 255 possible combinations.

[ZZZZ]

Thanks Rotary! I'm the one who was asking about increasing the blink count on the soft-touch turn signals! I haven't played with NETTODAT yet, will have to read up on making these modifications! Hopefully will have time tonight to play with it...

[anerbe]

in the BC or idrive, does it change the display to show 6 instead of 3?

[Rotary Rasp]

Originally Posted by anerbe

in the BC or idrive, does it change the display to show 6 instead of 3?

No. And if you change it on the BC or iDrive it will revert back to stock. So it's best not to mess with those functions.

[srwatters]

This is only conjecture, but if you look at it in binary and mask off the least significant two bits (11) that aren't changing and ignore the top three bits, you see this:

0x27 = xxx0 01xx = 1
0x2f = xxx0 11xx = 3
0xbb = xxx1 10xx = 6

Did you try 0x3b or 0x1b? If that also gives you 6 blinks, then my hypothesis would hold. If it doesn't, then the top three bits might have other usage. I would also try 0x17 or 0x37 to see if that results in 5 blinks or 0x13 or 0x33 to get 4.

(I write embedded controller software for a living so this is sort of like a second language...)

[ctuna]

If its a down counter timer then the values could be approximate.

[justa3series]

Use NCSDummy, find appriopriate value then change it. There is no trial and error if you do it right. Max value this takes is 7 and that's way too high. I set 4 just right and 5 is one too many.

[Rotary Rasp]

Originally Posted by srwatters

This is only conjecture, but if you look at it in binary and mask off the least significant two bits (11) that aren't changing and ignore the top three bits, you see this:

0x27 = xxx0 01xx = 1
0x2f = xxx0 11xx = 3
0xbb = xxx1 10xx = 6

Did you try 0x3b or 0x1b? If that also gives you 6 blinks, then my hypothesis would hold. If it doesn't, then the top three bits might have other usage. I would also try 0x17 or 0x37 to see if that results in 5 blinks or 0x13 or 0x33 to get 4.

(I write embedded controller software for a living so this is sort of like a second language...)

I'll give it shot tonight.

[Rotary Rasp]

Originally Posted by srwatters

This is only conjecture, but if you look at it in binary and mask off the least significant two bits (11) that aren't changing and ignore the top three bits, you see this:

0x27 = xxx0 01xx = 1
0x2f = xxx0 11xx = 3
0xbb = xxx1 10xx = 6

Did you try 0x3b or 0x1b? If that also gives you 6 blinks, then my hypothesis would hold. If it doesn't, then the top three bits might have other usage. I would also try 0x17 or 0x37 to see if that results in 5 blinks or 0x13 or 0x33 to get 4.

(I write embedded controller software for a living so this is sort of like a second language...)

You are 100% correct 0x17 = 5 blinks and 0x13 = 4 blinks.

Now please explain the logic?

[ZZZZ]

Originally Posted by srwatters

(I write embedded controller software for a living...)

I never would've guessed.

Don't leave these forums, you could be useful to us. We'll buy a drink though.

Wonder what else is contained in the NETTODAT file.

[srwatters]

Originally Posted by Rotary Rasp

You are 100% correct 0x17 = 5 blinks and 0x13 = 4 blinks.

Now please explain the logic?

Firmware programmers are notoriously stingy with memory. Unlike application programmers who now have gigabytes of memory to use, embedded software engineers often pack as much as we can into very little space. So if all you need is three bits to control a feature, why use all 8 in a byte? It's also possible that the other bits at this location control or are status or settings for the similar features, like perhaps blink rate or duration. Again that's all just a guess without seeing some source code or design documents on the module.

Having said that, except for in extremely low cost systems, most current trends are to have far more resources than you need. The cost of megabytes now is what we once paid for bits. But if you're selling hundreds of thousands, even a few dimes can make a difference given the count of modules in every BMW.

And I'll stick around. I've only coded a few things that irked me on my two bimmers. Since they're both still under warranty, I'm not messing too much with them. Maybe I need a project car ;-)

[justa3series]

You can use NCSdummy and see what eat bit and value is for the module to code via nettodat.

[Rotary Rasp]

Originally Posted by srwatters

Firmware programmers are notoriously stingy with memory. Unlike application programmers who now have gigabytes of memory to use, embedded software engineers often pack as much as we can into very little space. So if all you need is three bits to control a feature, why use all 8 in a byte? It's also possible that the other bits at this location control or are status or settings for the similar features, like perhaps blink rate or duration. Again that's all just a guess without seeing some source code or design documents on the module.

Having said that, except for in extremely low cost systems, most current trends are to have far more resources than you need. The cost of megabytes now is what we once paid for bits. But if you're selling hundreds of thousands, even a few dimes can make a difference given the count of modules in every BMW.

And I'll stick around. I've only coded a few things that irked me on my two bimmers. Since they're both still under warranty, I'm not messing too much with them. Maybe I need a project car ;-)

Good work. I'm impressed that you were able to figure that out. Now get to work on discovering new features to hack!

[ZZZZ]

NCSDummy -- I'm sold. I searched the thing up, a lot of hard work went into that program. I hope it works well. I also see in the screenshot the one option I want and haven't figured out how to enable---auto lock the doors when driving off. (In e90's built before Sept 2005 this option is not in the OBC).

Sweet deal.