Context
This project began life as an attempt to build a version of the common "firefly" light centerpieces I've seen at a number of weddings in the last few years. While working on prototypes, my fiance found [Bill Porter]'s project and liked what she saw.
The Hardware
Each unit consists of an ESP8266 module and three individual NeoPixels. The ESP connects to a Raspberry Pi 3 running the BlinkNet PiFFT server.
The Software
The Raspberry Pi is set up as a WiFi hotspot, and runs a simple python script that samples a USB microphone, applies DFT via NumPY, and pushes out the BlinkNet packet via a UDP multicast with this structure:
0 | 1 | 2 | 3 | 4...7 | 4(n+1)...4(n+1)+4 |
number of lights | opcode | client ID | reserved | RGBW data | RGBW Data... |
The first byte is the number of lights in the packet, meaning the total packet size is 4n+4 bytes total. The second byte is the opcode, detailed below. The third byte is the device ID (if applicable per the opcode). The fourth byte is reserved, and the remaining data is RGWB data for each LED.
Opcodes
- 0x00: Broadcast colors. This is the "normal" mode of operation, and is used when the control unit is broadcasting color data to all devices on the network. It does not set a device ID.
- 0x01: Individual device colors. This addresses a specific device (via the device ID byte), and only that device should follow the order. Once consumed, the device should ignore broadcast colors until this state is cleared. This should be used sparingly, as the nature of the network means that all device will receive this packet.
- 0x02: Clear device color. This packet clears the individual color state to allow the device to listen to broadcasts again
- 0x03: Global clear hold. Same as 0x02, but all currently-holding devices should listen.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.