hyperion.ng
hyperion.ng copied to clipboard
Implement RGBW support more generically
At the moment, only SPI provides support for RGBW strips - what if they're on a usbasp or arduino over serial ?
Well, then you need additional code for hyperion and device? (FastLED, usbasp). Something like a RGBW pre processor for cleaner code on hyperion side?
Nope - btw, this is really a reminder for me !
The byte format on the wire is the same it's just that each led gobbles 4 bytes, not 3.
There are some led types that need special timing after each led, but ws2812 and sk6812 are a simple long burst of led bits
Oh, slightly OT. Did you had a hands on at the WS2815?
I saw the specs for ws2815, are the easily available right now? btw if we need rgbw frmware for arduino, this should be noprob. Thing is the led driver, unless fastled is not read for rgbw we can't show the leds. But we can prepare it from protocol side and then we are ready when fastled is ready
I suspect the ws2815 is on the same Shelf as hens teeth !
The arduino probably doesn't care much. Certainly the sk6812rgbw is the same timing as the ws2812 - you just need to throw more bytes at it (4/3rds more to be specific.
If we did support 'W' in the internal processing, should we consider one big change and move to 16 bit depth throughout ? Pros; HDR video is 10 bit there are some leds that do 10 bit Better precision for colour transforms and smoothing We could support temporal dithering on some leds Cons: Performance ? Hopefully little as it's a 32/64 bit CPU Memory ? Meh!
all grabbers (inputs) are 8bit rgb therefore I doubt it is useful to switch the whole chain to rgbw. I can imagine that the general output buffer is rgbw and w is always calculated according the setting of leddevice. This could mean in Hyperion::update after image processing we recalculate the whole buffer and put it to smoothing/leddevice. This would eliminate rgbw calc in leddecie itselfs and is available for all devices. This minimizes code dups regarding settings and calculation too
would it be doable to make a RGB to RGBW translator using an esp8266 JUST for this purpose? I know its crude but I've grown tired. It will add some latency, but it will take some load off the main mcu
If the led data is being sent over wifi to an 8266 then yes, it should be easy. It isn’t a 5 minute job on the espixelstick code that I started adding RGBW support to but I probably missed something silly.
If you want as 8266 connected as a ws2812 emulator then that is probably pushing it due to the timing constraints.
A serial attached 8266 or any other arduino would be easy
And what happens when you need the white channel for a device where you can't hook something in between?
I desided to work on rgbw due to colour uniformity and potential lifespan increase for the leds. Lets say you have a display made out of 2812 or sk6812, and you want it to display a gif. Each pixel on that gif is made of rgb, so its simple (in theory). in case of rgbw you'll probably need to take the common minimum orf rgb, subtract it from each corresponding channel, and add it to white channel (the intensity should be the same, and the leds happier that rgb). IF this works, even roughly, you can use all the work that's been done around rgb pixel leds. @penfold42 The reason I was thinking the esp is due to its better processing capabilities and low cost. I haven't even considered timing problems, as I'd be satisfied even with a static image, at this time. @brindosch I don't think it would be of any help in that case unless you can physicly bypass the data line directly on the board (and add a jumper just in case)
I happened to bump into this after the post, which is probably better than my rough idea: http://codewelt.com/rgbw
Just so we’re clear - did you know we already have RGBW support for SPI and PWM attached leds ?
Thanks for the codevelt link - I think that would be a good third option. We already have white off and subtract minimum (as you described)
Hey, i just wanted to ask if RGBW over an Arduino has any benefits over normal RGBs at the moment.
@Lord-Grey denke das wird in Zukunft auch noch interessant sein für die LED devices...
Is there any discussion on RGBW support for WLED devices? WLED supports RGBW over UDP. I can't imagine it would be too difficult to implement a version of this for WLED. I would take a crack at it but I'm just too busy with other projects at this time. I've got 288 sk6812 LEDs on the back of my TV just waiting for Hyperion RGBW over UDP support. For now, WLED looks great.