Project Logs

Collapse

• They're Done!

  Alex Bowen • 06/27/2019 at 00:23 • 0 comments

  What's New?

  In the time since the last update, I've wrapped up production on the centerpiece units, and designed and implemented a basic control system. To tackle the problem of adjusting audio processing settings to fit the acoustics of the room, I had a trusted friend and member of the ushing team use a web app on a tablet to make sure they looked perfect. I'll have some more details on what exactly everything did eventually, but for now, here's a screenshot:

  Also, I finally have some footage of the centerpieces in action! I had hoped to get some more, but I was, you know, enjoying my wedding. What follows is some very rough footage that I took very late in the evening when they were behaving particularly nicely. Wouldn't you know it, the Cha-Cha Slide really emphasized their capability, so I hastily grabbed a quick shot on my phone camera.

  What's Next?

  Not much. I'd like to fill in a few details that were left out of this blog in my haste to finish the project. Interestingly enough, one guest decided they really wanted to take one of the pieces home, so I'd like to get some instructions in place to explain how to make them at home. I'm also considering making a cohesive video detailing the entire project.

• "Mass Production"

  Alex Bowen • 04/19/2019 at 17:40 • 0 comments

  Where I've Been

  In the time since the last project update in January, I've been hard at work trying to build all fifteen of the centerpiece units, so very little "exciting" things have happened. Now that I'm nearing the end of that phase of work, I figure it's worth an update.

  The New Stuff

  Despite most of the work being pretty manual, there has been one actual change in the project since the last update. We have decided that the edge-lit acrylic portions will double as table numbers. This helped with speeding up production, because I no longer needed to come up with cool, unique designs for each unit. To make that design exciting, I filled in the numbers with PCB patterns. Specifically, I grabbed the Gerber files for the open-source Arduino Uno.

  Building a Whole Bunch

  To help speed up the process of cutting fifteen acrylic plates, I got some 12x12" acrylic sheets that fit perfectly into my Cricut's cutting surface. I recorded a time-lapse of one of those sheets, and I also have one of the top bracket being printed.

• Getting Ready for "Mass Production"

  Alex Bowen • 01/12/2019 at 16:10 • 0 comments

  While Looking for some ideas to minimize the printing and manual crafting time per-unit, my Fiance found the answer in the PlumbQqik PQC-104, a flexible end cap for sewers and drains. It turned out to be only a few millimeters off in both height and diameter from the existing case design. I adapted the existing top and center bracket to a new design that clips into drain cap.

  While it will add significant cost (an additional $5 per unit), it shortens the 3D printing time down from three 2-4 hour parts to a single 3-hour part. I also no longer need to tap screw stalks and there is far less support material to remove. Additionally, it solves the problem of the visible layer strata, which would have required some sanding or better tuning and leveling of my printer.

  I've also settled on using the vinyl cutter to score patterns for the edge-lit acrylic. I still need to get better at scoring and snapping the sheets down to the right size, but the results are looking nice so far, ignoring the rough and broken edges.

• The Prototype Units

  Alex Bowen • 12/28/2018 at 17:26 • 0 comments

  The case for the unit is a 3-segment, 3D-Printed set of parts that hold the battery compartment, LEDs, and the acrylic sheet itself that was modeled in Blender 3D.

  There are currently two units. The first one was printed as a filled-in enclosure that I had experimented with covering in PlastiDip.

  It took longer than I would like to print, and I was having trouble getting a smooth coating on the sides of the cylinder, so I moved to the design seen in the model, where there is a lot of open space that can be covered with a vinyl wrap.

  The piece of acrylic in the picture above is scratch piece that I tested a couple of different methods for imaging on. Specifically, I had attempted to frost it, and also scored a pattern into it with my vinyl cutter to see how each would look.

  Lastly, I have a set of PCBs that were ordered from JLCPCB.

• The Development Unit

  Alex Bowen • 12/28/2018 at 17:07 • 0 comments

  For programming and development, I hacked together some hardware and software that is easy to configure and play with. The programmer is actually a breakout USB UART to which I soldered some wires and a button 😊

  Lastly, for testing the protocol without needing to hook up the Raspberry Pi or run audio, I put together a small TKInter python app that allows me to set static colors over the BlinkNet protocol.

• Technology Overview

  Alex Bowen • 12/28/2018 at 16:48 • 0 comments

  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.

View all 6 project logs