RGB PWM Dimmer Steps - improvement in softness for lowlight situations #6942
Comments
|
Tasmota is already doing Gamma correction with a 10 bits resolution which is more or less the maximum possible with Esp8266. You can try disabling Gamma correction with |
|
This Ledtable setting doesn't work properly. assumed color 00000000FF (only white channel)
|
|
This is indeed not normal. I will have a look. What device was that? Sonoff B1? What Tasmota version? |
|
I tested it right now with a MagicHome single channel (Profile Arilux LC11 Modul) on color 00000000FF
|
|
This is an old version and core 2.3.0 had pwm issues preventing from full power. This is solved in latest release. Please use the latest stable release 6.7.1 |
|
Ohh, flashed a week ago, wasn't aware of a new version in the meantime. Tested on MagicHome with single channel 00000000FF looks indeed better. But on a sonoff B1 it looks crazy. If you want to have full brightness on a B1 you use FFFFFFFFFF so RGB is on max white as well as WW and CW. Set color FFFFFFFFFF, speed 10, ledtable 1 and dimmer 0. Then set dimmer 100 and look at the lamp. It dims up until a certain point. then it witches down to maybe 50% and dim up again to 100%. This cannot be correct. Edit: this behavior on B1 is only with Ledtable 1. On Ledtable 0 the dimmer proceeds normal. Also the dimmer 100 to 0 is much faster than dimmer 0 to 100. I would further say factor 10 or more. Edit: this behavior on B1 is only with Ledtable 1. On Ledtable 0 the dimmer proceeds normal speed up and down.
|
|
Will try later with my Sonoff B1. Please note that Sonoff B1 uses hardware PMW with only 8 bits resolution. Can you please send the output of |
|
Below all requested:
|
|
Below the details for MagicHome 1ch dimmer. With this device the down/up period seems to be the same length, also with ledtable 1 if the values are larger. dimmer 10 is further longer than dimmer 0 (from 10). I have a 12V 5m LED Stripe single color on this controller. The dimming is smoother but I see folowing behavior by fire commands after eachother dimmer 0 - off Here the details for this device. I'll try to make some measures with my pocket scope tomorrow to check whether the PWM changes between dimmer 2 and dimmer 7
|
|
I've made a test with my cheap scope. There is indeed no change in PWM from dimmer 1 to dimmer 7. Dimmer 8 to dimmer 10 are on the same PWM and dimmer 11 is a change again. I added a few shoots from scope. Measured on 12V output of MagicHome dimmer 1 to dimmer 7 dimmer 8 to dimmer 10 dimmer 11 |
|
What you are seeing with MagicHome is normal. The human eye is VERY sensitive at low brightness, and there is not enough resolution with 10 bits to accurately represent every Dimmer value. Note also that Dimmer is of range 0..100 while the internal value is actually 0..255. The Gamma table used internally is as follows: We could force to have a change in brightness as every step but it would corrupt the perceived linearity of the light at low brightness. As said previously that's the best we can do with 10 bits resolution. I will look at the Sonoff B1 issue which looks to be something different. |
|
You are totally right, the human eye is very sensitive at low brightness. That's why stuttering in low level dimming is more anoying than stuttering between 80-100%. That's why I mean in the low level dimming there should be more steps per percent and in the higher level of dimming can be less steps per percent. With ledtable 0 it looks like we have a change on each percent. I don't know whether it is an inaccuracy of my scope but the step in dimmer 5 looks out of order (step is to large). I assume that we see a flicker between dimmer 4 and dimmer 6. I doesn't know the formula behind but also if 100% dealed into 255 steps a linear increasing should be possible Below the PWM with ledtable 0 - dimmer 1 to dimmer 6 |
|
I just don't see how this would be possible with 10 bits resolution and keeping a perceived linearity. We could tweak the Gamma table to force different values for Dimmer values, but that would also be artificial, since Dimmer is of range 0..100 while internally channels are of values 0..255. For example, if you want different PWM values for Dimmer 0..20, that would mean that Dimmer 20 has the PWM value 20, which would be equivalent to 25% of perceived brightness instead of 20%. Put differently, 10 bits PMW is not capable to accurately distinguish between 1%-4%. Why is it a problem if Dimmer 1 and Dimmer 2 have the same brightness? |
|
I just tested Sonoff B1. It uses My92x1 hardware PWM drivers, and they appear to have hardware Gamma correction. You should definitely use I'm updating the template repository accordingly. |
This is maybe not a problem at fade 0 or fade 1 && speed 0 (you only see no different on command dimmer 1 to dimmer 7, what a user doesn't expect but it can be explained) But it is a problem if you use fade 1 and e.g. speed 10. The time runs linear. Let's assume 100 seconds for easy calculation. This is the same as if you execute dimmer 1 to dimmer 100 with a second delay each. You set dimmer 50 and the cycle starts. Now you see LED turns on (dimmer 1). next you see nothing happen for 6 seconds (dimmer 2 to dimmer 7), next you see an increase of brightness (dimmer 8), next 2 seconds you see nothing happen and so on...... I don't know why this so hard to explain. You just have to take a PWM device of your choice, set ledtable 1, fade 1 and speed 10. Then start dimmer 100 look at the LED's and you see the effect I mean. You will see a anoying times of "nothing happen" between 1 and 20 and then a smooth increasing of brightness from 20-100 |
|
Related to the linear dimming (ledtable 0): |
|
Could you make this table accessable from outside via JSON array? The users could play around to define own gama correction?!
|
|
For linear dimmer (I have no clue how it is done actually in tasmota but it looks to me that it is done in 255 steps instead of 1024 steps) I would do it somehow this way |
|
In understand now your issue, I never use Fade. The Gamma tables are defined at compile time and it would take too much Flash and Ram to have them dynamically changed. Can you self-compile and try different values? You can do this locally or via GitPod. The Gamma table is defined in To keep the whole table into 256 bytes, it uses adaptative resolution in each 64 bytes blocks, starting from 11 bits to 8 bits. PWM uses 10 bits and rounds value to the nearest integer, and forces |
|
@Waldmensch1 : danke fürs kümmern :) @s-hadinger : if you never use fade, I understand your priorities, but I think I am not alone as fade user hating visible steps more than not having linearity. |
|
I am reluctant to change the Gamma correction tables and break the perceived linearity of brightness. So it's actually the Fade algorithm that needs to be changed, and there is little reason fading should follow a linear rule. @joba-1 are you working on a PR? |
|
The question is why "fade " is used. The reason is simple. If you use a hardware dimmer with a wheel, you have the efect of a smooth increasing/decreasing of brightness. Same you have on touch Hardware dimmers. A dimmer makes no real sense without fading because without fading it is "jump to a brightness". For "jumping to a brightness" a gamma correction doesn't make sense, because the eye see this jump anyway. The magic is to reach a soft increasing of brightness from 0 to 100% without seeing the steps in between. This is hard because an analog control behavior have to be done by a limitted number of digital steps. I had a look into code void LightFade(void), Without knowlede of the rest of the lights code I would say the fading is done in 255 steps (related to 100%) instead of 1024 possible PWM steps. This would go conform with my observations with scope on linear fade (see screenshots) a few comments above. I think, using 1024 PWM steps on fading would result in a quite smoother dimming |
|
Indeed, but it will need a refactoring of the the way Fade works. Today Fade is done before any Gamma correction or 8 to 10 bits conversion. I agree with your approach, but this means that the Fading algorithm should take place after the begin and end PWM 10 bits values are calculated (after Gamma correction). These are significant changes but worth the effort. Let me take a closer look. |
|
After all it may not be such a big change :) |
I have an unused H801 (RGBWW) for testing beside of MagicHome (W) and have re-installed the PlatformIO environment right now. So if you need somebody for testing - just ask and provide me with a link to your branch. (or send the 04-lights.ino to copy over locally) |
|
Thanks, will do. |
|
Actually I'm not convinced by the way Fade works today. In Zigbee you just specify the time it takes from the start to the end state, whatever the colors. Would it be ok to change |
|
Not sure if I understand correct. I my opinion the speed should be always set to cover the time fading from 0% to 100%. If I am at 50% right now I would expect that dimming to 100% would take half time of dimming 0 to 100. Or I'm wrong? |
|
That's a design choice. Currently the fading algorithm takes the distance between current and target color, and divides the distance by 2^speed at each step. Which is roughly a log function, and not linear at all. I will try to have a constant speed algorithm, meaning that indeed moving from 50% to 100% takes half the time than moving from 0% to 100%. |
|
cool! I did the initial flash for H801 right now. I see that it seems to be that there is also an additional IC hc245 between the ESP and MOSFET. Just the MagicHome seems to not have this. No clue which effect this have for testing. I hope not, because the MagicHome is the hell for FTDI flashing ;) |
|
Can you please try this branch: https://github.com/s-hadinger/Tasmota/tree/fade_dev It not polished but gives you a good idea of the result. There is still a Hue issue I need to fix. For example if you do |
|
checked out your repo and swiched to fade-dev branch without problems. I'm able to build this with PlatformIO but the .bin is not flashable OTA. Not tasmota and also not tasmota-DE if I build this. sonoff-DE (actual release) is flashed actually. The Error says "Upload Buffer compare differs". Is there any flag to set while compile to get that flashed OTA over the actual sonoff-DE release? Only thing I changed is to include my user_config_override.h
|
|
You need to flash a tasmota-minimal first, then the target firmware. This is because they are bigger than 512KB and you need to fit 2 firmwares in 1MB flash. |
|
Here is a compact firmware of the |
|
got it already :) Do yo have a special test-scenario where I should look at? |
|
Nothing fancy. And so on... |
|
WOW!!!! That works AWESOME!!! Edit: Tested on H801
At all you are very close to perfect! |
|
Thanks. Does it feel natural that moving from FF0000 to 000000 takes twice as long as moving from 800000 to 000000? |
|
For me this is okay. I would expect that behavior. |
|
Currently So |
|
I think I will leave it that way. Maintaining Hue values when scaling will add a lot of code - maybe too much. |
|
I never changed sleep, a check shows 50 I never measured the time 0-100 so I don't know how large the different is to your version. By the way, it's hard to measure, because the changes in the higher region are not really detectable for human eye. So I'm not able to see when dimming is at 100% |
|
There is maybe something wrong. I found the command WakeupDuration and Wakeup. I never used that before. By reading documentation I would assume:
If I set WakeupDuration 1000 and wakeup 100 after eachother nothing happens. To reproduce:
|
|
I think that Wakeup call is independent from Dimmer. Did it work in the standard Tasmota version? Or did I just break it? |
|
I tested the same on MagicHome single Channel 00000000FF (actual sonoff release) right now - it shows the same behavior. It's more strange than thougt before. If you have do
Good news, you made nothing worse, the bug is in actual release too ;) |
|
I rebooted the magicHome and switching dimmer 1 and dimmer 0 back and force works like a charm. So I asume that fire the wakeup "destroys" something |
|
I think it's a very old bug and it looks that nobody is using this feature lol |
|
I think too. Maybe "wakeup" was introduced before "Fade" which does nearly the same. I don't know what wakeup does internally but I would assume that it is a loop which fires dimmer commands every (WakeupDuration/ wakeup value) seconds until wakeup value is reached. So it could be used for long duration sunrise scenarios. Max value for wakeup is 3600, so 1hr. Could be a nice gimmick to illuminate a large translucent wall-filling image in your room with a few LED stripes behind. |
ghost
mentioned this issue
Have you looked for this feature in other issues and in the wiki?
yes
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
If you dim an RGB device e.g. from 20 to 0 the single PWM steps are hardly visible which doesn't look soft at all.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I know that we have a limited number of PWM steps to cover the 0-100%. My observation is, if you dim e.g. from 80 to 90 it is very soft but if you dim from 0 to 10 you see each single PWM step. I assume that the number of PWM steps per percent value is static (same number of steps from 0 to 10 as from 80 to 90). I counted 2-3 steps per percent value in the low region.
So the Idea is to use more PWM steps in the low region (0-20), maybe 10 PWM steps, and less steps in the higher region. Finally in the region 80-100 one PWM step per percent would be enough without seeing any flicker. I have no clue whether a logarithmic function or a linear function is better there to calculate the PWM steps from percent value. This have to be tested but I assume a logarithmic decreasing of PWM steps per percent value should have the most benefit to get as much as possible PWM steps in the low dimming region.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I found an explanation and a sample code here. (German language) https://www.mikrocontroller.net/articles/LED-Fading
Additional context
Add any other context or screenshots about the feature request here.
I tested the behavior on a MagicHome and H801 and also on a sonoff B1 with single white channel. They show exactly the same behavior. So I assume the steppy lowlight dimming onnly can be fixed on the PWM step calculation.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: