New ESP32 based WS2811/WS2812 controller anyone?

P

pascoea

New member
Hey there forum!

I've been working for a couple years on a new ESP based WS281x controller board. I'm on the 3rd-ish revision, and feel like it's ready to get a few boards out into the community and get feedback. When I started this project, the goal was to have a complete sub-$100 controller that can run 10 strands. Currently well under that goal. My display is based around the 12v WS2811 and WS2813, so that's what the controller is geared towards.

The hardware itself is intended to be a low-cost, maker/hobby type board. There are 11 outputs. Built-in 10/100 ethernet (LAN8720) and the ESP's WiFi. The nice thing about the 8720 is it utilizes the ESP's onboard MAC, so all of the async stuff still works. It supports on-board display and input, also configurable/manageable via a web portal. There are a couple of extra low-speed low-current GPIO available for, well, general purposes.

The software is loosely based around the ESPixelStick Firmware but has been modified to work with fastLED library (amongst others). It will be open-sourced once it's beta-level.

The brains of the device is either an ESP32 Dev Module or an ESP32-wroom (or pin-compatible) module.

As I mentioned above, I'd love to get a few of them out there and get some feedback. Let me know if you're interested!

Attached is a KiCAD render.
 

Attachments

  • esp32-wslan8720-main.jpg
    esp32-wslan8720-main.jpg
    83 KB · Views: 84
Last edited:
Why does it have to be married to 12v/5v at all? Some of the latest controllers in the pipe simply send data and V- for each channel. You should be able to power the ESP via USB and that's it.
 
RichieNorthcott said:
Interesting!

When you mention 10 strands, how many pixels per strand? What refresh rates would this support?
Click to expand...

I ended up getting 11 channels out of it. My longest single string is 300px (power injection obviously needed), but I mostly use it it drive multiple shorter strings of 50-100.

You're really limited by the 800khz of the WS281x timing, no real way around it. You can theoretically update 33,333 pixels/second, so use that to calculate your max frame rate. At a 33ms period (30fps) you can (again, theoretically) get 1000px, in practice you're going to be well below that, maybe 600-ish.
 
Last edited:
1pet2_9 said:
Why does it have to be married to 12v/5v at all? Some of the latest controllers in the pipe simply send data and V- for each channel. You should be able to power the ESP via USB and that's it.
Click to expand...

Valid point, I appreciate the input.

A couple of reasons: Mainly in installation efficiency: I was trying to keep it self-contained, no need for 120v or other external adapters. I haven't seen a need (in my display, so far) to isolate the logic supply from the "main" power. And lastly, when/if the Dev module gets dropped and go to the WROOM type modules you need to supply your own 3.3 and 5v anyway.

That being said, I have ran the board from USB. As long as the onboard supply is disconnected/not populated it wouldn't be a problem.

Again, thanks for the input.
 
Nicely done.
I realize you designed this for specific purpose though wonder if you had you considered an SD option .
 
When using that library to drive the pixel strings, there wont be enough CPU cycles left over to stream an fseq file. ESPixelStick V4 uses the hardware data stream generators and has the cycles left for reading files. ESPV4 could drive this board but only up to 10 ports.
 
angus40 said:
Nicely done.
I realize you designed this for specific purpose though wonder if you had you considered an SD option .
Click to expand...

Thank you, I've got a ton of time into this.

I have not considered an SD interface, to be honest. First issue is I/O. Every pin is utilized for either the ethernet interface, i2c, LED outputs. (There are 4 input-only pins left, but nothing Output) Second issue is I have exactly zero experience with SD/external storage on the ESP, lol.
 
MartinMueller2003 said:
When using that library to drive the pixel strings, there wont be enough CPU cycles left over to stream an fseq file. ESPixelStick V4 uses the hardware data stream generators and has the cycles left for reading files. ESPV4 could drive this board but only up to 10 ports.
Click to expand...

I assume you're referring to the SD card comment above? Either way though, yeah, with the relatively slow WS281x protocol there isn't a whole lot of time for other "stuff" to be done when bit-banging outputs. At this point my software can't really even handle web requests or user I/O while running a show without stuttering. I believe FASTLed is running asynchronous, but even then there's not a lot of free time. I love the stuff people are doing with the Pi Pico and the state-machine outputs, but haven't really dug into it too much yet. I'm not 100% sure what you are referring to about the "hardware data stream generators" in the ESP, but would love to learn more.

Thank you for your comment, I appreciate it.
 
MartinMueller2003 said:
When using that library to drive the pixel strings, there wont be enough CPU cycles left over to stream an fseq file. ESPixelStick V4 uses the hardware data stream generators and has the cycles left for reading files. ESPV4 could drive this board but only up to 10 ports.
Click to expand...

I forgot to mention in my other post... Thank you for everything you do. I've spent a ton of time poking around in the ESPixelStick world, absolutely amazing stuff. (I hope you don't think I'm trying to encroach on your turf, I'm just a tinkerer that loves to share what I've done.)
 
no worries. It is good to give people options. Shelby went away from the bit banging method due to limits in CPU processing and I fully agree with that decision. I am seeing a trend towards playing sequences from an sd card to reduce the load on the wifi network. But using an SD card means more load on the CPU uses a bunch of IO and ram (tradeoffs everywhere). The current V4 supports 10 ports and a bit over 3k pixels (total), about the same limits you are seeing. If you design to add an SD card then I can mod the V4 code for your platform.

+1 for the suggestion to remove V+ from your outputs. It reduces the cost of the controller bacause you do not need to use thick copper to provide power distribution.
 
pascoea said:
I assume you're referring to the SD card comment above? Either way though, yeah, with the relatively slow WS281x protocol there isn't a whole lot of time for other "stuff" to be done when bit-banging outputs. At this point my software can't really even handle web requests or user I/O while running a show without stuttering. I believe FASTLed is running asynchronous, but even then there's not a lot of free time. I love the stuff people are doing with the Pi Pico and the state-machine outputs, but haven't really dug into it too much yet. I'm not 100% sure what you are referring to about the "hardware data stream generators" in the ESP, but would love to learn more.

Thank you for your comment, I appreciate it.
Click to expand...
V4 uses two of the three UARTS to generate pixel data streams. It also uses the 8 RMT channels to generate pixel data streams for a total of 10 data stream generators. This still has a lot of load on the CPU but the E1.31 interface stays up and accessing the web page still works when all ten outputs are active. By using the hardware data generators we avoid the tight timing issues of a bit bang implementation.
 
pascoea said:
I forgot to mention in my other post... Thank you for everything you do. I've spent a ton of time poking around in the ESPixelStick world, absolutely amazing stuff. (I hope you don't think I'm trying to encroach on your turf, I'm just a tinkerer that loves to share what I've done.)
Click to expand...
and I am a tinkerer who likes to improve other peoples stuff :)
 
MartinMueller2003 said:
no worries. It is good to give people options. Shelby went away from the bit banging method due to limits in CPU processing and I fully agree with that decision. I am seeing a trend towards playing sequences from an sd card to reduce the load on the wifi network. But using an SD card means more load on the CPU uses a bunch of IO and ram (tradeoffs everywhere). The current V4 supports 10 ports and a bit over 3k pixels (total), about the same limits you are seeing. If you design to add an SD card then I can mod the V4 code for your platform.

+1 for the suggestion to remove V+ from your outputs. It reduces the cost of the controller bacause you do not need to use thick copper to provide power distribution.
Click to expand...

I can certainly appreciate the V+ suggestion, and will put some brainpower into it. As of now I haven't really had a voltage drop issue across the 1oz copper, but I've only ran about 1000px out of a single board without downstream power injection. I like that I can assemble/terminate everything inside the house, then just plug and play once I get outside. Makes deploying everything in the freezing cold of MN slightly more palatable. (also a more intelligent solution would involve deploying everything before Thanksgiving)

As far as the SD thing, the whole reason I started this project is I couldn't get rid of the stuttering/delays over WiFi. Figured why bother fix the network when you can spend 1000 hours designing, building, and coding a hard-wired controller. :D I appreciate the offer though!
 
I like to build minuscule enclosure boxes. I did it with Arduino nanos, which certainly don't have the capability that these ESPixelStick families do, but they share a similar form factor. A simple cell phone charger is all you need. Since I run 5V pixels, I like the PSU's on the props, close to the injection points. Everybody who builds these big 12V boxes with multiple PSU's inside are okay with a little extra run length on the power lines, but I try to avoid that. I'm okay with running AC to the props (where the PSU's are). The big 12V boxes I like, too, when I have a nice weatherproof location like under a gazebo, in the garage, under a permanently-parked car or something.

I saw one of these boards running only data and V- before, and that does wonders for the form factor when you only have to break out 2 pins instead of 3 for 10 channels.
 
You must log in or register to reply here.
Back
Top