Browsing Category Project Updates

Ottawa Mini Maker Faire 2014: Badge Edition

The weekend before last in Ottawa (August 16-17, 2014) was the fourth annual Ottawa Mini Maker Faire. Mike, Chris and I exhibited the pinball machine – more on that in a trip report later. For this Faire, however, I worked with the organizers on making some special LED name badges for the Makers. This article serves as documentation of that project.


Britta Evans-Fenton, one of the Faire’s organizers, came out to Mini Maker Faire Montreal (June 7-8, 2014 – again, trip report pending), so I got to talk to her there about this year’s Ottawa Faire. On the train trip back home to Toronto, I got the idea of having some sort of PCB name tag for the participants. I toyed with the concept for a while, and eventually came up with an idea, which I sent to Britta. This was June 18, at this point.

Maker Faire Badge Concept

We promptly both got busy, it seems – I dropped the project for a bit due to other priorities (such as Maker Faire Detroit preparations – once again, trip report pending). In the mean time, however, I somehow had the foresight to order sufficient dirt-cheap battery holders and power switches from Aliexpress. Power switches were something I wanted from the get go – we want the batteries to last all weekend in these things, and a good way to do that is to make sure that the light can be turned off at night, when you aren’t wearing it.

Around the first week of July, we started trading ideas back and forth, and I went back to the design. The idea at this point was for a silhouette for Centre Block illuminated by some LEDs, the Mini Maker Faire Logo, some silkscreened text of the badge type (Staff, Volunteer, Maker, Sponsor), and a large silkscreened area for the wearer’s name.

On July 15, I did some 3D renders, and send off for prototypes, in two sizes – a mini one that would be best with a pin backing, and a larger one that would be best for a lanyard.

Small badge renderBig badge render

The boards came back on July 23rd – I went for express shipping – and while we were waiting for them to arrive, Britta and I came up with a slightly different plan, to cut down on costs:

  • Use the lanyard-sized boards
  • One kind of board – no silkscreen text for badge type. This meant we were ordering more of one kind of board, so the quantity discounts were higher, and we only paid one setup fee.
  • Larger area for writing
  • Different LEDs for the different badge types – colour-fade for sponsors, white for staff, blue for Makers
  • Red PCBs for all

So when the boards did arrive, we already had a few changes ready to be done.

I quickly populated one when I got the boards, and fired a video up to Ottawa to demonstrate it.

After looking at the prototype boards, I also decided that the lanyard holes needed to be bigger – about a quarter inch / 6.35mm. I made the changes and sent them off on July 29, once the Detroit Faire was done. They shipped out on August 4, and arrived on August 7. From the 8th to the 14th, I started assembly at home, first putting the battery holders and switches on each board, then starting to add LEDs as numbers came in for sponsors, Makers, etc.

During this time I also did some battery life testing, 4 hours at a time. I was a bit worried about power draw given the lack of current-limiting resistors in the design. The Blue ones passed with flying colours – after 16 hours of on time, they were still usable. The colour fade ones did not – Blue went out after about 2 hours, and Green went out after about 6, leaving only Red working at the 16 hour mark. Because of this, the Partner badges with colour fade LEDs got 150 ohm resistors added by way of an x-acto knife and careful soldering.

Around the 14th, we remembered that we needed lanyards for these. I found some cotton and nylon cord at Wal-mart that fit the bill – 3’ sections worked perfectly for a lanyard (it came as 45’ lengths, hence the US Customary units). This was more expensive than I would have liked, but we were time-constrained. Wal-mart ran out of cotton cord, so I had to use Nylon as well, which required sealing to prevent fraying. This was done with fire, which had predictable results.

Apparently honey can be used to treat burns. I had no idea.

Badges were ready a few hours before we had to leave for Ottawa. Our departure was delayed a bit by car trouble, so Britta and I had to coordinate the transfer of badges. I had intended to deliver them the night before, but we got to our hotel at 3:30 AM, so that was out of the question, and us arriving at the Faire the moment it opened at 8:00 AM was… unlikely. So they were left with the front desk at the hotel.

From there, Britta and company handled distribution to each of the Makers, and there was much rejoicing and jubilation.

The Design

There were initially two designs: the small and the large. The small one was meant to be worn as a button, with a pin backing. It’s 1.95” by 1.45”, so it fits within Seeed Studios’s 5cm x 5cm maximum size. It doesn’t have a writing area on it, but does have two small (3.2mm) holes for a lanyard. The larger prototype was 3.4” by 1.95” and had a writing area, but was otherwise identical to the smaller one.

Front side of the small and large prototypes.Back sides of the prototypes

Electrically, the badge is incredibly simple – a 3V battery holder (CR2032), a switch, and 3 LEDs in parallel. This is actually much too simple, really – the LEDs should each have a current limiting resistor. This decreases the brightness slightly, but decreases the initial current draw dramatically, depending on the forward voltage of the LEDs in use. It also ensures that the LEDs are of comparable brightness – otherwise one or two will be substantially dimmer than the other(s), because the characteristics of different LEDs can differ wildly. I made the decision, however, to omit these, for two reasons:

  • I was planning on using LEDs with a forward voltage around 3V so the effects should be diminished, and
  • It would save a TON of time if I didn’t have to solder in 600 resistors as well.

Badge Schematic


The badges were build first by soldering the battery holder to the back. This has nice big tabs and pads on the board, so it was easy, but to ensure that the battery holder stayed in place both during assembly and afterwards, I used some scrapbooking glue dots on an applicator to affix them to the boards. The specific one I used was an Ad Tech Dot Glue Runner, which is purple.
AdhesiveAdhesive on the battery holder footprintSoldered battery holder

Next, the tiny SMD switches get soldered on. You get good at these quickly when you do a couple hundred of them.
Power switch

Once you’re done mounting those, the board joins the others in the pile on the floor.
Pile of badges

Once the numbers for how many of which colour started coming in, the LEDs went on. For the Maker ones, we went with a 5mm Blue LED in the middle, angled down to have a spotlight effect on the Peace Tower, and also to avoid blinding the wearer as much as possible. The two side ones were lovely diffused 3mm Blue LEDs that I previously used on my Christmas ornaments. All of these LEDs came from my personal stores / junk bin.

Partner badges got diffused colour-fading LEDs that I had for another project, and Staff badges got white LEDs that I never actually tested, but we only needed 2 of these badges. All told, it took a couple of evenings to do the battery holders and switches, and then 3 more to do all the LEDs.


Handling the artwork on the board is a bit tricky. I have a technique, though:

  1. Prepare the art you need in your favourite drawing program (or whatever’s available). I used Paint.NET in this case. I usually try and set the dimensions of the artwork based on rendering it to the PCB at 300 DPI – so if I want the final product to be 2 inches wide, I make it 600 pixels wide. Make sure the artwork is black and white.
  2. Save it as a BMP file. Odds are you won’t be able to save it as a monochrome BMP – that’s fine.
  3. Open the BMP file in Microsoft Paint, and save it as a Monochrome BMP file.
  4. Launch EAGLE, and create a library for your artwork.
  5. Create a new package for the artwork.
  6. Type “run import-bmp.ulp” in the command line in EAGLE and hit enter.
  7. Open your BMP file, and select Black as the colour you want to import.
  8. Set the scaling mode to DPI, and use whatever DPI value you used in step 1.
  9. Set the starting layer to 25 (top silkscreen) to put the artwork on the top silkscreen, or 29 (tStop) to put it on the solder mask.
  10. Hit Run.
  11. Zoom in and delete the filename text in the lower left hand corner.
  12. Save the library and add the package for the artwork to the board layout.

Note that this is mostly from memory – I reserve the right to come back and revise this to be accurate.

Design files

The design files – done in EAGLE CAD 5.12.0 – have been released on Bitbucket. Use them in good health.


The badges went over really well, and it was incredible seeing so many people using something I’d made in one place. If you look at different photos of the Faire and see a blue glow on someone’s face, odds are they were a Maker 🙂

I got a lot of compliments about the badges, and some ideas from people for next year. I’d like to do something a bit more hackable – ideally something with a microcontroller – but I need to figure out what we can actually make it do, and still stay within a budget, both in terms of power and price. Having 200 people with a pair of AAAs hanging from their necks all day might not be so welcome, so staying with a CR2032 is ideal. Next time we’re also definitely using pre-made lanyards – they’re cheaper and less injury-prone for me.

In terms of changes, I would have liked to order things earlier so that we could have avoided paying for fast shipping (and then paying the shipping charge again in the form of HST and fees for charging HST). Also, I would have definitely added current-limiting resistors – towards the end of the first day I was seeing LED brightness differences which they would have prevented.

Category : Project Updates &Trip Reports

New project: the PiMinder

We’ve started work on another new project, which we’re calling the PiMinder. It’s still a work in progress – don’t have any photos yet – but it’s coming along, so it’s probably best to start writing about it before things get really, really hectic.

The PiMinder is a “market minder” – a device for keeping track of your shopping list. Old-fashioned ones were boards with common grocery items – milk, eggs, bread, etc. – painted on, and you’d check off what you need by putting a peg in a hole next to that item. The advantage of moving to a digital version is that you can synchronize it with a Web service, and check in on what you need from your smartphone, tablet or desk at work. That makes it a LOT easier for couples and families to keep track of what they need from the grocery store.

This wasn’t our idea originally – someone else already made one on Instructables. There are a few problems with that one, though:

  • No source code is given.
  • The light-up buttons are REALLY expensive
  • The app only works on iOS
  • The WiFi module is pretty expensive

We’re taking a different approach:

  • Raspberri Pi Model A based – $25 for the board plus $5 for a WiFi adapter is about the same price as the WiFi module used in the Instructables one, and gives us the controller as well
  • Circuit boards with six light-up buttons connected over I2C. We use the MCP23017 I/O expander rather than 74HC165 and 74HC594s gives us both inputs and outputs in one part, and lets us chain up to 8 boards of light-up buttons off the same I2C bus. The MCP23017 is well-supported on the Pi.
  • An IKEA RIBBA picture frame as the enclosure. This can be scaled up depending on how many boards/items you need.
  • Three sheets of laser-cut plastic added to the RIBBA frame. One to hold the circuit boards in the frame, one face plate, and one plate to mount labels on. These last two form the front panel of the device.
  • A Node.js-based service for synchronizing grocery lists. This will use Angular.js for editing the list and using it from a desktop, tablet or phone. A interface will allow real-time updates when a list is modified in any way. That way, the app and the device are always in sync.
  • A much cheaper light-up button, similar to this guy from SparkFun
  • A Node.js-based program running on the Raspberry Pi to receive events from the web service and send updates based on buttons being pressed. Using Node.js makes it easy for us to use the same interfaces as the mobile app, which really simplifies the server. There are also some decent libraries for working with the MCP23017.

This architecture lets us make multiple PiMinders that point at the same list (but not necessarily the same items on that list), and have them all keep synchronized with each other. It also lets us keep costs down – estimated cost of the prototype is under $100, and subsequent ones are much cheaper due to minimum orders for circuit boards and what not.

This project is going to be evolving quickly. Currently, the boards are in and populated, and the server and web app are close to working. Laser cut plastics have been designed and just need to be actually cut. From there, it’s a matter of assembling physically and finishing the Pi-side software. Getting the first version of that will be simple – getting a nice configuration interface going is going to be a bit trickier.

The plan is to have this ready to demonstrate in time for Maker Faire Montreal on June 7 and 8. Even with spending a week in San Francisco for Maker Faire in… wow, less than two weeks… this is looking very doable.

One more thing: this project will be fully open-sourced when it’s working. That includes the server-side Node.js code, the Raspberry Pi code, PCB layouts, and CAD files for the laser-cut plastic in the RIBBA frame.

Category : Project Updates

Introducing the 2013 Christmas PCBs

Two years ago, I made a snowman circuit board. It was a fairly simple board – white with black silkscreen artwork, and a bunch of LEDs for the scarf and buttons on the snowman. A small PIC microcontroller handled blinking the LEDs in various patterns, and a button allowed the user to switch between patterns, as well as turn the unit off. Power came from a small watch battery. I made 100 of them, and they were a huge hit.

I’ve shown these at various Maker Faires over the two years since, and one question always came up: “Are you selling these?” Two years later, I’ve finally gotten the message, and came up with a new design. While the original was an all-Surface Mount affair (since I was the one building all of them), this new design is a through hole design, intended to be distributed as a soldering kit. There are four different designs, as well: a snowman, a snowflake, a candy cane, and a christmas tree. It’s also designed around an AVR microcontroller so that an open source toolchain can be used.

In this post, I’ll go over each of the boards quickly. Future posts will cover how the hardware and firmware works, how to assemble them, and how to modify the firmware to change the blinking patterns.

Candy cane board

The candycane board has 16 LEDs, alternating 8 red and 8 white in my construction. This can be changed when the user builds it on their own, of course. The board is made with a red solder mask and white silkscreen. It has seven patterns and an off state, which you can rotate through using the button on the right-hand side of the board. The patterns are:

  • Off
  • All lights on
  • All lights blinking
  • Alternating red and white
  • Fill in from the short end of the candy cane
  • Marquee
  • Twinkling
  • Fill in from the long end of the candy cane

Here’s a video showing all of the patterns, in order:

Christmas tree board

The Christmas Tree board has 17 LEDs, with a yellow star at the top and whatever arrangement the user wants for the lights in the tree. The board has standard green solder mask and white silkscreen. The patterns are:

  • Off
  • All lights on
  • All lights blinking
  • Marquee
  • Fill in from the right
  • Fill in from the bottom
  • Twinkle all lights
  • Twinkle all lights, except the star, which is always on

All of these are shown in the following video:

Snowman board

The snowman consists of 10 LEDs: one red nose, three white buttons, and six LEDs along the scarf. The board has a white solder mask and black silkscreen. The patterns are:

  • Off
  • All lights on
  • All lights blinking
  • Nose on, all others marquee
  • Nose and buttons on, scarf marquee
  • Twinkle all lights
  • Nose and buttons on, scarf twinkling
  • Nose and buttons on, scarf fills in from the right

All of the patterns are shown in this video:

Snowflake board

The snowflake is my favourite. It has 19 LEDs total, blue and white alternating along six spokes of a snowflake. It’s on a board with blue solder mask and white silkscreen. It has the following patterns:

  • Off
  • All lights on
  • All lights blinking
  • Alternating blink
  • Starburst (fill in from centre)
  • Spiral fill
  • Pinwheel (basically a rotating line)
  • Twinkle

All of these are shown in this video:

What’s next

The boards have turned out very well. I’m still waiting on a few parts to arrive, so unfortunately I’m not going to be selling many this year. However, with a few tweaks I should have them ready well before Christmas next year.

The next few posts will go over the design and build instructions, as well as some lessons learned in the process. These boards are being released as open source, so you’ll be able to make your own if you like and modify as you see fit.

Category : Project Updates

Update: Bluetooth Polygraph

Just a quick update on the Bluetooth Polygraph project. More description is coming soon – possibly full documentation before the Waterloo Maker Faire this weekend – but this’ll have to do for now.

The PCB has been assembled, and two of the three sensors tested:
Bluetooth PolygraphBluetooth Polygraph Sensors

The pulse sensor (actually a Pulse Sensor Amped) and the GSR sensor (based on / blatantly copied from Make’s Truth Meter) both work nicely over Bluetooth. A processing app is currently graphing the data on a strip chart. I still have to build the respiration sensor, and get the app working on my Nexus 7, but I’ve already tried the stripchart (slavishly copied from this code on OpenProcessing) on the Nexus, and it worked nicely. Bluetooth functionality will be provided courtesy of the Processing BtSerial library from the Arduino folks, which I’ll be providing instructions on how to install, as well (since it doesn’t come with a .jar file).

So there’s still some work to do, but a manageable amount, and we should be done and possibly even documented in time for Waterloo Maker Faire.

Category : Project Updates

New PCBs are in!

We just got a bunch of new PCBs in, which means more projects are going to move forward.

Amongst the fun stuff that just came in:

  • StatusLight 2.0 – A cost-reduced StatusLight using an ATTiny85 and WS2812 LEDs.
    StatusLight 2.0 PCBs
  • boards – the Base Board, Score Display Board and Raspberry Pi CAN Board for that system (currently under development) Base BoardDIYPinball Score Display moduleDIYPinball Raspberry Pi CAN interface
  • Bluetooth Polygraph boards – just in time for the Maker Faire in Waterloo this weekend:
    Bluetooth Polygraph PCBs
  • Project Vending Machine 2.1 boards – an upgrade to use Raspberry Pi GPIOs and I2C rather than an Arduino:
    Project Vending Machine I/O board
  • WS2812 Breakouts, for some experiments with these fun little LEDs:
    WS2812 Breakout boards
  • Taskmaster boards, for finally making some progress on my time tracking project:
    Taskmaster PCBs

Hopefully this tides us over for a bit, though I have a feeling we’ll be making another order this summer.

Category : Project Updates



The NESVerter is a conversion board to make an original NES controller into a USB gamepad. It originally came about after I made one based on this one over on for my friend Kat. I wanted to try making a PIC-based version that would fit inside an NES controller without modification to the case. This is the result.

The NESVerter is a small PIC18F14K50-based board that solders into an NES controller in place of the standard 4021 shift register. It requires removing that part. For more on how the NES controller works, visit here.


There are two versions of the hardware, mostly the same. Version 1 is a slightly larger board, with a reset and a bootloader button so you can download new code to the board. Due to a miscalculation on my part, Version 1 requires filing down part of the case. Version 2 is smaller (thus no filing) and loses the buttons in favour of using the controller’s buttons on power up to activate the bootloader.

NESVerter versions 1 and 2

The schematics are as follows:

NESVerter 1.0 Schematic

NESVerter 2.0 Schematic

This is a very, very basic USB PIC setup. There are some pads for ICSP and USB connections, a couple of capacitors for the PIC, a crystal and load caps, pullup resistor on reset, and the 330nF capacitor on the VUSB pin. The 4021 is only used in the schematic as a footprint – it’s actually populated as pins connecting the board in place of the removed 4021 in the NES controller. Pullup / pulldown resistors on the inputs aren’t required, as they’re in place on the controller PCB (as printed-on carbon).


The firmware can be downloaded at our Bitbucket site here. It’s based on JALv2 with JALLIB. HEX files are also included. The first versions were based on Microchip USB stack examples, but licensing issues with those led me down the JAL route, which actually turned out well.

There are actually two parts to the firmware. The first is the USB HID bootloader, which allows you to download updated code to the controller without taking it apart and breaking out the PICKit2. There are two versions – one for the V1 hardware and one for the V2. The V1 one uses the buttons on the PCB, while the V2 requires that you hold down the A and B buttons on the controller while plugging it in to enter the bootloader. I think the V2 one will work on the V1 hardware, so just use that. The bootloader gets loaded on via the ICSP board and something like a PICKit2.

The second part of the firmware is the actual gamepad firmware, which you load on via the bootloader. This is a very basic USB Gamepad firmware. I copied the USB descriptor from raphnet’s version, and much of the rest of the code comes from this JALLIB sample. All it really does is check which buttons are pushed, and sets the appropriate bits in the USB HID report for those buttons. That’s it. The code is documented if you want to have a look.

Building it

The board is all-SMD, and fairly tiny stuff too. I’m only providing instructions and a parts list for Version 2, as I don’t recommend building Version 1. You’ll need the following parts:

Device Quantity Parts on board Digi-key part number
10K 0603 resistor 1 R1 311-10KGRCT-ND
10uF 0805 capacitor 1 C3 445-1371-1-ND
12.000 MHz Crystal, 5×3.2mm 1 Q1 535-10875-1-ND
22pF 0603 capacitor 2 C4, C5 445-1273-1-ND
100nF 0603 capacitor 1 C1 311-1343-1-ND
330nF 0603 capacitor 1 C2 445-5142-1-ND
PIC18F14K50, SSOP package 1 IC2 PIC18F14K50-I/SS-ND

Note the thickness of the PCB – using standard 1.6mm PCBs is a bad idea here. Pay a little extra for thin, if you have to – I went with 0.8mm.

I won’t cover how to build the board – if you’re experienced with surface-mount soldering, odds are you can figure out where stuff goes based on the parts list above and the silkscreen on the board. You will need to burn the bootloader to the board, however. For that, I use a PICKit2 with a cable and pogopins. The same pads that are used for USB can be used for ICSP to load the bootloader – connection is as follows:

NESVerter ICSP pinout

Here’s how to assemble the controller:

  1. Get an NES controller
  2. Open the controller, and remove the board from the case
    Step 1: Open the controllerStep 2: Remove the circuit board

  3. Desolder the cable
    Step 3: Desolder the cable
  4. Desolder the 4021 chip
    Step 4: Desolder the 4021 chipStep 5: Pry off the desoldered chip
  5. Line up the NESVerter over the IC holes
    Step 6: Line up the NESVerter board
  6. Thread small-gauge wire through the holes, and solder on both sides. Then, clip the wires.
    Step 7: Add wiresStep 8: Solder the wiresStep 8: SolderingStep 9: Cut the wires
  7. Cut the end off the USB cable (the PROPER end – not the type A plug!). Strip and tin the wires.
    Step 10: Grab a USB cableStep 11: Cut off the square endStep 12: Strip off the plasticStep 13: Strip and tin the wires
  8. Solder the wires to the PCB. The pads are indicated with the colour of the wire (G = Green, W = White, R = Red, B = Black) that attaches to them.
    Step 14: Solder to the PCB
  9. Route the USB cable, and reassemble the controller
    Step 15: Start reassemblyStep 16: Put the buttons back inStep 17: Put in the PCB assemblyStep 18: Route the USB cableStep 19: Put the back back onStep 20: Done!

Loading the firmware, and testing it

To load the firmware, you’ll need to use the USB HID Bootloader program that comes with the Microchip Libraries for Applications. The program is in the USB\Device – Bootloaders\HID directory. Follow the following steps:

  1. Open the program
  2. Hold down the A and B buttons on the controller (for the V2 bootloader) or press the bootloader button (for the V1 bootloader) and plug in the controller
  3. The app should indicate that the device was found.
  4. Click the Open button, and open the nesverter.hex file from the code-gamepad directory in the source code download
  5. Click the Erase/Program/Verify button to download the code
  6. When the app tells you, unplug the controller and plug it back in.

To test it, you’ll need an app to test the controller. On a Mac, I use Joystick Show from the Mac App Store. On Windows, you can go into Devices, right click on NESVerter, go to Game Device Properties, click on NESVerter and hit Properties. That’ll show you the state of each button.

Using it

The gamepad is a standard USB HID gamepad, so it’ll work on any major modern OS without a custom driver. You’ll need to consult the documentation for whatever game, emulator, etc. you’re using to see what, if any, configuration it needs to use a standard gamepad. Some emulators on the Mac, for example, require the Emulator Enhancer program to use a gamepad.

Lessons learned, and conclusions

Overall, this project was a big success – the system worked very well for bringing the venerable NES controller into more modern times, and was a very inexpensive way to do so. The first version had issues requiring a little filing of the case to fit the board, but that was easily corrected in version 2. Definitely something to keep track of in future versions – making sure the dimensions are correct before sending boards out for manufacture.

In future, I’d like to do another version of this – without surface mount or stitching together boards, both of which are difficult for people who aren’t that experienced with soldering. I’m thinking of doing one with through-hole parts and Microchip’s newer (and cheaper) USB parts, with a full-PCB replacement for the NES controller. Before I do so, though, I’ll have to find some more NES controllers – they’re getting harder to come by.

Category : Project Updates

Project Vending Machine 1.0


The Project Vending Machine is a vending machine for digital goods – files, specifically. Vending Machine is a bit of a misnomer, actually – no money changes hands in this implementation, but vending machine is about the closest analog that we could come up with.

It’s pretty simple to operate – you plug a USB thumb drive into the USB port in the front, pull the knobs to select the projects you want – kind of like an old cigarette vending machine – and hit a button to copy them. A light for each project tells you if it’s selected, if it can be copied, if it’s copying, if it’s done or if there was an error.

How it came about, I’m not entirely sure. At some point, we determined that it would be useful to be able to distribute digital files from a vending machine. I can’t say for sure what sparked it, but it may have been restrictive download caps. At any rate, we didn’t find anything like this that existed, and figured it could be useful for giving out project details at Maker Faire.

So we decided to make one for Maker Faire Detroit 2011.

Final shot of the front


We investigated a few microcontroller-based methods of building it, but actually building that would be complicated and likely have compatibility issues. I wound up buying an Insignia Infocast 3.5 – a Chumby relative – at a good price at Best Buy. It runs Linux, has various ways of attaching buttons, and has USB support, so it would suit the system nicely.

We determined that the system would need:

  • 1 selector per project
  • 1 RGB status LED per project
  • 1 overall “Copy” button

We decided that 8 projects would be an appropriate number, arranged in 2 rows of 4. We went with a row controller PCB for each row of 4. Given 3 outputs for each status LED and one for the input, this meant 16 lines total per board. This fit perfectly with the MCP23017 I/O expander from Microchip, which would allow us to chain mutiple devices from the Infocast’s I2C serial bus. Up to 8 MCP23017s can be added, which would mean up to 32 projects per vending machine. The start button was to be hooked up to one of the Infocast’s built-in GPIO pins.

The overall architecture was meant to look like this:

Vending Machine Architecture

This approach had a few big advantages:

  1. Linux-based, so a lot of it could be prototyped easily on a desktop machine before adding the hardware-specific stuff later
  2. Infocasts were somewhat available at that time, so we could each have one to work on
  3. Having Linux as a base meant a wide variety of programming languages available to us. We wound up going with a combination of C and BASH.
  4. Having Linux as a base also meant that the file handling stuff was already, well, handled.
  5. Using off-the-shelf I/O expanders meant that no firmware had to be written – only host software. Not having to write and debug firmware nor develop an over-the-wire protocol to communicate with that firmware saved a *ton* of time.


The hardware consists of four major parts:

  1. The Infocast, with its I2C and I/Os broken out via a ribbon cable.
  2. The interface board, which the Infocast connects to, and has an I2C level shifter (the Infocast uses 3.3V, and the other boards were run on 5V)
  3. The row controllers, which have the I/O expanders and the LEDs
  4. The optical sensors for the knobs

I’ll describe each individually.


We did two main things with the Infocast: Replace the SD card with a larger one (described later), and soldering in a ribbon cable to bring out the I2C, a GPIO pin and the UART (for debugging). I don’t have a ton of details on how we did the cabling, but I do have the following photos:

I2C port in the Chumby / InfocastI2C port in the Chumby / Infocast 2I2C port in the Chumby / Infocast 3I2C port in the Chumby / Infocast 4I2C cable coming out of the back of the Chumby / InfocastUART cable in the Chumby / InfocastUART cable in the Chumby / Infocast 2

Interface board

This connects to the ribbon cable, and level shifts the I2C. It then connects to the row controllers. The level shifter is a standard N-MOSFET based I2C level shifter, using 2N7000 transistors. The schematic is more or less like this:

Interface Board Schematic

Interface board

Row controller

The row controller has the I/O expanders, some jumpers for the address of the board, connectors and current limiting resistors for the LEDs, and connectors and pullup resistors for the optical sensors. The schematic is as follows:

Row Controller Schematic

These were built on protoboards, but we do have PCB layouts that we never built. They’re included in the source code further down.

Row controllerBack of a rowLED closeupRow 1 wiring

Optical sensors

To make the system robust and inexpensive, the knobs use a standard break-beam optical sensor with a dowel that slides between the light source and sensor. This way the user isn’t directly interacting with the sensor – making it a bit more robust – and is still fairly cheap. The setup looks like this:

Optical sensor

We used a Sparkfun breakout with some holes drilled to mount it to the frame.


The software consists of three key parts:

  1. Linux on the Chumby. This handles a lot of things – I2C driver, file handling, and even automatically mounting USB drives. About the only thing we changed here was upgrading the SD card in the Infocast / Chumby, which we followed instructions here for.
  2. Programs to interact with hardware. These were written in C, based on samples posted to the Chumby forums. The source code for these is included in the download below.
  3. The overall control script, written in BASH. This was basically a state machine to run the overall process – it would turn on or turn off LEDs for each selected project. They’d be yellow if no USB drive was available, or green if one was. If the drive was available, the Start button would also be checked. Once it was pushed, the script would start copying files, turning the light purple while it was copying, blue if it was done, or red if it failed. It would do this for each selected project, then wait until the storage device was removed before resetting.

The source code is available for download here. To set it up, you’ll need a Chumby or Infocast with developer tools installed – once you SSH into it, just try running gcc, and it should tell you how to get that going. Then, use the Makefile to compile the C programs. After that, edit the shell script to specify the project files. When you’ve got the unit hooked up to the hardware, run the script to operate the machine. It will output somewhat useful debug data as it runs to help determine what it thinks is going on.


I don’t have final plans for the overall machine. It was basically made of a few horizontal “slices” made from Select Pine 1x2s. Top and Bottom were basic rectangular frames, while the two middle ones – for the rows with knobs – had horizontal cross-members, and holes for both LEDs and the selector knobs / dowels. The cross-members were used to make sure that the knobs slid smoothly and straight. Sensors were put on the back edge of each slice, and the LEDs were attached behind the appropriate holes on the front.

After these slices were assembled, they were combined with vertical 1x2s to form the overall box, which then had woodgrain-printed masonize attached to the sides, and MDF panels on the top and bottom. Aluminum trim was added for the 70s Cigarette Machine look. Holes were drilled for the LEDs knobs in the fron panel, and then everything was wired up.

This was a pretty tricky construction technique that didn’t result in anything even close to square or true, so I don’t recommend it in future. That said, here are some photos of the process and the final product:

Materials for building a frameKnobsKnobs 2Clamped frameCorner jointFrame, mostly builtAdding the cross-memberCompleted frameFramedRudie behind barsLet me out!Clamping wiresDrill end of the wiresReady to twistHere we go with the twisting...Doing the twistDrilling holes for the knob shaftsMeasuringMore drillingScrewed togetherDrilling LED holesDrilling dowel holesMore LED drillingMore LED drillingCutting the top and bottomBottom frameTest fitting the framesAnother angle of the test fitKnobs, drilledAll the way throughStop with a hole for a set screwDrilling a set screw holeAssembled frame

Lessions Learned and Conclusion

We learned a bunch doing this project. Using Linux as the basis made some of the tricky stuff really easy, but also made diagnosing I2C errors a bit harder. Having I2C over long distances with poor wiring was a BAD idea – lots of noise would lock up the bus, which made it stop responding and kept the Chumby from reading its configuration EEPROMs on start, making a reboot to clear everything and get it all working again somewhat invovled. So I2C with lots of wire should be avoided in future.

We didn’t get the GPIO-based start button to work, so we wound up using an extra row controller with a single button to do that. This required minimal modification to our scripts and worked pretty well.

The frame was way too big and way too heavy for what it had, and was a pain to move in and out of the Faire. More than a few people remarked on how much it looked like a cigarette vending machine.

The knobs with the optical sensors worked incredibly well, and were a great demo to show kids who were coming by.

The Chumby proved to be a bad choice, once they stopped being available for sale not long after we showed off the project. It worked, but now the ability to duplicate it is severely restricted.

The biggest surprise, though, was that next to nobody had a thumb drive to copy stuff to.

Overall, though, it was a great project that was a lot of fun (though a bit stressful at the end) and was VERY well received. We liked it enough to do a bigger and better version in 2012.

This time with lights on!Front view of the machineIMG_5638.JPGCorner view of the machineProject sign

Category : Project Updates

Project Vending Machine 1.0 Overview Video

In an attempt to document some older projects (as well as continuing to work on new ones!), here’s an overview video of the first Project Vending Machine:

Sadly, now the first vending machine is now gone – it was too big, and taking up space. More projects are underway, though!

Category : Project Updates

New Project: 3D Printer

3D printers are the new must-have tool for people who make things. Personally, I want one for two reasons: designing and building custom enclosures for electronics projects, and putting the heads of my friends on Pez dispensers.

I’ve had the parts for months, and am hopefully going to get it working soonish. Here I want to go over the decisions (if any) behind each piece of the project. (more…)

Category : Blog &Project Updates