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.
2 Likes
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.
1 Like
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:
6 Likes
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).
3 Likes
I was going to suggest to @wizard that a PB capable of driving a HUB75 device would be useful, when in the midst of my research to see if anyone had done a ws2812->hub75 adapter, realized you’d already done it one better.
Any progress on this? This seems a great way to drive a big panel of LEDs via a PB… Using multiples with output expander, you could easily get to the point where the PB itself could be the bottleneck. (64x64 = 4096 pixels, and that would just be one panel)
Maybe you two should collaborate on a single board that’s a dual ESP32, one to run PB and one to drive hub75?
Yes, Pixelblaze is the bottleneck for framerate at most panel sizes. I have it working at 64x64 but don’t think I posted the result as the framerate was too low.
I’ve continued to iterate on the firmware, but haven’t done much on the hardware since I posted. @wizard ordered Pixelvation Engine PCBs a while back to test it, and I’m definitely open to collaboration.
Also check out the #2d channel on WLED Discord next time you’re in there.
1 Like
In going down the rabbit hole for Halloween LED patterns, I came across this LED mask, originally from Lumen Couture http://www.lumencouture.com
(who is also an Oculus designer, as well as into led fashion.)
Currently $75 for that branded one on Amazon, also now available in many many clones some cheaper, (which potentially means cheaper still in bulk), and all use the software, so …
Crappy bluetooth, by reviews, one source for app (trojaned?!, according to reddit below)
So I dug into the specs:
46 * 58 (Irregular) led matrix according to the cheapest one I found on Amazon at just $50 after coupon https://amazon.com/dp/B0987892MZ
https://fccid.io/2AOLN-16/Internal-Photos/Int-Photos-5007890
And you can clearly see it’s a hub75, but reprogramming the at32f415 (cortex m4) and the add-on Bluetooth, the “MCU Core” board? Bleh…
https://www.reddit.com/r/arduino/comments/mnfd0s/help_can_anyone_identify_this_board_details_in
I’m imagining a hub75 version of PB now, @wizard … Yes for normal 32x64 (or bigger) panels, but for stuff like this… A PB mask? With gif support? And built in sound sensor?
There’s a few threads on this mask:
I was trying to help Elec Dash Tron on twitter reverse engineer the matrix so it could be replaced by another controller, but it seems like the mask isn’t directly HUB75E compatible and he moved on to other things before finishing the project:
https://twitter.com/search?q=%40wow_elec_tron%20%40embcreations&src=typed_query
Based on what I saw I think it will be possible to drive it with the Pixelvation Engine controller, but it won’t be trivial.
Here’s my notes which I may or may not have posted on Twitter or Instagram above, and also may be out of date after the reverse engineering effort:
The pinout looks like HUB75 with only one data channel and up to 32 rows. There’s two OE signals which doesn’t make sense at a glance. I count 22 TC5020A chips, enough to drive 117 RGB LEDs in parallel.
From what I see from the LED refresh artifacts in the video, I have a hunch that this is driven up to 117 pixels at a time in three row blocks, with some blocks being non-rectangular (e.g. in the middle where 117 LEDs isn’t enough to drive all LEDs in 3 rows).
If I were trying to drive this, I’d desolder the bluetooth board and use one of the open source HUB75 libraries to try to drive it (probably with an ESP32). Most HUB75 libraries are going to be very data inefficient as this display seems to have only one data channel instead of the 6x that HUB75 panels normally use. PxMatrix may be a better start than other libraries as it drives just one output pin.
Here’s my notes from what I can see in your video:
- Controller
- Pinouts look like HUB75 signals, but only one data output “SDI”, where HUB75 would have 6x: RGBx2
- 5x address lines: “ABCDE” for addressing up to 32 rows
- I see two “OE” signals for some reason.
- Maybe there’s two OE signals so part of the display can be turned off while shifting the data across the chips, to avoid having to shift data to all chips serially which would have
- LEDs
- I counted 46 wide in the widest rows. I estimated 58 tall but didn’t verify
- Chips
- It looks like there’s three rows of TC5020A chips, 8x top two rows, 6x bottom row. Each chip has 16 outputs, so there’s drivers for 117 RGB LEDs in parallel
- The chip placement looks similar to a HUB75 panel
- Refreshing
- The refresh rate is low enough artifacts are captured by the camera and can be seen by stepping frame by frame through the video. They’re almost always across the width of the mask, usually around 3 rows tall.
- There’s one black block right in the widest part of the mask (repeated at least twice in the video) that is three rows tall, but doesn’t extend the full width on one of the rows. There’s at least 19 pixels still lit. The number of pixels in the black block is roughly 117, the number of total RGB LEDs that can be driven by 22 TC5020A drivers.
- Given that there’s not enough outputs on the TC5020A to drive all LEDs on the widest rows, they’re probably not doing just a simple matrix mapping.
I’d love to see Pixelblaze with GIF support.
1 Like
Says it’s SPI rather than 6 RGB in parallel, and lots of other neat info via hooking it to oscilloscope.
Thanks for the deeper dive, saved me lots of time. I hadn’t dug into twitter and Google was sparse. I suspect these will be around for a while, and remain cheap.
As for gif (or really any bitmap) support, we’ll all just keep poking @wizard till the magic happens.
Added, in other news, I found a new model, a kids model from same manufactory, which I’ve ordered, mostly cause I’m curious. No phone app, but a windows app, and has a bracelet button (bluetooth?), to change display.
1 Like
Bringing this back on topic, because I happened to click on the link @wizard linked about the limits of dithering…
And…
let’s just say in July 2021…
I’ve been wondering if scanlime was dropping the fadecandy project after a couple years of no updates, guess I now know the answer. Here’s some backstory if anyone is interested: