As the W&B soda machine has been unplugged for the winter, I am putting the soda machine hack project on hold for a couple of months. In the meantime, I’m returning to some past projects, several of which I never wrote up in the blog. One such project is a system for handling and displaying an ultra-tiny bitmap font on a little graphic LCD, the sort that were on nearly every 90s cell phone and are currently popular with hobbyists.

There are several examples of little font code on the Internet, but those that I saw were all non-proportional (they have fixed dimensions, e.g. a W is the same width as an I) and/or have legibility problems. The characters were also typically 4×7 or 5×7 pixels, neither of which easily fit a power of two without wasting memory — a vital resource when working on a microcontroller with only a couple thousand bytes of program memory. The system I came up with uses a 5×5 bitmap for the character itself, plus four bits containing the character’s width and three bits containing the character’s vertical offset. These sum to 32 bits, a convenient power of two and a the size of a long number on an Arduino. A 5×5 bitmap was chosen because it is the minimum size to accurately display characters like M or E. The vertical offset allows ‘descending’ characters (like j or y) to actually drop below the other character’s baseline without requiring all non-descending characters to have wasted space below them. The character width allows the text to be crammed in more tightly; in the future, it will also allow for ‘alternate’ characters (like ö and ü) to be created by displaying an accent (an umlaut in this case) with a width of zero pixels followed by an ‘ordinary’ letter; the accent mark will appear over the other letter.

To experiment with this idea, I wrote a tool for creating, editing and displaying such a font: CharEdit. The image above links to a screenshot of CharEdit in action. Written in Processing, the program (or ’sketch,’ in Processing terminology) provides a reasonably nice environment for drawing the characters and adjusting the with and offset data, as well as ‘exporting’ the font as Arduino-compatible C code. I intend to release CharEdit once it has been cleaned up a bit. This probably won’t happen for a month or two.

My intention was to implement the font on an Arduino driving a common PCD8544-based display salvaged from an old Nokia cell phone. Since then, I got a small LCD breakout board from my fellow Dorkbot Boston member, Tim. The LCD itself is very similar to the one from the Nokia, but as the breakout board is already breadboard compatible and the LCD is operable on 5V (as opposed to 3.3V), it is much easier to work with. So far, I have basic text display with scrolling; line-wrapping is coming soon. The code is currently in the form of an Arduino sketch; I intend to rewrite it as a library and release it to the public. This is also likely to be several months off.

This work is also setting the stage for another project of mine, which I am keeping under wraps for the moment. More information as it comes closer to reality.

In the past couple of weeks, I managed to do a little more work on the soda machine hack. With the hardware to interface 110VAC relays to 5VDC logic done, the next step is to create a means of connecting it to the TINI390 board. This has turned out to be a little more complex than I’d anticipated, specifically because I don’t have direct access to the various I/O pins (at least not through its Java VM). The TINI is set up more like a microprocessor than a microcontroller; all the I/O is done by reading from and writing to specific memory locations, divided into several pages. The board has only eight general-purpose I/O pins, but it has a twenty-bit address bus and five usable “Chip Enable” pins. All communication with the on-board peripherals (such as the flash memory and probably the Ethernet) is carried over the same data pins, so anything I attach needs some capability to decode addresses in order to avoid reading or stomping on unrelated stuff.

Since there’s only a limited amount of stuff I need to connect to the TINI, I went with a moderately simple solution: I ignore the actual address pins and pay attention only to the Chip Enables. For example, accessing any memory location in the range 0×800000 to 0×8FFFFFF activates Peripheral Chip Enable 0 (PCE0); since I only need eight bits, I can write anywhere in that range and watch only the enable pin, ignoring the address completely. While this effectively wastes 16,777,207 possible bits, it greatly reducing the complexity of the electronics.

With everything needing to access the same set of pins, however, the board layout started to get a bit hairy. I’m planning to build the system as a set of stacking modules, each with a specific function. This way, I can build the thing piecemeal and add features as I go. The first module is for reading the soda selection. It is fairly simple: when a soda is selected, one of the seven input pins goes ‘high’ for about a quarter of a second. An eight-input OR gate triggers the clock of a flip-flop which grabs and keeps the input. The TINI can then read the selection at its leisure. The DRST (external device reset) pin also triggers the flip-flop’s clock; with no input from the selection detector, this effectively clears the flip-flop. A standard two-input OR is all that’s needed to handle the address decoding.

The soda selection encoder has been built on a breadboard and undergone some testing on the benchtop; it seems to work perfectly. In attempting to test it with the actual selection detector connected to the soda machine, however, I experienced a minor disaster. Apparently, I attached the interface board’s AC neutral to the soda machine’s AC ‘hot’ — I’m attaching this to the lighting circuit, the wires of which are all the same color. When I pressed a soda button, all of the inputs were powered simultaneously, drawing much more current than expected. All of the board’s indicator LEDs lit at the same time with alarming brightness, followed by an alarming darkness. One of the LEDs was actually slightly blackened after the experience; it is just luck that it didn’t actually explode. I suppose either the external LED or the diode inside the optocoupler blew first, then the reverse current killed the surviving diode. Luckily, after some tests, it looks like only that LED/optocoupler pair was destroyed. It should be moderately easy to replace.

After some modifications to the design and some tweaking to the print settings, pan/tilt rig version 2.0 is a success. At a marginally lower extrusion rate and temperature, the accuracy was greatly improved — this version was much less “lumpy.” This improvement turned out to be somewhat of a mixed blessing, however. The first draft ended up being slightly too small to fit the servos, so this version was scaled up by 10% prior to printing. Combined with the improved precision engendered by the print setting tweaks, the final result ended up being a bit too loose to grip the servos with friction alone. A small rubber band around each holder keeps the motor nicely in place, however.


Here are the virtual and material versions of the servo holders for comparison. All in all, a good likeness.

I made my first tentative steps into the world of desktop manufacturing last night. Having a couple of small servo motors, I thought it would be cool to make a tiny pan/tilt rig with them. I also thought this would be a good first 3D printing project. A couple months ago, several of us at W&B got together and built a Makerbot*, a small hobbyist’s 3D printer based on the RepRap project. Like RepRap, the Makerbot fabricates objects out of extruded ABS plastic, the same stuff of which LEGO blocks are made.

The Makerbot fabricates things by laying down a thin bead of molten plastic onto a small platform. The platform moves in two dimensions beneath the extruder, creating a cross-section of the model being built. After one cross-section is complete, the extruder rises and the next cross-section begins. It is a little like creating something from cake icing — I wonder if that’s the origin of the Cupcake name.

The end results aren’t always very pretty; the machine’s accuracy is somewhat limited (there’s only so much control one can have over semi-liquid plastic) and fabbed objects have a somewhat fibrous texture. The open air construction also makes it difficult to create objects with closed vertical openings or overhangs, but it can be done reasonably well by building chamfers or arches to support the overhanging parts.

My own first try was only marginally successful. I designed holders for the vertical (top) and horizontal (base) servo motors in SketchUp, a nice program for sketching out geometric/architectural shapes in 3D. SketchUp has been around a while, but Google bought it a while back and released a free edition. From SketchUp, the model was exported as STL (stereolithograph) files and then converted to GCode (the standard language for driving CNC devices) via Skeinforge. This was then fed to the machine. In about twenty minutes, I had a pair of slightly lumpy plastic objects.

On the one hand, I actually turned a set of data into a physical object, which is pretty incredible when you think of it. On the other hand, the servos don’t fit the holders, so this first draft is useless. I think I made the model too precise, not properly accounting for either the eccentricities of the gooey plastic thread or the slight shrinkage of the object as it cooled. Some cleanup is to be expected — some trimming with a razor blade here, a bit of sanding/filing there — but as tight as these models are, it would be nearly as much work to carve new ones by hand from scratch.

I’m headed back to W&B this afternoon to build some more workbenches for the new members, so I think I’ll set the machine printing version 2.0 while I work. Hopefully, with these lessons learned, the next ones will turn out better.

(* Technically, the machine is called Cupcake CNC and the company that makes it is Makerbot, but the two names appear to be used interchangeably, like ‘Apple’ and ‘Mac.’)

This is the idea: modify the pre-compiler (or, more specifically, the IDE code that calls the precompiler) to automatically include a #define statement, defining MY_UNIQUE_ID as the last sixteen bits of the build time in milliseconds. The chances of two Arduino builds being done in the same thousandth of a second are extraordinarily low, effectively making the ID unique for all practical reasons. In the code, all the programmer needs to do is use MY_UNIQUE_ID as a variable.

I’ll have to take a look at the Arduino IDE source.

Update (9/24): A couple of people have commented on this on Facebook (where this appears via RSS), suggesting some dynamic, real-time solutions. These are good ideas, but the situation I was imagining isn’t one in which all the points would have access to each other simultaneously; instead, temporary connections are being made between units, probably by physical contact.

The W&B soda machine continues its march towards the Internet. Yesterday, Sam Gerstein (another W&B member) and I spent a couple of hours investigating its treacherous inner workings, figuring out specifically where the credit-emulating relay needs to go and testing the selection detection board.

Despite a couple of brief setbacks, the afternoon was a success. Virtually everything in the machine worked more-or-less as predicted. The CONTROL BOX did contain a couple of mysteries: a switch fixed in one position in by a steel plate and a couple of screws, a relay not connected to anything whatsoever, and color-coded wires that didn’t seem to match the schematic. Apart from those, however, it was fairly spacious and tidy inside. The machine had apparently been modified modified so that every item is the same price, so only one of the four circuits that denote credit is actually in use, and shorting this with the ‘hot’ connection registered as money having been deposited. The relay board will be easy to integrate.

The selection detection board also went through its first full test. Nervous that it might explode or catch fire, I asked Sam to plug it into the wall. My fears were unfounded, however: no explosion, no fire, and not even a wisp of smoke. One of the seven optocoupler circuits didn’t work correctly, however; it almost seemed to be working in reverse, outputting a ‘high’ signal when AC power wasn’t applied and a slightly lower voltage when it was. Eventually, Sam noticed that one optocoupler’s transistor’s base and collector were shorted; I never spotted it, probably because the transistor’s base isn’t used in the circuit.

Now, I need to reinstall my TINI/1-Wire development environment and start trying to get the software side started.


Back to Stokes’ Project Blog

Since I’m trying to update my project blog to reflect what I’m actually doing, I thought it worth mentioning the workbenches (and now shelves) I’ve been building for Willoughby & Baltic, previously posted only to Facebook.

I’ve built three nearly identical benches and one large table of similar construction using primarily scrap and recycled wood 2×4s from some demolished partitions. They were designed so that there are few pieces that meet end-on, reducing the required accuracy of the lengths of their pieces and allowing for a lot of tweaking room; since some of the 2×4s are a bit warped and the floor isn’t 100% level, anyway, a decent ‘fudge factor’ was needed. Three of the benches use doors (also once part of the demolished partitions) for work surfaces; the table uses two pieces of heavy, linoleum-covered countertop-type material from some other source.

The shelves are fairly similar in design, if only because they, too, are made primarily of 2×4s. These were built to slightly different proportions: 6′x6′x2′. Having used most of the small scrap in the benches, the shelves were designed to get the most out of whole 2×4 beams, which are typically 8′ long. Plywood paneling (again from the former partitions) serves as shelf surfaces. The paneling is just standard structural plywood with some ‘decorative’ grooves cut into it so it is actually quite sturdy.

Willoughby & Baltic has acquired a vintage soda machine; if I were to guess, it dates back to the late 1950s or early 1960s. It’s a massive steel box with a wood veneer front, its sides an industrial non-color. In contrast to more modern machines, its only text is the words Cold Drink in small, white-on-black, sans-serif lettering above a narrow, horizontal window displaying a representative can of each beverage within. I should have thought to photograph it, but I was distracted by the interior. Inside, the machine is a wonder of space-age technology: as you can see from the schematic, everything operates on 110V AC line current, and its works are almost entirely electromechanical relays and solenoids. Frankly, it’s pretty cool.

Of course, the first thing that needs to be done to the machine is connect it to the Internet. Why? I don’t know. I’m only interested in the ‘how’ at the moment.

The first step of that first step is building microcontroller-compatible interfaces for the machine’s 110VAC inner workings. Since most microcontrollers operate on DC between 3 and 5 volts, this will take some doing.

There are two basic functions that need to be exposed; the first is detecting the beverage selection. For this, I’ve built a board (here’s the schematic) that uses optocouplers to pass the signal but keep the two voltages electrically isolated. It’s really pretty simple. Every button is a SPDT switch, wired so that the first button pressed cuts the power to all the rest; only one button can be active at a time. The output from each of the seven buttons is split; one side goes where it was intended, the other to the board’s inputs. When a button is pressed, one of the seven low-voltage outputs on the other side of the board goes ‘high’ (i.e. changing from ground to just below +5VDC). The signal will come through as a rapid series of pulses (half of the AC sine wave), but I’ll account for this in the software.

The other thing that a computer-enabled soda machine must be able to do is operate cashlessly. We use uniquely-identifiable iButton keys for other purposes at W&B, so I plan on using those to allow members to put a drink on their tab. Looking at the machine’s schematic, it appears that the coin box abstracts the credits put into it; it just closes one of four circuits when ‘enough’ money has been put in. The four separate circuits apparently allow for four separate prices, although the W&B machine has everything cost the same. The board I put together for this (schematic) is a fairly generic relay controller. When powered, the relay switches the credit circuit’s source away from the coin box. This circuit uses an optocoupler in a way opposite of the first board; it sends a signal from the low-voltage portion. There’s actually an extra step in this: the relay is what connects to the machine’s native 110VAC, and it operates on 12VDC. The optocoupler controls that 12V signal which in turn controls the 110VAC.

The selection detection board is fairly straight forward to hook up; all the buttons are connected with standard ’spade’ connectors, all of which are accessible when the machine is open, so putting in a splitter is just a matter of plugging it in. The credit faker’s attachment is not so obvious. The coin box is a separate module, connected via a strange plug that looks like four standard grounded plugs stacked vertically. I’m going to have to open up what the schematic refers to as the control box, which is literally an ominously featureless steel box located next to the coin module. While I’ve tried to plan all my modifications to avoid making permanent changes to the machine, this will almost certainly need some ‘higher impact’ hacking.

If I don’t get a job in the meantime, I hope to do some additional work next week. I should really take some photos of the machine itself as well.

Stokes’ Project Blog

I’ve long been interested in UI and usability; I took some courses back in school and I’ve pursued it on my own since then. A couple of months back, I performed a thought experiment: what would be the worst (plausible) user interface hardware? It occurred to me that bad interfaces keep the user from performing an activity, but what if the interface itself was the activity? In such a case, the regular rules no longer apply.

From that came my idea for a modular, expandable control panel composed of banks of toggle switches.

The prototypes I built consist of sets of eight vintage toggle switches equally spaced on brushed aluminum panels. The panels have a nice bevel on one side and are open on the other; the back has mounting holes and a set of leaf springs for maintaining tension but is otherwise open as well. Placed open-end-to-open-end or top-to-bottom, the switches are distributed evenly across the resulting surface.

The end result has a nice, Altair/PDP-8 feel to it.

The system is really just a bunch of switches connected to 74LS166 parallel-to-serial shift registers. The one vaguely clever electronic feature is that each panel’s orientation changes both the order in which the switches are scanned and which direction is ‘on.’ This is accomplished by a header wired to reverse all of the switches and swap power and ground when plugged in upside down. This way, the control panel can be reconfigured without the need to adjust the software that reads it — it only needs to be told the number of panels attached. Even this could be made automatic in a future version.


I had additional plans for including other vintage-style controls (e.g. knobs, thumbwheels, et cetera), but this project has sort of stagnated. If I return to the project, I may implement this.

Then I just have to think of something to control with the panel.

An alternative: border the sides and/or bottom of the screen with a translucent white gradient, representing the wearer’s breath condensing on the glass surface inside of the mask. Wearing a gas mask/space suit in a video game is usually accompanied by the requisite 2001-style breathing sounds; the gradient could contract with each breath and slowly dilate afterward. For added realism, the rate at which the fog clears could remain constant while the rate of breathing (and thus fogging) is based on the character’s exertion, so panicked running around could leave the player momentarily blind. That would work well in a game of the “survival/horror” genre.