-
-
Notifications
You must be signed in to change notification settings - Fork 269
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
Official Support for UCS2904 NeoPixels #871
Comments
https://www.artleds.com/images/Specs/UCS2904-Datasheet.pdf In NPB, the UCS8904 is just a "feature" selection, so color order and color bits. Adding one specific to UCS2904 should be just as simple. It just aliases the generic RGBW feature. Now, the next issue is getting WLED to expose the name. It will just wrap the current generic RGBW feature. And this could be done within WLED without a change here. But I will add the wrapper since I have one for the sister chip UCS8904. |
In WLED, I configured UCS2904 like this: Type: SK6812/WS2814 RGBW |
if you add the wrapper, I'll open a PR for WLED. It'll be dependent on what ever version of NPB you release under, of course. Thanks! |
Pure NPB code. It works great with my UCS2904 pixels.
|
This reverts commit 19da765.
A lot of NeoPixel pucks that are available are using the UCS2904 chips. These are RGBW, with 8 bit dimming per channel. It's looking like these are similar to the UCS8904 chips that are already supported by NeoPixelBus. The difference is, UCS8904 is 16 bit dimmable per channel.
Source: https://www.artleds.com/blog/ucs8904-ic-pixel-protocol-overview
I have some of these UCS2904 chips. I'm running them with WLED, and they seem to be working fine. I'm sure you're aware, WLED uses NeoPixelBus for the interface to the NeoPixels.
What is required to officially support a chip / protocol? I would be willing to execute what ever test is needed.
The text was updated successfully, but these errors were encountered: