Rgb dimmer: completely deactivate leds and add brightness message

[wurststulle]

• disable COM0A1 and COM0B1 when value is 0 to deactivate the leds completely
• add message to set the brightness of the rgb dimmer

[breaker27]

1) How is the behavior when brightness is set? Do I understand it correctly that it is an additional factor? So I may set color "white" and can dim it with brightness or can set "yellow" and dim it with brightness?

2) What is the advantage turning COM0A1 and COM0B1 off? If the threshold for the timers is 0, the pins should be off already, right? Isn't this only additional (unnecessary) code?

[wurststulle]

1) yes. 2) no. When the timer is 0, the led is still in. With minimal intensity, but on. Turning both off will turn the leds off completely. Am 14.02.2015 19:35 schrieb "breaker27" notifications@github.com:

1) How is the behavior when brightness is set? Do I understand it correctly that it is an additional factor? So I may set color "white" and can dim it with brightness or can set "yellow" and dim it with brightness?

2) What is the advantage turning COM0A1 and COM0B1 off? If the threshold for the timers is 0, the pins should be off already, right? Isn't this only additional (unnecessary) code?

— Reply to this email directly or view it on GitHub https://github.com/breaker27/smarthomatic/pull/123#issuecomment-74386501 .

[wurststulle]

1) its working fine for blue, i dont know why. 2) i am fine with both, not sure whats the better solution.

[breaker27]

I fixed the bug that the LEDs are not completely off with color 0 (see https://github.com/breaker27/smarthomatic/commit/c56586adc180563274ef0da86f03ecb372bbe9f6). This is for the 0.9.0. For the brightness feature, I'll look at it later (>0.9.0).

[wurststulle]

This will fix the issue at 0% duty cycle. But now you have it at 100%. So it will jump between 99 and 100%. This is imho even worse.

[breaker27]

What do you mean with "jump"? I tested several colors (incl. white) and see no problem. What do I have to set as color or animation that I will see an issue?

I measured it. The peak is roughly 8µs with OCR0A = 0 and inverting PWM. This is about 3.8 permill of the duty cycle at 480 Hz. I see no problem that the LED is "only" 99.62% on.

With non-inverting PWM, I measure a peak of 30µs (with OCR0A = 0). This is much more and the resulting 1.4% "on" (when it's intended to have the LED off) is visible.

So at least for 0.9.0 my fix seems to be reasonable to me.

[wurststulle]

In fact i dont like it when something is supposed to be off but is still in for some time. Imagine you are using something else then leds, e.g. a fan. I dont know if it is a problem, but it does not feel right.

[breaker27]

I've to correct the times I mentioned. It is 8µs for both inverting and non-inverting mode with 480 Hz PWM. The rest is correct.

You write in the last message that something should not be on when it's supposed to be off. But this is also not the case anymore after the fix! When OCR0A is at 255 with inverting PWM mode, the LED is 100% off.

Where do you see a problem? I don't get it.

[wurststulle]

when its completely off its ok. regarding the 100%: with the non inverted implementation, you got spikes at 0% duty cycle. if you invert it, you got them at 100%. i dont know if you see these changes from ~99,4 to 100% and back. i will test it this evening. if you cant see it, lets do it this way.

[breaker27]

I solved it by using the phase correct PWM mode (submitted to the develop branch). This creates duty cycles of 0..100%. I didn't integrate it in the 0.9.0 though, because it needs more testing.

[breaker27]

Forgot to mention: Brightness message will be added also (separate issue).