-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixed offsets and inverted signal plus dead time #4126
Conversation
- renamed variables - some tuning
I think this does it. I tried to optimise a bit (inverted signal is inverted on all channels so needs no special treatment). |
it does not ;)
I will fix these points, test and commit. |
Turns out this is a nice brain gym! 😄 I think there is no distinction between normal and inverted signal. It is just the logical interpretation of the brightness slider orientation. If it is set to 32 or 224, dead time follows the pulse regardless of its width. And hPoint is just the amount of time (in single bit pulses) that need to pass before the output goes high. So if our duty is 32 with a dead time of 2 our hPoint will be 34. Similar when 224, it will be 226. So the second output will be delayed appropriately. Remember that the second output is also inverted and the sum _data[0]+_data[1] is always less or equal to 255. |
you forgot two things: |
I will trust you on this. 😄 There is a small error though. |
@DedeHai are you comfortable if I merge this? I will then PR bus config branch. |
sure go ahead, I tested the CCT signals and they were looking good, also RGBW was ok. I did not test multiple RGB outputs (I did test the timer assignment earlier and that code did not change). |
No description provided.