hyperion.ng icon indicating copy to clipboard operation
hyperion.ng copied to clipboard

Implement RGBW support more generically

Open penfold42 opened this issue 7 years ago • 15 comments

At the moment, only SPI provides support for RGBW strips - what if they're on a usbasp or arduino over serial ?

penfold42 avatar Jun 26 '17 04:06 penfold42

Well, then you need additional code for hyperion and device? (FastLED, usbasp). Something like a RGBW pre processor for cleaner code on hyperion side?

brindosch avatar Jun 26 '17 07:06 brindosch

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

penfold42 avatar Jun 26 '17 08:06 penfold42

Oh, slightly OT. Did you had a hands on at the WS2815?

brindosch avatar Jun 26 '17 08:06 brindosch

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

redPanther avatar Jul 31 '17 09:07 redPanther

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!

penfold42 avatar Jul 31 '17 11:07 penfold42

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

redPanther avatar Aug 07 '17 08:08 redPanther

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

Nyxtegida avatar Feb 10 '18 17:02 Nyxtegida

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

penfold42 avatar Feb 11 '18 00:02 penfold42

And what happens when you need the white channel for a device where you can't hook something in between?

brindosch avatar Feb 11 '18 11:02 brindosch

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

Nyxtegida avatar Feb 11 '18 12:02 Nyxtegida

Just so we’re clear - did you know we already have RGBW support for SPI and PWM attached leds ?

penfold42 avatar Feb 11 '18 15:02 penfold42

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)

penfold42 avatar Feb 11 '18 15:02 penfold42

Hey, i just wanted to ask if RGBW over an Arduino has any benefits over normal RGBs at the moment.

UniCizin avatar Jun 05 '19 14:06 UniCizin

@Lord-Grey denke das wird in Zukunft auch noch interessant sein für die LED devices...

tpmodding avatar Jun 03 '20 19:06 tpmodding

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.

THATDONFC avatar Oct 12 '20 22:10 THATDONFC