I would love to see an output expander that implements Fadecandy dithering. For WS28xx compatibles you can use fadecandy to get increased color depth. It would be awesome to use PixelBlaze for all of the calculation and then have the expander handle distribution and dithering.
FadeCandy is awesome! I’ve made several projects with them. The output expander’s timer + DMA + GPIO trick to send out WS2812 was inspired by FC / OctoWS2811.
Temporal dithering only works well if you can refresh the LEDs at very fast rates, which is why FadeCandy has LED string length limits of 64.
I tend to gravitate toward the APA102/SK9822 type LEDs that have even better brightness range (via global brightness data) than possible with temporal dithering on WS2812s.
BTW the output expander is open source, and with a $2-$35 SWD ST-Link programmer, you too can hack it’s firmware
It would be a cool feature to add, especially when you have WS2812s and few enough LEDs that it can work.
I could see keyframe interpolation adding some benefit as well, even for more LEDs.
I did wonder if the output expander could be turned into a “quasi-fadecandy”
So much hardware, so little time.
I’m hoping to convince @wizard that the next thing is a Pico+, a tiny device like the Pico, but with sensors built in, or else (easier) a tiny matching sensor board that can easily to solder/wire connect to the bottom pads.
Imagine a really tiny PB single board with enough smarts to listen, figure out local orientation/gravity (6dof? Current sensor is only 3dof), and maybe light levels?
I’m afraid that hacking it myself is way beyond my ability. Just imagine if in the expander configuration screen you had a check box. If your LED type was WS2812 and you had less than 64 LEDs you could “enable enhanced color depth” and boom goes the dynamite. One of the great things about PB is that it’s written for high color depth. FastLED is natively not, so there’s probably no future for dithering, other than for universal brightness, which they have implemented. So now I’m tearing out my hair with RPI servers and Processing (which is also 24 bit color native) and Fadecandy and building differential boards and a PC, when really PB is 100 times easier to do almost all of that but just missing dithering. A man can dream!
What are you doing that fadecandy/etc is a better fit? Maybe we can help with a PB solution?
It’s just the color depth and fades. Right now if I’m working at very low brightness, either by lowering universal brightness or making very subtle shades, there is flickering.
As mentioned, better quality LEDs (sk9822s) that have extra brightness bits can help.
If you insist on using ws2812s, their low end of brightness is the issue here. Expecting hardware to solve this, you’d be better off just using better LEDs with PB.
Unfortunately, my stuff uses multiLED modules and the modern LED chipsets haven’t made it there yet. Maybe soon.
I’m working on a board that can receive APA102 data from Pixelblaze and drive 16 channels of LEDs (potentially more) and do dithering. The first phase of the project, refreshing HUB75 panels with data received from Pixelblaze is working:
The second phase is to drive addressable LEDs, both APA102/SK9822 and WS2812/etc with dithering, and interpolation between frames. I’m not sure when I’m going to start on that phase, but hopefully early 2021.
I’m publishing the open source design and firmware, you can follow along here:
Will it support all LED strips that PixelBlase does? I’m specifically wondering about the RGBW ones. Also if it just connects to the PB output could it also connect to other boards running other software like FastLED for example?
I’d like to support as many popular LED strips as I can. The order will probably be APA102/SK9822 first, WS2812 RGB, WS2812 RGBW, then whatever people are asking for most after that.
I’ve tested the board and sketch with Pixelblaze, WLED, FastLED, and SmartMatrix Library (my project).
A post was split to a new topic: Can an output expander be reprogrammed to drive more LEDs?