The same control system, on one PCB (in a sketchy looking enclosure):

Never doing that first thing again.

A problem with the shield that I've run into is that there is very little documentation for the two-in-one audio jack. It's a 3.5mm four-connector TRRS (tip-ring-ring-sleeve) jack for the handset speaker and microphone:

The shield schematic shows the following for the audio jack:

Testing the continuity of the connection to components on the board confirms that the pinout for the jack should be:

This is obvious in retrospect: visualize it as the audio connector is inserted upwards into the bottom of the schematic symbol. The pins connecting the jack to the board don't seem to be numbered sequentially counterclockwise from the upper right; the S+ pin (4 on the schematic) is on the lower left, and the upper left pin is not used.

The standard 4p4c wiring for a phone handset has four wires: black, red, green, yellow. Black and yellow are for the speaker, red and green are for the microphone. To use a standard phone handset with the shield, wire the TRRS connector this way:

The dial-a-flame-effect details post will undoubtedly happen at some point soon.

As DMX is not supposed to be used with potentially dangerous devices, these boards are meant to turn 12V RGB LED strips into cheap DMX fixtures. Why a separate load power input (suitable for a deadman switch) remains on the board is left as an exercise for the reader.

The design files are on GitHub - you too can have PCB business cards with a small amount of KiCad know-how!

Using a fenode board and a 12V RGB LED strip, it's easy to make a DMX512 lighting fixture. DMX addresses 1-4 directly adjust the output of the 4 PWM channels using the controller's sliders. Channel 1 is red (above), channel 2 is green:

The fenode and dmxfire boards use RS-485 for communication, which is the serial communication protocol that DMX512 runs over. One simple Arduino sketch later, the boards take DMX512 commands from an off-the-shelf lighting control system. I'm using the Chauvet Obey 10, because it was cheap on eBay ($100 including 4 XLR cables). The only extra work was making an XLR-3 to RJ45 adapter cable; the next version of each of these boards will have a dual RJ45 and XLR footprint for data in and out.

The DMX512 specification states that it is not meant to be used for pyrotechnics and other potentially harmful devices due to the lack of error detection. (This is why the communications protocol used in Super Street Fire and other projects has error detection built in.) However, commercial DMX512-controlled flame effects do exist, and generally use multiple addresses for arming and firing. While I don't recommend using DMX512 as the communication protocol for a flame effect controller, it is possible.

The Charcade was a huge hit, and we burned approximately 10,000 pounds of propane (and ~100 gallons of gasoline - thanks, Matisse) over the week.

Everyone loved Riskee Ball - apparently everyone who has ever been a kid, at least in this part of the world, knows and loves Skee Ball.

Super Street Fire and Riskee Ball both use the control hardware I've developed - SSF uses individual fenode boards on each of the 32 flame effects, and each Riskee Ball lane is run entirely off of a dmxfire board that controls not just the flame effects but also the LED lights for scoring and the gameplay itself. Mens Amplio, by Don Cain, also used a wifire board to control its flame effects over I2C.

At the end of the week, the Ardent crew retired Dance Dance Immolation - by dropping a piano on it from a variable reach forklift. No joke.

Now that Burning Man is over, I'm going to return my focus to developing the line of flame effect controllers and accessories, and improving the firmware to make it easier to use as a drop-in solution for any project that wants to incorporate fire. Have an idea for a project and think this could help? Let me know!

0xFF [channel] [value]

For servos, value can be from 0 to 255, with 127 being the midpoint. Relays are even easier: 0 is off, 1 is on.

As a result, the Arduino sketch for a wifire16 board that processes this data and activates the SSR channels is also very simple, and allows the wifire16 board to be used with any control software that supports the protocol. One example of this is VSA by Brookshire Software. (I've never worked with VSA myself, but it's what a friend uses to control and sequence his Propane Dancefloor project.)

The wifire16 MiniSSC code can be found here.

This was my first LED project, and I decided I wanted to make similar LED boards. However, the resolution was too low, so I decided to up the pixels from 4x4 to 8x8 in the same 6" square board.

The LEDs are Piranha/Superflux 5mm square RGB LEDs, chosen because they are very bright at a wide viewing angle.

The pixelboard64 worked out ok, for the most part. Due to a simple math error, the power regulator wasn't enough to power the entire board when all the LEDs were fully lit up. The TLC5940 chips were also very picky, and often weren't grounded well enough, causing them to burn out. Having 12 per board (at about $3.50 each) made these pretty expensive to play with and test, so progress kept on stalling.

This is what happens when you try to pull about 4A through a LM323 regulator that doesn't have a large enough heat sink on it:

Recently, I started working with WS2812 LEDs. Their low cost was enough to make me think about the pixelboard64 again - at $0.15/LED with no additional chips, instead of $0.50/LED with every 16 LEDs needing $10.50 worth of TLC5940 chips, it was worth another try. The board was shrunk to 4" square (half inch pixel density), and instead of using one big power regulator, I split it out to 4 UA7805 regulators.

The end result is a board where I can use a solder paste stencil and hot plate to quickly assemble the LED side, and then hand solder the power supply components to the back. 64 LEDs, super bright, and relatively cheap to make. For power, the board has a header for an Anderson Powerpole connector, to avoid the trouble of screw terminals.

Populated, the prototype looks like this. The camera can't really capture how bright the LEDs are - 64 of them all on at once is surprisingly bright.

Would you be interested in one of these boards? Depending on interest, I may organize a bulk order through Tindie or IndieGogo in order to cut down on costs, and maybe have them professionally assembled.

If you are looking for an IMU board that is reasonably priced (the SparkFun MPU-9150 breakout board is $50), or need an IMU with an integrated radio header, please consider the hadokenIMU. Not only will you be supporting an awesome fire art project, you'll also be helping me continue to work on future open source hardware designs. Thank you!

At $0.14 per LED plus driver chip, this is incredibly cost effective, especially compared to the TLC5940 chips I usually use. The PLCC-6 form factor is easy to solder as well.

So, why are the LEDs sometimes called WS2811 and sometimes WS2812? The datasheets make this pretty clear, but here's the answer in picture form.

The WS2812 is the LED with embedded driver chip. The LED is 5mm x 5mm, but fortunately I have a USB microscope:

The driver chip is the WS2811:

It also comes in DIP-8 and SOP-8 packages if that one is too small to work with.

Datasheets: WS2811 (rar), WS2812 (pdf)

Yesterday I found myself needing to reference an RN-XV configuration option, and I dug up the slides from the class. If it's useful for me, it's probably useful for other people too, so here it is:

Wireless Communication With Arduino: Using the RN-XV to communicate over WiFi

Last month, I brought the Coat Rack to Frostburn. Since it was so cold out, it was set up with a very simple interface: push buttons, receive fire.

Photo by Shawn Ferry

The tablet interface (written by Kate as an offshoot of the Super Street Fire tablet control) is very simple, providing buttons for each and an eruption button to blast everything at once. At some point, it's likely that the interface will have the capability to record and play back effects.

Pushing a button sends a message over UDP to a wifire16 board with a RN-XV radio, which activates the solenoid valves. Each time the wifire16 receives a message to activate a flame effect, it increases that effect's shut-off time by 100ms. Since the update messages are sent out approximately every 50ms, holding a button will keep the flame effect constantly on, but an interruption in communication will cause the effect to shut off quickly.

The tablet interface is a great alternative to using physical buttons - having it be wireless seems to make it magic to many people! I'm hoping to integrate the EEG headset for Pyrokinesis to the tablet interface for this summer, and bring the Coat Rack with both the Pyrokinesis and Dance Dance Revolution pad controls to Atomic Lollipop again.

EICRB |= (1<<ISC60)|(1<<ISC61); // sets the interrupt type
EIMSK |= (1<<INT6); // activates the interrupt

For more information, see sections 11.0.2 and 11.0.3 of the ATMega32U4 datasheet.

To set the interrupt function, define it in the normal AVR way:

ISR(INT6_vect) {
  // interrupt code goes here
}

The interrupt type is described in Table 11-3 of the datasheet, and is similar to interrupts 0 - 3:

INT6 uses Port E Pin 6 (PE6), which corresponds to Digital Pin 7 on the Leonardo.

I've been working on cleaning up the KiCad files; many of my projects are now in my new repository on GitHub. I've also been trying to make sure that all of the symbols and parts are in the libraries, the schematics are back-annotated with footprints, and all of the other details are included in the project, schematic, and board files. This project cleanup is taking a while, so while not everything is online yet, it's getting there.

If you're interested in following what I'm working on or taking a look at any of the PCB designs mentioned here, you can find all of my repositories on GitHub under propane-and-electrons.

The first glove IMU prototype had a couple of showstoppers. In particular, the KiCad symbol for a USB connector has the D- and D+ lines reversed. I was also using a standard USB pinout, not the 5 pin connector that mini- and micro-USB has. With these problems fixed, and a few other modifications such as moving the MPU-9150 sensor chip out from underneath the metal radio shielding, it was time for another prototype run.

Using a stencil for one board was a lot of work, so this time I used a solder paste syringe. Even though the needle was not as small gauge as it should have been, applying the solder paste was much easier and more consistent than my attempt at a stencil with card stock and paste that wasn't warm enough. Unless I'm making many boards, this is the method I'll use in the future.

The assembly method was the same as last time: apply solder paste, place parts with tweezers, use the hot plate to reflow the solder, clean up bridged joints. This time there were far fewer solder bridges, and finding them was easy using a USB microscope.

Fixing them was as simple as wicking away the extra solder with copper braid, applying some flux, then just touching each solder joint with an iron.

In the end, I assembled two boards. On the first board I left the MPU-9150 chip out; I wanted to make sure the rest of the board was tested before committing an expensive chip. Initially I had the same problem as I did on the first prototype: the ATMega32U4 would accept an Arduino bootloader via ICSP, but it would not work over USB. On the first prototype, this was due to the D- and D+ USB lines being reversed; in this case, the 32U4 pins weren't soldered well enough. Adding solder to dry joints fixed the problem. Once this was solved, I tried adding the MPU-9150 using a hot air station, but ended up lifting the pads on the board.

Where did the pads go? On the bottom of the QFN chip!

The second attempt included the MPU-9150 as part of the hot plate reflow process. Fixing the solder bridges on the QFN pads involved the same process as on the larger components and wasn't difficult.

The good news is that the hadokenIMU board works. I tested the sensor with the example programs from Jeff Rowberg's I2C Device Library, and it communicates data back to the Arduino program over I2C without any problems. (Note: the MPU-9150 is pin-compatible with the MPU-6050, and the example program there will work with the 9150.)

The assembled IMU board is just smaller than the 1000mAh battery it uses:

The design files have been uploaded to the project repository on GitHub, details and documentation will be posted soon.

The gloves were originally assembled using off the shelf parts. The main components of the glove hardware are an Arduino-compatible IMU, a radio, and a LiPo battery charger. The first prototype used SparkFun boards, attached to plastic pieces:

Once the gloves were successfully streaming data, the parts were boxed up for protection. The original gloves used XBee radios, but we moved to WiFly in the second year due to range issues. This also required the use of the Adafruit XBee Adapter Kit instead of the SparkFun XBee Explorer, as the version at the time did not do proper level shifting. The second year gloves had three boxes, one each for the IMU, radio, and LiPo battery and charger:

While this glove design worked (and was held together by beautiful leatherwork done by Carl Penny), it was still bulky, rattled when people threw strong punches, and the quality of some of the boards was a bit suspect - we lost multiple Micro USB connectors from the SparkFun charger boards.

Up until a few weeks ago, I hadn't done any real surface mount electronics design, and only a small amount of SMD assembly. A glove hardware redesign seemed like a good project to work on, so I decided to make custom glove hardware that would incorporate all of these components into one board. The design goal was to have an Arduino-compatible board, using a ATMega32u4 microcontroller, with integrated 6- or 9-axis IMU, headers for a WiFly radio, and LiPo battery charger. The gloves currently use 1000mAh LiPo batteries, so the board would hopefully be no larger than 2" x 1.32".

The first glove prototype came together quickly. I kept the parts mostly to 0805 as I'd been able to work with them before without any difficulty. The original design looks like this (minus many 3D models):

It uses the MCP73831 for LiPo charging, the 32u4 for the microcontroller, and the InvenSense MPU-9150 9-axis sensor. This would have to be a SMD project - the MPU-9150 only comes in a QFN package. The board production only took three days by Seeedstudio, giving me ten of these:

The plan was to use a stencil and solder paste - which, although I'd never done before, seemed like a good idea because I have a laser cutter. This took a decent amount of work using CorelDRAW, Inkscape, and LaserCut 5.1, but eventually gave me a stencil that was just about the correct size.

Some examples of testing with card stock to determine a good speed and power level:

The last of the parts came in today, so I attempted to put it together. First up was using the stencil and solder paste. This was the hardest part of the assembly - getting the paste to the pads cleanly and uniformly. I felt that this may have been way too much in some areas (especially the MPU-9150) and not enough in others, but figured I'd give it a shot:

Placing the parts was surprisingly easy using a pair of tweezers. I started with curved tweezers but eventually found regular ones were easier to work with:

From there, the board went on my hot plate. The smaller parts snapped into place easily, but there was definitely too much solder paste on the two chips. The 32u4 had many solder bridges, and the MPU-9150 didn't seat itself properly. I cleaned off some of the excess solder around the MPU-9150, reheated the board, and nudged the chip. It seemed to fall into place without too much trouble:

Unfortunately, I had no solder wick readily available, so I wasn't able to fix all the bridged pins on the 32u4. It definitely was way too much solder paste, giving huge bridges such as this one:

So while I haven't been able to test the new glove hardware prototype yet, the surface mount soldering for it was much easier than expected. The total time for placing parts and soldering was just under two hours, giving me this:

I'll be cleaning up the 32u4 tomorrow and testing the board's functionality then. I'll have a full technical writeup including schematics and layout files once it's been tested and any revisions have been made. This design looks like it will be a huge improvement over using off the shelf parts, and allow us to make gloves that look much nicer for our next run of Super Street Fire.

Each effect head has a controller board which operates the fire system, as well as the effect and safety lighting around the protective caps that cover the plumbing. Each cap has a ring of red LEDs that activate when the system is armed, and the caps on the inner rails have blue and green LEDs that correspond to the player activating the flame effect. The control boards are enclosed in plastic containers and buried in the sand to keep them hidden and protect them.

The control system was modeled after the wifire16 solid state relay board, but with a smaller number of outputs, enough to control one flame effect and its safety lighting. The boards have many of the wifire16 features, including full Arduino compatibility, separate system and load power, and reporting back to the microcontroller whether the system is armed. Having one control board per flame effect also meant that the boards could be used to switch AC power to the hot surface igniters from the primary control system.

One of the biggest issues with the SSF v1 installation was that the XBee wireless link was not reliable. To fix this, the new control boards were designed to use a wired RS-485 serial interface. Each board has two RJ-45 connectors for input and output, and a termination header if the board is the last in the chain. The connectors take standard Ethernet cables for ease of setup and reuse.

The assembled control nodes look like this:

The microcontroller system is in the upper left, the four DC channels are on the right, and the AC system is on the lower left. This was my first design using line voltage AC, so there's a pretty wide gap between the AC system and the rest of the board, and the AC system is on a fuse. The boards also have a built-in flame sensor using an infrared LED. We didn't have the time to implement this functionality in our control software, but it may show up in a future release.

The extra control nodes have since been put to use in a few other projects, as wired control of 4 DC / 1 AC systems has been very useful. The four DC channels all have PWM capability, making the board great for controlling 12v RGB LED strips.

I'm sure I'll be reusing this board for future projects, and hope that other people can find it useful as well for fire and lighting control. Future plans for this board include writing DMX-compatible firmware so that they can be attached to existing DMX networks (for lighting control only, please!). A full writeup of the board will be posted soon in the projects section.

As part of the project, I designed and built a new flame effects system (fuel heating system, manifold, large regulator, 32 effect heads using hot surface igniters) and the electronics to control it (individual control nodes that take commands over RS-485 and operate the flame effects and LED lighting).

There will be many more posts about SSF and the individual systems coming up, and the flame effect control node design files have already been checked in to the repository. But for now, here is a picture of me riding an accumulator tank wearing someone else’s cowboy hat:

The XBee on the wifire16 can run in simple point-to-point (AT) mode. It’s possible for one coordinator in API mode to send commands to many wifire16 boards in AT mode. Each board communicates directly with the coordinator, and the coordinator chooses which board to talk to.

A simple control program that runs on the microcontroller will read one character over the serial link. 0-9 and A-F will toggle channel 1 – 16, and ? will prompt the board to reply with + or – based on whether the solenoid side power is armed. For more complicated applications, the board can be wired in to external sensors.

The end result looks something like this (the final product will have red solder mask):

More details on the wifire16 can be found on the project page.

The wifire16 is the heart of Super Street Fire electronics. Currently SSF uses six wifire16 boards: three for fire and color control solenoids, one for 12v LED lighting in the round timer, and two for 12V LED lighting in the player life bars. More on this soon, but here’s a teaser of what the wifire16 boards can control:

The end result is this, a three channel wireless solenoid controller:

I’ve put up a project page for my business card with more details on the hardware, the KiCad design files, and some example programs to run it.

My hope was to make a memorable card, but also one that’s useful (at least, for other people who create fire art), and one that can be assembled as a project by someone without a lot of electronics experience. I hope that at some point I’ll find someone else’s project using my card as a controller.

I know I’m not the only person who has ever made a PCB business card. However, I’d like to think that mine is particularly awesome; not everyone can say that their business card is a wireless flamethrower controller, and use it to make things that they probably shouldn’t bring across international borders:

“If this were a bomb, would I really have my name, phone number, email address, and website printed on it in a prominent location?”

I hope I don’t ever have to have this conversation.

KiCad is an open source EDA (electronic design automation) suite, used for schematic capture and designing PCBs (printed circuit boards). It’s considered to be the “open source equivalent” of EAGLE, another well-known and used program in the OSHW world.

I originally chose KiCad for a simple reason: I was learning how to make PCBs, and while everyone I knew used EAGLE, the board I wanted to make was larger than EAGLE would create with its free version. KiCad was one of the two major alternatives (the other being gEDA), and was the tool that I learned how to do PCB design with.

Over the last three years, I’ve considered switching back to EAGLE and buying a license for it. This is primarily due to the community support for EAGLE, e.g. SparkFun releasing parts libraries and schematics in its format (and requiring it for projects sold through their site).

I’ve decided to stay with KiCad and never made the switch back because I feel very strongly about using free and open source software for open source hardware designs. With the development of EAGLE to KiCad parts converters, the advantage of using EAGLE has been becoming less of an issue; creating new parts in KiCad is also easy and has also never been an issue to stay away from it.

To help encourage other people use KiCad, I’m releasing all of the parts libraries and footprints I create and use in the Google Code repository I’ve set up. I hope that these are of use to other hardware designers and that it helps promote an excellent open source EDA project that I’m happy to have found.

Some Links

• A comparison between EAGLE and KiCad [bigmessowires.com]
• Another comparison [curiousinventor.com]
• A KiCad tutorial [teholabs.com]
• The OSHW logo for KiCad [wayneandlayne.com]