Hi there. I am working on an LED wall project, and am researching various methods to control it. It’s currently being controlled by an ESP32 , so I already have the hardware part covered. My question is: what would it take for me to get a port of your firmware for the ESP32? Or just the source so that I can work on porting it myself? Honestly, I would prefer the source so that I can add Art-Net capability to it. If you need me to buy your hardware, I’ll gladly do that, but I can’t use it for this project because I’m pretty sure the ESP8266 doesn’t have enough umph to handle 4096 pixels (WS2812b).
Sorry if this question seems out of line. If you don’t want to share your code I completely understand. If it helps, this is for a non-commercial project.
I can’t speak to the source other than to note that I think that Ben has mentioned publicly that the project is currently closed source, that it might change in the future, but that it has a few peripheral open source components (sensor board, output expander).
You project looks really cool though. That one dude on Reddit was such a troll. I’ve looked at Twinkly, it’s incredibly expensive, and I want more hackability.
What I can offer you though is some thoughts about the specs. The ESP8266-based Pixelblaze v2 can support up to 6,400 WS2812b LEDs on a single one of the latest output expander.
The limiting factor tends to be the rate at which you can generate the frames. At 12,000-45,000 pixels per second, your 4096 LED tapestry will output at 3 frames per second for complicated patterns, and ~11 FPS for simpler math.
Ben’s also mentioned here on the forums he’s working on a ESP32-based version.
Thanks for the response. Yeah, I figured it was closed-source. It was worth a shot, though.
Regarding FPS, I’m starting to look at a parallel output solution. I’m not sure if you’re familiar with Yves-bazin, but he’s done a bit of work in this regard so I’ve been talking with him trying to get his libraries working with my project. I’m currently looking at an 8-pin solution (1 pin/2 boards), and he claims I should be able to get 65fps with that. He’s in the process of updating his library, though, and said it may be a couple of days before the new one is available.
The main thing I wanted from the PixelBlaze’s code is the built-in pattern editor. While the solution I’m working on now is more made for Art-Net/DMX, it’d be good to have something on there when a PC isn’t available to drive it. It’d be awesome to have something I could build patterns on without having to continually compile/upload the code.
Hi @taeratrin,
I think @jeff covered the bases (thanks, Jeff!). 4k pixels is still quite a bit for PB at the moment. All that live coding magic works by running in a virtual machine or bytecode if you will. The ESP32 version of Pixelblaze is 2-2.5x faster, but still not where you would want to be for 4k pixels with a fast framerate.
I hope it’s OK to mention a “competitor” here. PJRC is basically one guy, Paul Stoffgren, who designs the hardware and writes the software. His Teensie and OctoWS2811 hardware and software have been out for years so they should be stable.
There are also tons of other commercial controllers designed just to push pixels/video to LED walls.
Of course, Pixelblaze is more than just pushing pixel data out to LEDs, the main goal for it is live coding patterns and having the ability to change the patterns on the fly without compile/upload steps.
@wizard OK, thanks anyway. I am thinking that my only other option would be to setup a Rest API end point that receives arrays and pushes them to FastLED, then create a frontend that takes user input and converts it to those arrays. That’s going to ttake a while.
@kanyonKris Thanks for the heads up. Looks interesting, but it would need a lot of work to port it to the ESP32.
@taeratrin why are you insisting on using an ESP32? Are you sure the ESP32 is capable of driving 4096 pixels at an acceptable framerate?
The WLED firmware (running on ESP32) suggests 1000 pixels max. Perhaps clever coding could allow more than 1000 pixels on ESP32, which means searching around and hope someone has already done the code, or do it yourself.
I prefer to find hardware and software that already does what I need. As @wizard mentioned, there are many products that can handle 4096 pixels. As an example, a Teensy 3.2 running the WS2811 library using DMA can do 4000 pixels. And if that’s not enough you can get a “bigger” Teensy (3.5, 3.6, 4.0, 4.1) or use two Teensy 3.2s. Teensy 4.1 supports ethernet. If you need WiFi, perhaps connect (serial) the ESP32 to a Teensy. It looks like there is Art-Net code available for Teensy.
@KanyonKris
a) I already have an ESP32. No need to buy more hardware
b) Specs-wise, the ESP32 is much more powerful than the Teensy. 240MHz vs 120Mhz. Dual-core vs single-core. 520kB RAM vs 192kB RAM. If a Teensy can run that many pixels, so can an ESP32. I have seen several people manage it.
I have already driven it with some FastLed test code, and it handled it fine with a decent framerate. However, implementing ArtNet is going to require that I output in parallel in order to get a decent framerate. Yves-bazin has aleady done work in this area, and he’s driven a lot more pixels than I am trying to.
I prefer to find hardware and software that already does what I need
Look, this project didn’t start out as “I want to build an LED wall”. It started out as “I have an ESP32. What neat things can I do with it?”. In addition to that, part of the satisfaction from putting this together is coming from not just plugging a pre-built controller into it. I realize that may sound silly considering this is a post where I asked from some pre-built software, but :
a) Even if I had received the source for PB, I would have had to make major modifications for it to do everything that I wanted.
b) Pre-built software is a good placeholder so that my project does something while I work on my own code, which could take a long time.
I did some reading, including Yves-bazin. Impressive coding to drive so many LEDs from the ESP32.
I wonder why WLED is limited to 1000 LEDs? Perhaps the web interface and all the other stuff that WLED is doing reduces how many LEDs it can drive (at a reasonably fast framerate).
I mentioned Teensy and the OctoWS2811 library because I know Paul used DMA to offload a lot of the LED driving from the CPU. He has actual examples of running thousands of LEDs. And the library and Teensy are pretty stable (have been out for years). So I thought it might be a good fit for your LED wall.
Do you think WiFi will be stable enough for Art-Net? Seems like most people use wired (ethernet) runs. Could add ethernet to your ESP32 I suppose. As I mentioned, the new Teensy 4.1 has ethernet (via a simple breakout cable, board and a few components). 600 MHz M7 CPU.
@KanyonKris I believe the limit in WLED comes from their support of multiple interfaces. While their FastLED code could probably handle 4k pixels, things like ArtNet and sACN would choke on it. Hence the need for parallel outputs, which WLED doesn’t support yet. They have indicated that they are adding that functionality in the near future, though.
One of these days I want to take the time to re-build WLED with the 1000 limitation removed from the UI just to see how it does.
I read that fadecandy “includes unique color dithering and interpolation algorithms to get the most out of each pixel.” Is your 8x output expander doing the same kind of thing? WS2812b’s low brightness colors get all messed up. I’m curious if the 8x expander helps with that like fadecandy supposedly did. Paul recently updated his readme on github and I don’t know what to make of it. I think he is saying that the fadecandy project is dead.
What do you mean? What does the output expander get from fadecandy? Is it more than just being able to run 8 strips? Sorry if I am being dense, but I am trying to understand.
One of the key features that I like about fadecandy is the temporal dithering & the interpolation between frames. Due to the timing/PWM & datarate of the WS2812 style pixels using dithering means that you’ll only be able to drive 48 pixels per channel instead of the 64 that you are currently able to.
Ok, so 64x8 channels via USB. Potentially you could make it “smart” and handle some data manipulation to interpolate and dither.
Compare that to @zranger’s code for the Output Expander. Processing based, any PC/Mac/Pi/etc can run it. It works similarly, via USB but can handle so many more LEDs.
Compare the size of the boards, and the small OE is about the same size, costs $19 but can run 600-800 LEDs per channel, 8 channels. That’s about 10 times as many as Fadecandy (total 64x8 = 512). Each individual channel is more than an entire FadeCandy can do. It’s dead, Jim.
Yes, you need to a USB to serial adapter ($12ish), but it can drive more than one OE at a time (8, I think) as well, so cost per pixel? Up to 8x8x800 (or 100 times a single FadeCandy) pixels and that’s just one USB connection? Need more?
Add more.
FadeCandy is awesome, and I had used it in a number of projects in the past. Notably I used it to drive LEDs from a Raspberry Pi in the Synthia project, both V1 and V2:
FadeCandy gives you 4 kinda big things that my expanders don’t:
Temporal dithering for a bit more than 8-bits per element - though this is a double-edged sword. It will limit you to 64 pixels per channel because the way it works is software PWM on top of the 8-bit per channel PWM on the LEDs. It has to send new values to it quickly, and needs to do this at 400-500 FPS or it would flicker badly, thus limiting to 64 pixels per channel. (@Scruffynerf, the mention of 48 is for RGBW - extra byte on the wire).
Keyframe interpolation. If your animation ran at 30 FPS, this would interpolate between each frame and boost the apparent frame rate. Even if your animation ran at 1FPS, it would output buttery smooth fades. The only downside is that it doesn’t work well if there is a lot of jitter in when those animation frames arrive, so it has to be consistent for best results. In other words, if your animation took a variable amount of time to generate each frame, the frame interpolation wouldn’t be transitioning quite right. It also looses benefit if you are pushing high frame rates already.
Native USB connectivity.
An Open Pixel Control (OPC) server that would talk to FC over USB and give you a nice network interface to push pixels to. This was often used along with Processing, but could be used with anything else pretty easily (perhaps it wouldn’t be too hard to build an OPC server for PB expanders, but that doesn’t yet exist). The server also had a minimal web GUI that was handy for testing.
In Synthia, I had to disable both temporal dithering and keyframe interpolation because I was sending animation frames at around 100 FPS, and those features were both unnecessary and caused issues with the very high frame rate animation.
We’ve talked about adding things like temporal dithering and keyframe interpolation to the expander before. Limiting to 64 pixels is a non-starter for me, and not a limit I would want to impose in order to achieve temporal dithering. That said, it’s technically possible and anyone is free to modify the expander code to make it do that.
Keyframe interpolation could be very interesting, but would require a lot of CPU for as many pixels as the expanders can handle. It might be doable with modest limits on the newer expander models MCU (STM32L432) using some of the ARM SIMD DSP instructions.
I love the direction @zranger1 is taking with this, and perhaps an expander with native USB would make sense at some point.
Maybe not. Thinking a bit more, it might be feasible to support either input and have both a serial and USB input. Perhaps the board could also support sending OUT serial to chain additional expanders on the same USB connection, less USB hardware.
Good point, as long as you aren’t hitting data rate limitations, a frame interpolation layer on the computer side of things would have much more resources to tap.
I suppose it’s possible to do the same PWM-based dithering thing from Processing if you only had a few LEDs connected. Communication speed vs. flicker would be a real problem. I’d just advise people to use APA102-class LEDs if they need a lot of dynamic range, especially now that I’ve checked in (v0.2.0) extended APA color support.
Frame interpolation – not hard, but I can’t think of a reason you’d ever want to do that if you’re rendering on a computer. You’ve got the resources to render at basically whatever frame rate you want, especially if you’re using the GPU to do it all in parallel.
On USB hardware support: Wow, that’d be interesting if the demand merits it. I wasn’t even going to ask – was just going to start testing a broad range of USB->Serial devices to get an idea what’s out there that works for this purpose.
