ZIPP (Zero-Overhead Intelligent Pixel Protocol)
| Warning | The ZIPP project is currently under active development. Hardware designs, firmware, communications protocols, configuration procedures, and specifications described on these pages may change as development and testing continue. |
ZIPP
ZIPP (Zero-Overhead Intelligent Pixel Protocol) is a family of low-cost ESP8266 and ESP32 based controllers developed for DIY Christmas, Halloween, and other animated lighting applications.
ZIPP began as a lightweight Wi-Fi/DDP pixel controller designed to determine how much performance could be obtained from inexpensive ESP8266 hardware without the overhead of a large general-purpose firmware package.
Development and testing of the original ZIPP controller led to a broader distributed-control architecture. The ZIPP family now includes projects for pixels, relay control, incandescent lighting, motion sensing, and audio distribution.
A major goal of the project is to keep remote hardware inexpensive and simple. Rather than requiring every device in a display to be a full-featured controller, a ZIPP device can perform only the function required at its location while a more capable master or gateway handles higher-level communications and coordination.
Project Status
The ZIPP family is an active development project.
Some ZIPP hardware and firmware has been built and successfully tested, while other portions are still experimental or in the design stage.
Each ZIPP project page identifies its current development status.
Information published on these pages should therefore not be assumed to describe a final hardware or firmware design.
Project Names and Pronunciation
The names in the ZIPP project family are intended to be spoken as words rather than as individual letters.
- ZIPP (zip)
- Zero-Overhead Intelligent Pixel Protocol. The original ZIPP pixel controller and the root of the ZIPP project family.
- ZIPP-R (zipper)
- The ZIPP relay-control family. ZIPP-R1 is the single-relay version.
- ZIPP-I (zippy)
- The ZIPP incandescent-light controller.
- ZIPP-M (zip 'em)
- The ZIPP motion-sensing and motion-control project.
- ZIPP-A (zippa)
- The ZIPP audio-distribution project.
- ZIPP-PL (zipple)
- The ZIPP standalone sequence and show player.
ZIPP Project Family
ZIPP - Pixel Controller
The original ZIPP is a lightweight ESP8266-based pixel controller designed to receive DDP data over Wi-Fi and directly drive addressable pixels.
Development of ZIPP has included testing ESP8266 performance with large pixel counts, DDP packet handling, pixel timing, Wi-Fi startup and association behavior, and the effects of large numbers of wireless controllers operating simultaneously.
Testing demonstrated that an ESP8266 can directly drive 800 WS2811 pixels at a sustained 40 frames per second when unnecessary firmware overhead is removed.
ZIPP has also been used for long-range wireless experimentation. A 28-pixel candy cane was successfully operated at approximately 1,800 feet during testing.
Status: Working prototype / active development.
ZIPP-R - Relay Controller
ZIPP-R provides inexpensive distributed ON/OFF control for electrical loads that do not require dimming.
The first implementation, ZIPP-R1, uses an ESP-01S and an inexpensive single-channel 5 V relay module. The electronics are small enough to be installed in a compact enclosure and placed directly where switched power is required.
Rather than requiring every ZIPP-R1 to maintain a conventional Wi-Fi connection, the current architecture uses an ESP32 master and ESP-NOW communication between the master and remote ESP-01S relay controllers.
A working prototype has successfully demonstrated:
- ESP32-C3 master operation
- ESP-NOW communication
- ESP-01S remote operation
- Addressed command packets
- Remote relay ON/OFF control
Future development is planned to include automatic device commissioning, logical device addressing, heartbeat and failsafe operation, DDP integration, automatic wireless-channel selection, and channel roaming.
The intended commissioning system will allow identical firmware to be installed in every remote controller. A new device can identify itself to the master using its factory MAC address, receive a logical ZIPP device number, and store that number for future operation. This avoids maintaining or manually entering MAC-address lists for large numbers of controllers.
Status: Working prototype / active development.
ZIPP-I - Incandescent Controller
ZIPP-I is intended to provide distributed control and dimming of traditional incandescent Christmas-light strings.
The project is investigating a low-voltage-fed controller using an isolated high-frequency power-conversion stage rather than distributing conventional line-voltage dimmer electronics throughout the display.
Design goals include:
- Dimming of incandescent light strings
- Soft-start to reduce filament stress
- Electrical isolation
- Compact distributed hardware
- Low-cost construction
- Integration with the ZIPP communications architecture
Because incandescent lamps operated continuously from DC may experience filament migration effects, periodic output-polarity reversal is also being considered as part of the design.
Status: Design and experimental development.
ZIPP-M - Motion Controller
ZIPP-M is a distributed motion-sensing concept intended primarily for Halloween and interactive display applications.
Low-cost PIR motion sensors, such as the HC-SR501, can be connected to inexpensive ESP-based controllers and placed at useful locations throughout a display.
Rather than requiring each animated prop to contain its own independent motion detector, ZIPP-M can allow motion information to become part of the distributed ZIPP system.
Possible applications include:
- Activating Halloween props as visitors approach
- Triggering lighting effects
- Controlling ZIPP-R relay outputs
- Triggering sound effects
- Dividing a display into multiple motion zones
- Powering or enabling other sensors only when visitors are present
ZIPP-M functionality may also eventually be incorporated into other ZIPP devices when combining a sensor and an output in one enclosure is practical.
Status: Concept / early development.
ZIPP-A - Audio Distribution
ZIPP-A is an experimental audio-distribution project intended to transport show audio digitally to equipment located elsewhere in a display.
The initial concept uses an ESP32 Ethernet controller to receive audio over the show network and output digital audio through an I2S DAC. This could provide an inexpensive method of delivering stereo audio to an outdoor amplifier or FM transmitter without requiring a long analog-audio cable.
Prototype hardware under consideration includes an ESP32-ETH01 Ethernet controller and PCM5102A stereo I2S DAC.
Status: Early development / temporarily shelved.
ZIPP-PL - Standalone sequence/show player
Status: Concept / future development
System Architecture
ZIPP is evolving toward a distributed architecture in which different communications methods are used where they are most appropriate.
The original ZIPP pixel controller receives DDP directly over Wi-Fi because pixel data requires relatively high bandwidth.
Devices such as relays and motion sensors require very little bandwidth. These devices can instead use ESP-NOW to communicate with a central ESP32 master or gateway.
A possible system therefore consists of:
xLights | DDP | Wi-Fi / Ethernet | ESP32 ZIPP Master | ESP-NOW | +---- ZIPP-R relay controllers | +---- ZIPP-I incandescent controllers | +---- ZIPP-M motion/sensor controllers | +---- Future ZIPP devices
This architecture can substantially reduce conventional Wi-Fi traffic while allowing very inexpensive ESP8266 and ESP-01 based devices to be distributed throughout a display.
Logical Addressing
The ZIPP architecture is intended to use logical device addresses rather than requiring the user to manage ESP MAC addresses manually.
For example:
ZIPP-R #1 ZIPP-R #2 ZIPP-R #3 ... ZIPP-R #50
ESP-NOW devices still have unique factory MAC addresses, but these can be used internally during device commissioning.
The planned commissioning process will allow an unconfigured controller to announce itself to the master. The master assigns a logical ZIPP address, and the remote device stores that address in nonvolatile memory.
The same firmware can therefore be installed in many identical controllers without compiling a different firmware image for every device.
A controller may also provide a physical indication, such as operating its relay or flashing an indicator, when it is assigned an address so the installer can identify and label the device.
Wireless Channel Selection and Roaming
Automatic wireless-channel selection and roaming are planned areas of ZIPP development.
The goal is for the ZIPP master to determine which usable 2.4 GHz channel provides the best operating environment rather than requiring the entire system to be permanently configured for one channel.
Remote devices may store their last known operating channel for fast startup. If communication with the master is lost, a device could search the permitted channels until the ZIPP network is rediscovered.
A future implementation may allow the master to announce a channel change to all devices. A device that misses the announcement can recover by detecting the loss of the master heartbeat and searching for the network again.
Channel selection becomes more complicated when the ZIPP master is simultaneously connected to a conventional Wi-Fi access point because Wi-Fi and ESP-NOW share the ESP32's 2.4 GHz radio. This interaction is currently an area of investigation.
This functionality has not yet been implemented and should be considered experimental.
Design Philosophy
Several principles guide development of the ZIPP family.
- Low cost - Use inexpensive and readily available ESP8266, ESP32, ESP-01, relay, sensor, and power-supply hardware wherever practical.
- Distributed control - Place small controllers near the devices they operate rather than running large quantities of control wiring back to centralized controllers.
- Simple endpoints - A remote controller should perform only the work it actually needs to perform.
- Identical firmware where practical - Configuration and logical addressing should eliminate the need to maintain many individually compiled firmware versions.
- Efficient communications - High-bandwidth devices can use DDP while low-bandwidth devices can use lighter communications such as ESP-NOW.
- Recover automatically - Controllers should recover from communication interruptions without requiring manual resets whenever practical.
- Fail safely - Loss of communications should result in predictable behavior appropriate for the controlled device.
- Measure rather than assume - Performance limits should be established through actual testing whenever possible.
Development and Testing
ZIPP development has included experiments involving:
- ESP8266 pixel-output timing
- WS2811 maximum pixel counts
- 40 FPS operation
- DDP packet reception
- Wi-Fi startup and association timing
- Large numbers of ESP8266 Wi-Fi controllers
- xLights output behavior
- ESP-NOW communication
- Long-distance wireless operation
- Automatic recovery from communication failures
- Distributed relay control
Test results, including unsuccessful experiments, may be documented when they provide useful information for future development.
The intention is not only to document the finished controllers, but also to preserve the engineering information that explains why particular designs and approaches were chosen.
Documentation
As development continues, the ZIPP pages are intended to include:
- Hardware descriptions
- Schematics
- Parts lists
- Firmware
- Firmware installation
- Configuration
- Communications protocols
- DDP configuration
- ESP-NOW configuration
- Logical addressing and commissioning
- Wireless channel selection and roaming
- Heartbeat and failsafe operation
- xLights integration
- Performance testing
- Enclosures and construction
- Known limitations
- Development history
Project Author
The ZIPP project is a DIY Christmas member project developed by Ernest Horning.
The project is being documented while development is in progress so that design decisions, experiments, test results, and working configurations can be preserved for future reference.