ESP8266 For WS2812B strip control

[botcrusher]

I'm Currently using a ATMega 328 (5V) to control 300 lovely WS2812B chips
Works pretty well. I've gotten some slow animations going, (conga, bounce, solid colour) but i need more.

My limiting factors in this are the Serial Interface, and the poor 328 that I'm capping to run both 300 leds, and use a 0.5Mbit serial connection.

I of course, want a minimum of 30 updates per second, with a goal of 60 for some really smooth animations. This is not currently possible, and I need to run more strips anyways, (300 * 6 strips for text) which will further errode the refresh rate. This is already using the FastLED library, so suggesting i try that won't help much xD

Creating the animation is easy, I have a python script currently generating the animations which then transmits to the microcontroller, but I'm wondering how practical this is over WiFi with these cheap little badboys. Netcode isn't an issue, I can
Struct up some data for the ESP8266 to receive.

TL;DR:
 I need to ditch serial and get faster MCU(s) to run 1800+ rgb lights. Is the ESP8266 practical for this, and how many lights could I probably get away with driving off of one?

[Sal Ammoniac]

Another option is an FPGA. They have lots of I/O and would easily handle thousands of the RGB LEDs at very fast update rates.

[LukeW]

Even if you never use the WiFi, if you're happy with the SDK and the various development environments available for the ESP8266 (e.g. NodeMCU) many people like the ESP8266 just as a relatively cheap, easy-to-use 32-bit microcontroller with more performance compared to something like an 8-bit ATmega328 with a low single-unit cost.

Technically the WS2812s are specified for 5V logic levels, and you may consider translating the 3.3V levels from the microcontroller, but many people plug it straight in and it seems to work.

[sporadic]

Bit-banging doesn't work so well on the ESP8266 as you'll start getting watchdog resets from the WiFi stack.  Thankfully though, you can trick some of the peripherals to generate the ws2811 stream for you.  I came up with a method that uses the UART configured at 6N1 and 3.2mbps in inverted mode with a lookup table for bit generation.  It's part of my ESPixelStick project and is for driving pixels via E1.31 (sACN / DMX over IP) for holiday / show lighting.  The source is available on GitHub here and a better description of the project is available here.  However, if you're wanting to integrate something into your own project, I'd look at NeoPixelBus.  He implemented my UART code into his library, made it interrupt driven, and added a DMA method as well.  These methods however, are targeted at single runs of pixels.  You'll run in to refresh rate issues before RAM issues.  At 680 pixels (4 DMX universes), you'll be at a 20.4ms refresh rate - ~50Hz.  I'd recommend keep your max run around there.  Also, as others stated, you'll want to properly drive them with a 5v buffer.

Here is this board:


Driving this matrix from a Raspberry Pi at 25ms update rates. It was sequenced in Vixen 3:


And here's what I do with them

[Kilrah]

This project might interest you:
https://www.pjrc.com/teensy/td_libs_OctoWS2811.html

[botcrusher]

Thanks all, part of my wanting to use the ESP8266 is that the WIFi would be brilliant for this.

My very first idea when aproaching this project was to use DMX, but I realised that that was fairly ineffective for this given the low data rate vs the high number of pixels to drive. Part of my current implementation to save currently precious serial bandwidth is using 8-bit values for the most common colours, so that the full 24bit RGB value doesn't need to be sent each time.

I know I'm saturating serial already, because a bit of research shows that serial above 500kbaud gives no further increase in speed on the ATMega 328, and when I send too many full 24-bit values at once, i seem to overflow and lock the poor arduino's serial connection.

This brought me the Idea of using the WiFi on the ESP, as each ESP will only use a small slice of the available bandwidth. (This project is getting a dedicated (WAP / switch)

The teensy solution looks nice, but I kinda want to continue my current arduino Based route, especially with the FastLED library being so damn fast, and that I've already made fairly efficient code to bang out the strips with very little delay from hitting [enter] on the computer to the animation starting.

I've already used netcode quite a bit in python, and the easy availability of cheap networking equipment makes this approach even more attractive. The low cost of each unit also means I can just throw on another MCU when i want more strips, add the IP to the python program, increase the number of lights to scale the animation to, and go.


Any MCU that is easy to code for, has a WS2812B library (sorry, i have too many things to do to take time nailing the timing requirements for the blasted things) and has WiFi (or Ethernet, getting off of 2.4Ghz sounds fine to me) is one I would take.

[sporadic]

I wouldn't dismiss all of DMX as a data transport.  E1.31 (aka sACN - streaming ACN / DMX over Ethernet) is used to drive thousands of channels of data for lighting control.  Going the E1.31 route opens you up to all kinds of sequencing software that's already been written.  You could easily keep 3 ESPs driving 680 pixels each in sync at a 50Hz refresh rate from an E1.31 source (just make sure your source is hardwired due to the simplex nature of 802.11).  If you want to keep in on a single controller or go a different route though, I'd either dump the data to a teensy via SPI and have it handle the pixels, or go an FPGA route.  Here's a 32 Universe controller (~16k channels / ~5.4k pixels) based on a Cyclone II - https://ronsholidaylights.com/32-universe-controller and is driven via E1.31.  Read up on Vixen Lights and xLights for some free sequencing software.  They're usually used for syncing with music, but you can just do animations as well.  You export your sequences to a Pi as well and control up to 64k channels via E1.31, or sync multiple Pi's together for more (Falcon Pi Player).

[Buriedcode]

This has been on my 'to do' list for a while.  I suspect someone has got the I2S port with DMA working for the ESP, this way each 32-bit 'word' sent out is a WS2812 byte, and the DMA just makes life a lot easier.  Theres many ways to control these, FPGA's probably being the idea if you have a significant number, but using the hardware modules on any micro will be a plus.

What really got me using the Arduino environment is the support for the ESP8266, the libraries are extremely easy to use and seems quite reliable.  I'm sure someone has done a hardware control version of the WS2812B rather than bit banging.

[botcrusher]

Yes, FastLED uses hardware SPI to accelerate by default if supported by the selected pin.

[sporadic]

Yes, there are I2S DMA implementations and async UART implementations for ESP8266 readily available, linked above. I would not recommend FastLED for ESP. 

Sent from my XT1094 using Tapatalk

[Kilrah]

How would you guarantee proper sync through Wi-Fi?

Also, from all benchmarks I've seen the data throughput over Wi-Fi of the ESP8266 is no higher than what you get on your arduino through serial.

[Rerouter]

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

It would appear that 500000 bits/s should be more than enough to handle the amount of data in, and adds up to 69 frames per second.

the link above even gives some good ideas for how to output the data that quickly, based on his minimum timings it would take 7.63ms to write 300 LEDs at 24 bit, leaving you quite a lot of time to process the serial stream.

So you should have tons of time left to check the buffer and write each frame out, even if you went the 328+esp8266 approach. Just to not tax the esp.

[sporadic]

How would you guarantee proper sync through Wi-Fi?

Also, from all benchmarks I've seen the data throughput over Wi-Fi of the ESP8266 is no higher than what you get on your arduino through serial.

With the ESP, you don't guarantee it.  You just need to have a proper WiFi infrastructure (dedicated and clean) in place and it works.  You'll run into other issues on ATMega's (like memory for buffering the pixel data) before you'll run into serial throughput issues.  Here's another example with 4 ESP's rendering E1.31 data incoming at a 50Hz refresh.  Just 1 universe of E1.31 using 120 channels (40 pixels) each, but they would handle 4 universes worth each no problem.  I run 15 ESP based modules in my show and don't have any synchronization issues using a dedicated Nanostation locoM2 as my AP.  Now, if you want to build a video wall or something, you'll obviously see some sync issues and should be looking at FPGA solutions, but I don't think that's the OP's intent.

[sporadic]

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

It would appear that 500000 bits/s should be more than enough to handle the amount of data in, and adds up to 69 frames per second.

the link above even gives some good ideas for how to output the data that quickly, based on his minimum timings it would take 7.63ms to write 300 LEDs at 24 bit, leaving you quite a lot of time to process the serial stream.

So you should have tons of time left to check the buffer and write each frame out, even if you went the 328+esp8266 approach. Just to not tax the esp.

You can offload everything to the UART on the ESP and drive WS2811 asynchronously.   I'm able to push 720 pixels worth of data via E1.31 at a 50Hz refresh and interact with the embedded web server for configuration and stats. And it's smooth. Just load this sketch on a ESP8266 and wire GPIO2 to your pixels - https://github.com/forkineye/ESPixelStick

[botcrusher]

Some posters seem to be a bit confused. The goal is to replace the ATMega 328 with an ESP, A teensy, etc. The initial animation is made via the computer it will be attached to. This brings up another problem i forgot to mention. These strips are going to be about 5m up in a theatre, about 35m in cabling away from the controller desk where the computer sits. If desperate, i can probably reduce that to ~10m from the MCU if i stick the laptop in a side room. This is part of why a WiFi or Ethernet approach is nice, as the first doesn't need cables, and i have an Ethernet drop close enough to pull it off.

I'll have to try out some of these solutions!

[botcrusher]

Well, it isn't going to be a video wall, more just animations and a bit of text once i get 6 strips (150* 6, not 300* 6 as i based my earlier estimate on.)

The ESPixelStick is out for me, as i barely have enough money for the strips, i can't get an MCU and the module. (Students be poor!)

I've got my eye on the Teensy route.

But how hard would FPGA be, as well as the cost? FPGAs are not something I'm very knowledgeable in.

[sporadic]

Well, it isn't going to be a video wall, more just animations and a bit of text once i get 6 strips (150* 6, not 300* 6 as i based my earlier estimate on.)

The ESPixelStick is out for me, as i barely have enough money for the strips, i can't get an MCU and the module. (Students be poor!)

I've got my eye on the Teensy route.

But how hard would FPGA be, as well as the cost? FPGAs are not something I'm very knowledgeable in.

Either an ESPixelStick ($10 + $2-3 for an ESP-01) or a nodeMCU (~$12?) would be cheaper than a Teensy ($20?). I'd honestly recommend getting a couple of nodeMCU 1.0's just to play with it. It's a great prototype platform for the ESP8266. Doesn't get much cheaper.

[Sal Ammoniac]

But how hard would FPGA be, as well as the cost? FPGAs are not something I'm very knowledgeable in.

FPGAs have a steep learning curve and take time to master. Once you get over that curve you can handle tasks that have tight timing constraints with ease. You could, for example, design a module to handle the timing required by the WS2812B fairly easily (it's quite a simple protocol, after all), and then instantiate that module many many times on the FPGA. Even the low-end Xilinx FPGAs have over 100 I/O pins and some of them have over 500. Need to drive 250 strings of LEDs? No problem!

[botcrusher]

Yeah, i just looked up the cost of the teensy. That ain't happening.

The ESPixelStick just became the #1 contender again xD

By DMX earlier, i meant the RS-485 run of the mill variety.

Looking up sACN, I like what I see. I've already found a E1.31 transmit library for python, so I can modify my existing animation generator to that.

[jasper9]

What did you end up going with?

I'm familiar with the ESP8266's sold by Adafruit and Sparkfun.  Do I understand it right that ESPixelStick isn't a ESP clone itself but an addon to make driving pixels easier?  Any pointers for what components would be needed on a standard board to get the same effect?

A post in this thread says "Just load this sketch on a ESP8266 and wire GPIO2 to your pixels"  No other config is needed?  It should just show up in software like xlights when you search?