The latest ESPixelPOPs build and setup guides are here:
ESPixelPOPs
One of the best sources for affordable DIY lighting control has been various hobbyists involved in the Xmas light animation groups. A few years ago Shelby Merrick started development on the ESPixelStick software and it has matured into a very full featured Wi-Fi based E1.31 (DMX over Ethernet) Pixel controller. It can drive up to 680 WS2811 pixels (4 DMX universes) or 63 GECE pixels. It can also be configured as an E1.31 to DMX bridge (1 DMX Universe) by connecting a RS-485 driver instead of pixels.
The ESPixelStick software will run on many different variants of hardware (anything ESP8266 based) and there are quite a few different versions available. The ESPixelPOPs is a PCB designed by Ukewarrior (based on an original design by Bill Porter). It is a very compact PCB (designed to fit in 1 PVC pipe) that only uses through hole parts (no SMD soldering required).
Here are a couple examples of the controllers I have setup using the ESPixelPOPs. The first one I use for testing Pixel displays. It has a pair of JST connectors (a typical connector used on various Pixel strips) and a couple of the 4 pin sockets that I use on some Xmas decorations. I use this controller with E1.31 test software (like da_Tester or sACNView) or with the Pixel control software (xLights or Jinx) to test and burn in pixels for various projects.
The next controller I built is one I use for controlling some large outdoor Xmas lights. This display has 10 large lights and I loop the Pixel data line from one to the next using 4 conductor cabling. Each light has a 20 foot Cat5 cable run (so 40 feet between lights) and I was getting strange glitches in the signaling until I added some SN74AHCT125N buffers in between each cable run. This cleaned up the signalling nicely. To the left of this controllers you can see a couple of test devices I made up consisting of a single pixel connected to a plug. These let me confirm operation of the controllers without having to setup up the whole display and they are very handy for troubleshooting.
This guide will show you how to build one:
ESPixelPOPs DMX
A great feature of the ESPixelStick firmware is the ability to output DMX. Instead of driving pixels it send out a DMX signal. All you need to add is a RS-485 interfaces. You can get the MAX485 modules from AliExpress for less than 1 dollar. It easily connects to the ESPixelPOPs. Check out the DMX build guide for full details. I have added both 3 pin XLR and RJ45 outlets on this controller. This is a very cost effective way to get a E1.31 to DMX gateway when will let you use older DMX controlled fixtures in your Pixel display. This guide will show you how to make one:
ESPixelPOPs WLED
While the ESPixelStick software is fantastic for running E1.31 controlled pixel animations sometimes you just need something simple. Something that doesn’t require streaming a complicated show from Xlights or Vixen. Of course the ESPixelStick does have some preset test sequences that may be all you need but what if you want soemthing more complex. An easy solution is to run WLED on your ESPixelPOP. I wouldn’t use it for streaming E1.31 (though it can do that) but it does give you a wide variety of canned lighting effects and sequences to play with. And it will run on your ESPixelPOP with no changes to the software or hardware!! This guide will show you the basics of installing it:
ESPixelPOPs-WLED-Guide-v5.16.2020
Note that the latest version of WLED (0.13.3) will still run on your ESPixelPOP. Just make sure you download the WLED_0.13.3_ESP01.bin file. The ESP01 version has all the WLED features except the OTA (Over The Air) firmware update (you need to use a connected USB/Serial dongle) to load new firmware)
Unicast vs Multicast
One of the issues you can run into using Wi-Fi when using the ESPixelStick firmware is network congestion. The ESP-01 Wi-Fimodules only use the 2.4G radio frequencies and this only allows for 3 different radio channels to be used at the same time. You can run into buffering issues when streaming the real-time E1.31 data in a area that is congested with other Wi-Fi users. The solution is to use multicast instead of unicast. It takes a bit to get you head around it but here are some links to good information:
https://www.diychristmas.org/wiki/index.php?title=Streaming_ACN_over_WiFi
https://www.vixenlights.com/docs/concepts/sacn/
The issue revolves around how Wi-Fi treats the unicast UDP packets. You would expect that unicast UDP traffic works in the Wi-Fi world the same as it does in the wired world. In a wired network a UDP packet is essentially fire and forget. The packet gets sent one, if it makes it to the destination that’s great. If not it’s up to the receiver to deal with it. In E1.31 (ACN) traffic a missed packet is no big deal as another one is coming in 50 mSec. This is the reason that UDP traffic is used for streaming type protocols.
The issue is the the Wi-Fi physical layer (Layer 1) actually keep track of UDP packets and wants to acknowledge them. If a few get missed they system can quickly bog down due to the relentless stream of new packets. This goes against logic but that is how it works. If you are having issues using unicast, make move to multicast where this mechanism does not exist.