-
Notifications
You must be signed in to change notification settings - Fork 70
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
WIP: Add RGBW strip support #101
base: master
Are you sure you want to change the base?
Conversation
@ebrearley Hi, any plans continuing work on this? |
@ebrearley, I'm in need of this. Are you going to continue with what you mentioned above? Mind if I tag in to get through some of it? |
@che-effe I reckon this is stale now, so if you are feeling up for it then I can help guide you on what needs doing. |
@ajfisher I'm in! I'm going to fork from @ebrearley 's work and get myself up to speed with what he had completed. Unless you think I should start fresh. |
@che-effe i am also testing on a arduino nano and 60 sk6912 leds right now. If u like i can also support your branch. I really want to get this working in the next few days. The firmware looks good, i got these leds working with the adafruit lib, fastled and jinx! |
I currently have bandwidth for this. Giving it a shot this week. Will be on vacation for a bit but still planning to work. would love a bit of guidance on where to pick up from here. I have a forked branch here https://github.com/che-effe/node-pixel I made sure to update from latest master and will continue there. |
I played arround a bit with all the libs and stuff. Basiclly its not that hard because when you think of the problem twice, you just have to convert rgb to rgbw right before sending data to the leds at the arduino side, doing changes at the javascript side is not needed. 255 255 255 converts to 0 0 0 255 The formular is pretty easy: w = math.min(r,g,b); There are also more advanced formulars to extract the white value from a color, but this one works very well. |
So there are a couple of things you want to account for:
The first is that like the RGB channels, the W channel can work entirely
independently of the others. As such, in order to represent what is going
on at a per pixel level you'll need to account for having a 32 bit value to
represent each pixel. This will have *massive* bandwidth implications so
you definitely don't want to do this as a default.
Now as far as usage goes, typically you don't really use the white channel
at the same time as the other three - ie you wouldn't typically go RGB
(255, 0, 0 - Pure Red) and then have w = 255 at the same time. Though you
technically could do this, the pixel is likely to just drown out in white.
The normal reason people use RGBW pixels is because you get a more pure
white if you want to use them as white rather than trying to blend RGB
channels together into white (which will typically always end up with a red
cast due to voltage issues).
So my suggestion is to introduce a couple of new modes. The first is to
enable it to set the channel size to 4 bytes instead of three. Then you'll
need to send RGBW commands in all the pixel / strip colour setting
commands.
The other mode you'll want is to send a white only channel mode (ie 1 byte)
and then send the data on only the white channel for the pixel values. This
would give you a considerable speed improvement as well.
…On Tue, Jan 15, 2019 at 7:21 AM Charles F ***@***.***> wrote:
I currently have bandwidth for this. Giving it a shot this week. Will be
on vacation for a bit but still planning to work. would love a bit of
guidance on where to pick up from here. I have a forked branch here
https://github.com/che-effe/node-pixel I made sure to update from latest
master and will continue there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHRo2idBtMoQsP0_D3D6ug33G-NRdN7ks5vDRD4gaJpZM4NqHHa>
.
|
Any body on that in 2023 ? |
I don't have any of these strips to build and test with, however process
for this is more or less as described. You need a fourth byte to drive the
W channel and then you can set that separately.
…On Fri, 27 Oct 2023, 23:03 Andréas Hanss, ***@***.***> wrote:
Any body on that in 2023 ?
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA5DIYWWGXJSFAB3LOWXP3YBOPIBAVCNFSM4DNIOHNKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGI3TSNZZHEYA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Add RGBW and SK6812 support
This PR is aiming to address both
Description
This is VERY much a work in progress. In fact what I've done in this first iteration is a bit of an educated and guided hack to get the hardware to light up correctly, as a proof of concept.
I have a tangible result with this however, I am able to address LED's individually. Win!
The strip is currently only showing blue and green colours, and it looks like:
WIP gif:
johnny-five controlled RGBW SK6812 LEDs! (well kind of)
Plan
Once I get this working, I'll go back and refactor what i've done to add RGBW as an optional parameter OR as a initialisation configuration option.
johnny-five