Nov 5 2013
I've been working with the Seeed Studio GPRS Shield in a project for a flame effect controller. The shield and underlying SIM900 module are great; sending and receiving calls and SMS messages has been very easy.
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.
Oct 21 2013
I recently ran out of my PCB business cards. Rather than just get another run printed, I designed a new one. Inspired by my last post on using DMX512 with a fenode board, the new cards are Arduino-compatible three channel controllers with an RS-485 interface.
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!
Sep 14 2013
Flame effect controller, or LED lighting controller?
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.
Sep 11 2013
This year's big fire art project was called the Charcade - a collection of seven fire art games set up in one big flaming arcade at Burning Man. Site 3 Fire Arts brought two projects: Super Street Fire, a reimagining of Street Fighter 2 in a ring of 32 flame effects, and Riskee Ball, 10 giant Skee Ball lanes that shoot fire when you score points. We also collaborated with five other fire arts projects and groups: Dance Dance Immolation by Ardent Heavy Industries; Rock Inferno, by Ar[sonic] Creations; Flamethrower Shooting Gallery, by Matisse Enzer; Toxic Bloom, by Ethan Garner, Christopher Linder, Joel Greenwood, and David Dowling; and Touch Me, by Noah Rosenthal and Nathan Clark.
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!
May 12 2013
The MiniSSC protocol used by some servo and relay controllers is very simple:
0xFF [channel] [value]
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.
Apr 17 2013
In 2010, I worked on a project that required both flame effect controllers and very low resolution LED panels. The Heart Machine had 20 interactivity stations with touch-sensitive panels, requiring multiple participants at different stations to activate the flame effects. The panels were LED boards and a piece of metal screen behind acrylic; the screen was the line for a QTouch input, and the LEDs were controlled by three TLC5940 chips.
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.
Apr 9 2013
I've just put the hadokenIMU up as a fundraiser project on Tindie. I'm hoping to pre-sell 50 units as a way to reduce the per-unit costs as well as get them professionally assembled; this will help us get 5 pairs of motion sensing gloves for Super Street Fire, and will also help me with my first attempt to sell an open source hardware project.
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!
Apr 3 2013
I've been starting to work with a 5050/PLCC-6 RGB LED that is usually called WS2811 online, but sometimes called WS2812. It's a fantastic LED that is very bright and has the constant-current driver chip built in to the actual LED. It takes three inputs: 5V power, ground, and data in. Each LED takes 24 bits (8 bits for each color channel), then buffers and retransmits the rest of the data stream to the next LED in the chain.
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)
Apr 2 2013
Back in November, I taught a class at Site 3 coLaboratory on Wireless Communication With Arduino: Using the RN-XV to communicate over WiFi. This was a class for people familiar with Arduino who wanted to add WiFi to their projects, in the same way I did with the wifire16 boards - primarily building the XBee Adapter boards and configuring the radios themselves through the serial interface.
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
Mar 25 2013
The Coat Rack is a flame effect with eight effect heads (individually controllable solenoid valves) that sits on top of a 100lb. accumulator. I have a number of control systems for it, and have just updated a project page for it with some details.
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.
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.
Mar 19 2013
The documentation for Arduino's attachInterrupt function lists the pins for the four interrupts available on an Arduino Leonardo. But the Leonardo uses the ATMega32U4, which has a fifth external interrupt (called external interrupt 6, or INT6, just to be confusing). INT6 is not available from the attachInterrupt() function, but is available if you access it directly via the registers EICRB (External Interrupt Control Register B) and EIMSK (External Interrupt Mask Register):
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:
// interrupt code goes here
The interrupt type is described in Table 11-3 of the datasheet, and is similar to interrupts 0 - 3:
||Any logical change on INT6
||Falling edge between two INT6 samples
||Rising edge between two INT6 samples
For INT6 to work, it requires the AVR I/O clock to be present, unlike INT0 - INT3.
INT6 uses Port E Pin 6 (PE6), which corresponds to Digital Pin 7 on the Leonardo.
Mar 13 2013
All of the electronics projects I write about here are open source hardware. The schematics, the hardware layouts, and the component libraries are all freely available.
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.
Mar 9 2013
As always, prototypes have mistakes.
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.
Jan 23 2013
One of the hardware systems of Super Street Fire unrelated to fire control is the motion sensing gloves we use for gesture recognition. While playing the game, players wear special gloves which have multiple accelerometers, gyroscopes, and magnetometers in them. The gloves take the sensor data and stream it wirelessly to a central control system which does gesture recognition. The control system then activates the fire control system based on what gestures are recognized - for example, a punch will send a wave of fire towards the other player, but different kinds of punches will change the timing and amount of fire. A jab will send one quick wave, while an uppercut will be slower but activate two flame effects at the same time.
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.
Jan 20 2013
The flame effect system used in Super Street Fire is a ring of 32 flame effects, split up into two inner rails and an outer ring. Participants play the game by wearing motion sensing gloves and throwing punches and other special moves; with each successful gesture, a wave of fire and lights will hurtle towards the other player. The perspective inside the ring looks something like this:
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.
Sep 8 2012
The reason this site has been so silent lately is that I tried to start it up just before starting on version 2 of Super Street Fire. Over the last nine months, I’ve been working with a great team of people to design and build a considerably updated version of the video-game-with-flame-effects and bring it to Burning Man as an honorarium installation.
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:
Nov 8 2011
The wifire16 is a 16 channel wireless solid state relay. It acts as an Arduino clone with built-in XBee support, and activates the output channels via shift registers connected to optoisolators and MOSFETs. The output power can use higher voltage DC (within reason, e.g. solenoids that operate at 24 or 48V) as it’s just switched through the board.
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:
Nov 4 2011
A few months ago, I had the idea of making a PCB business card. At the time I was working on Super Street Fire, and developing a wireless solenoid controller for triggering flame effects. (More on this soon.) I took the same basic idea, removed everything unnecessary (including the microcontroller), and set aside an area for contact info. With the remaining space, I found I could fit three optoisolator/MOSFET circuits comfortably.
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.
Nov 2 2011
One of the reasons I decided to make this site is because I am very interested in Open Source Hardware. Arduino is what made me realize that I can do hardware work without a background in electrical engineering; projects like RepRap and commercial ventures like MakerBot Industries have shown me that physical things can be just as accessible for DIY makers as software.
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.