The Ardent Mobile Cloud Platform

This year I had the pleasure of working on a big art project for Burning Man with a wonderfully talented group of artists and engineers in my community. It started with a simple idea: Let’s bring a variable reach forklift to Burning Man, and put a cloud on it. The project’s tongue-in-cheek Kickstarter video illustrates the concept we were going for:

(View on YouTube)

In only about two months, we worked hard and this vision took shape. The skin of the cloud was made from thousands of squares of HDPE plastic zip-tied together. I love projects that import a simple and rigid digital aesthetic into the imprecise real world, where the constraints of manufacturing and assembly leave their own unique marks on the result. This was especially true at Burning Man, where we assembled our art in the desert heat, contorting our bodies to reach inaccessible internal bolts, soldering upside-down, and dealing with unexpected equipment failures.

9594693517_b926288656_o(Photo: Making final adjustments on the Ardent Mobile Cloud Platform, by Aaron Muszalski)

I’m used to projects that involve some level of technical complexity that leaves me feeling like I just accomplished something challenging. This feeling eventually subsides, and leaves me wondering why it was I that actually built the thing at all. This project did still involve some technical challenge, but it was about so much more than that. Art projects like this bring my community together, and we all enjoy using the art to create weird and delightful experiences for those around us. For me the peak of this experience was Tuesday night False Profit party, riding the cloud 40 feet in the air with my friends and collaborators, taking in the spectacle of Burning Man around us, people far below us dancing around an art project I helped create.

The Ardent Mobile Cloud Platform rains on the DPW Parade, Burnin(Photo: The Ardent Mobile Cloud Platform rains on the DPW Parade, by Neil Girling)

As is the tradition of Ardent Heavy Industries, we took a dumb idea way too far. This wasn’t just a static sculpture, it sported an interactive control panel via WiFi and an iPad running TouchOSC. This cloud was equipped with a water pump and pressure vessel, two computer controlled valves, a sound system, and 2368 individually addressable RGB LEDs.

2013-08-16 18.29.35 2013-08-16 18.29.48

I was in charge of the electronics and software for the project, and I designed the volumetric lighting. The effect is a little like mapping a 3D light texture onto the outside of our cloud. I built modules with addressable WS2812 LED strips aimed outward at the translucent cloud skin. These were controlled by a Raspberry Pi and five of my own Fadecandy LED controller boards. The Fadecandy boards used high-speed temporal dithering and gamma correction to very smoothly interpolate between keyframes generated by the Raspberry Pi. The Pi’s software has a rough idea of where each LED is in 3D space, and it uses that location to sample from a 4D fractional Brownian motion function.

The result was really beautiful at night:


(Video: J Gingold)

Working on AMCP has been a great experience, and I’m looking forward to doing more projects that create weird experiences and bring people together.

How we built a Super Nintendo out of a wireless keyboard

I wrote a guest article for Adafruit about the story behind the new Sifteo cubes:

In today’s world, video game consoles have become increasingly complex virtual worlds unto themselves. Shiny, high polygon count, immersive, but ultimately indirect. A video game controller is your gateway to the game’s world—but the gateway itself can be a constant reminder that you’re outside that world, looking in.

Likewise, the technology in these game consoles has become increasingly opaque. Decades ago, platforms like the Commodore 64 encouraged tinkerers and do-it-yourselfers of all kinds. You could buy commercial games, sure, but the manual that shipped with the C-64 also told you what you needed to know to make your own games, tools, or even robots. The manual included a full schematic, the components were in large through-hole packages, and most of them were commonly-available chips with published data sheets.

Fast forward three decades. Today’s video game consoles are as powerful and as complex as a personal computer, with elaborate security systems designed specifically to keep do-it-yourselfers out. They contain dozens of customized or special-purpose parts, and it takes some serious wizardry to do anything with them other than exactly what the manufacturer intended. These systems are discouragingly complicated. It’s so hard to see any common link between the circuits you can build at home, and the complex electrical engineering that goes into an Xbox 360 or Playstation 3.

We wanted to build something different. Our platform has no controller, no television. The system itself is the game world. To make this happen, we had to take our engineering back to basics too. This is a game platform built using parts that aren’t fundamentally different from the Arduino or Maple boards that tens of thousands of makers are using right now.

This is the story of how we built the hardware behind the new Sifteo Cubes, our second generation of a gaming platform that’s all about tactile sensation and real, physical objects.

Read the full article at Adafruit.

X-10 SmartRemote

I’m not even sure why I built this at all. I guess I did always have a childhood fascination with making things that seemed professional in some way. A simulacrum of some expensive piece of A/V equipment, or simple computer games that came in a shoe box with construction-paper cover art.

This is another ancient project I dug up during my recent move to San Francisco: A rather gigantic “smart” remote control for X-10 home automation devices.

I’m only posting this because it seems cute in some ways… like finding one of your childhood finger-paintings. But it was really an awful project in pretty much every way. It was over-engineered, terrible at the job it was designed to do, and of course the battery life was pretty bad.

The extremely clunky user interface is based on a numeric keypad recycled from a very old television set, and a 16×2 alphanumeric LCD. The X-10 codes are transmitted via a reverse-engineered “Firecracker” board. A Basic Stamp 2 controls it all. This is one of my earlier microcontroller projects, from way back in 1999.

[flickr id=”5921077038″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5920516143″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921079728″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921081670″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921082132″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921083104″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921082814″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

Neon Scope

It’s so hard for me to clean up my office. I’ll see a random collection of objects that I’m supposed to be sorting, putting away, and/or throwing in the garbage.. and I can’t help playing with them instead.

This time the objects in question were an old CCFL backlight inverter, a neon flicker-flame bulb, and a linear table from a discarded flatbed scanner.

These flicker-flame bulbs have two metal plates in them. Normally, the 60 Hz AC power charges the neon gas between the two plates. The current isn’t high enough to uniformly light the neon along the entire plates, so you end up with an unstable flickering region caused by the gas non-uniformly ionizing along the surface of the plates. As the 60 Hz power cycles on and off, there are frequent opportunities for the ionization to break down, and for the lamp to re-light with a different pattern of glow discharge.

To make this more interesting, I wrapped a very thin (AWG 32) wire around the bulb as a ground. Now instead of just discharging between the plates, we can observe discharge between the plates and the glass envelope of the bulb. Much more interesting— it looks more like a plasma globe now:

[flickr id=”5698828474″ thumbnail=”medium_640″ overlay=”true” size=”large” group=”” align=”center”]

Since the CCFL inverter generates a much higher frequency variety of AC power, the bulb actually doesn’t normally flicker when driven this way. To get the interesting flickering back, but in a more controlled fashion, I hooked the input of the inverter up to a benchtop function generator. And finally, to “plot” the flickering, I used a long exposure and the linear motion from the old flatbed scanner table:

[flickr id=”5698255349″ thumbnail=”medium_640″ overlay=”true” size=”large” group=”” align=”none”]

With a pause in the middle, to show the bulb itself:

[flickr id=”5698255781″ thumbnail=”medium_640″ overlay=”true” size=”large” group=”” align=”none”]

Cube64 GameCube to N64 Adaptor

Enjoy retro N64 games, but can’t stand the controller? That’s the situation I found myself in about 7 years ago, back in 2004. So I built an adaptor, to use Game Cube controllers on the N64.

The adaptor hardware is very simple- all you need is a PIC microcontroller. I originally designed the project to work with the very popular at the time PIC16F84A, or some smaller 8-pin chips. It bit-bangs both protocols, so you don’t need any more hardware than a tiny µC, a couple resistors, and optionally either a voltage booster or battery pack to run the “rumble” vibration motor.

I had a lot of fun building it, since it was an opportunity to reverse engineer a protocol that, as far as I could tell, had never been documented publicly. There were many web sites explaining the basics of the N64 and Game Cube protocols- enough to talk to the controllers with your own hardware. But there was significantly more to learn about emulating an N64 controller, since there are many features that you don’t really need to use the controller, but which games will use. The N64 also has the added complexity of having a memory card slot. The controller implements a protocol that tunnels SRAM reads/writes over the controller wire. Peripherals like the Rumble Pak pretend to be SRAM, but are actually memory-mapped I/O devices.

This is a very old project, but I thought I’d do a quick post with an update on it. I never really released the project, I just quietly posted the source code and the CIA feed. Since then, many others have found the project and built their own.

I recently heard from Jacques Gagnon, who went a step farther. He was frustrated by a few lingering bugs, most notably lack of support for the WaveBird wireless controllers. So he pulled the project into Google Code and has been hacking away! WaveBird controllers work now, and he’s added several other new features, such as the ability to store multiple sets of button mapping layouts in memory.

If you’re still interested in this classic gaming platform and you’d love to have your own Cube64 adaptor, I highly encourage you to check out Jacques’ work. The adaptors are easy to build, especially if you already have some experience with microcontroller programming.

Getting to know the Thing-O-Matic

This post is mostly an apology for not having done anything blog-worthy in the past few months. As usual, life has been full of Things. Like Katamari Damacy. Kinda.

On the technical side, I’ve had a few interesting ideas bouncing around in my head lately:

  • 3D Printing. Seems like a space ripe for DIY innovation, and besides, it’s really cool.
  • Other sorts of odd CNC machines. Like a computer controlled sort-and-place for fabricating Perler Bead designs automatically.
  • Electronic Jewlery, assembled at microscope-scale. Ropes of twisted 40 AWG wire with LEDs soldered along them in a Charlieplexed matrix. That sort of thing. And perhaps I can make something half as pretty as Zelle‘s stuff.
  • You know, something actually important. Like solving world hunger, or making computers more efficient or more secure, or solving Big Problems in human rights. But who has time for that, let’s play with microcontrollers.

Starting at step #1 then, I recently got the Makerbot Thing-O-Matic kit that I preordered. It’s pretty cool- a relatively cheap way to get into 3D printing, and every single part is open source and hackable.

Makerbot with thing-collection system

Starting a build (closeup)

Companion Cube

This is my first 3D printer, so I’m not really qualified to write a review of it just yet. But I can briefly list the things I like and don’t like about the kit.

Things that rock:

  • It’s relatively easy to put together. I got my kit on a Friday afternoon and had time to get it printing by (late) Sunday night while also taking a day off to socialize.
  • With default settings and pretty much no futzing with the belts or Skeinforge, the print quality is pretty fair. And with only a bit of tweaking, you can do decent prints at a 0.4mm layer height.
  • From what I can see, the mechanical parts are fairly good. Feed rates seem relatively fast for a low-cost CNC machine, and while the machine as a whole tends to wobble and vibrate a lot, the machine is quite rigid where it counts.
  • The MK5 extruder has a very solid mechanical design, and it grips the plastic filament quite heartily.
  • The conveyor belt is cool, and it was fun printing several parts back-to-back without manual intervention.

Things that annoy me:

  • The motor on the MK5 extruder. This motor bugs me. A lot.
    • For starters, mine had a common problem in which the motor stalls randomly, overheats the H-bridge, and generally makes a mess of the whole system. I traced this back to a particular mechanical state in which the motor needs upwards of 2 Amps to un-stall, when it normally runs at less than 50 mA. Ow. This is more current than the H-bridge can handle, so it just gets hot and the motor goes nowhere. Right now I’m working around the bug by using a relay to drive the motor, but that’s a dreadful hack.
    • Even when the motor works, the extrusion rate is unpredictable and uncontrollable. The extruder controller’s PWM is worse than useless (The docs warn of it damaging the motor?) and even at a constant voltage, the actual extrusion rate changes based on lots of factors- age of the motor, tension on the filament drive gear, phase of moon. So the thickness of the extruded plastic is, in turn, quite variable.
  • The conveyor belt easily warps and twists. It’s really convenient, but for larger or high-res prints it just isn’t rigid enough. I think I could fix this by building a tensioner for the belt, but for the moment I’ve just taken my belt off. Right now I’d rather print one thing accurately than print 100 copies of something inaccurately 🙂
  • The electronics and firmware seem a bit.. I hesitate to say this, but, amateurish? I can’t help but think that there’s a better processor for the job than an AVR, and I think the Arduino layers are getting in the way more than they’re helping. The modular design also seems like needless complexity. Six PCBs? Really?
  • The software which generates toolpaths, Skeinforge, is actually quite nice and configurable. Now I’m just about the biggest Python fan of anyone I know in person, but I still get very frustrated by how slow this tool is on more complex models. It also seems to frequently do rather bizarre things- like generating toolpaths that could easily be one continuous segment, but are instead several disjoint plastic threads that are placed down in very suboptimal order.

So, naturally I have some plans to rectify these annoyances:

  • I’ve already ordered a Makergear stepper extruder with 0.35mm and 0.25mm nozzles. Can’t wait to try this out!
  • I’m tempted to try my own toolpath generator. I know everyone and their mom are writing Skeinforge replacements these days, but it seems like this could be a fun project to tie in with my interest in computer graphics and graphics-related algorithms.
  • I’m also quite tempted to design my own all-in-one controller board for Makerbots and RepRaps. I’m picky about these sorts of things, so I really want some real-time guarantees in the motor controllers, and I want to never have to worry about the processor reading in g-code slower than the motors can move. So I’ve been thinking about doing something based on an XMOS, Propeller, FPGA, or ARM. And it’d be one PCB, with one processor, and all of the stepper drivers and FETs onboard. Anything else would just be a waste of board space and wire. I also kind of want a faster uplink to the PC, either Ethernet or USB 2.0.

So, we’ll see if these go anywhere… All of the above ideas are just ideas now, and their implementation or lack thereof is subject to my level of boredom!

Espresso Machine Sous-vide

This project is a bit different from what I normally do. No firmware to write, just several trips to the hardware store and a lot of quality time with the drill, files, and nibbler. But this one has a higher purpose: Food.

It was actually a commission by a friend of mine. He wanted to try sous-vide cooking, but neither of us were crazy about the idea of paying for something lab-grade, and even the consumer-focused SousVide Supreme seemed kind of lame with its $450 price tag and no circulation pump.

The interwebs are brimming with do-it-yourself solutions for sous-vide cooking, ranging from the incredibly simple and cheap, through a middle-ground of modified rice cookers and crockpots up to other DIY immersion circulators like this project by Scott at Seattle Food Geek.

The easier solutions (like a modified crock pot) didn’t seem to meet my friend’s requirements. He wants the flexibility to use large water baths sometimes, and he wants it to be stable for long durations. So, a real immersion circulator starts to sound awesome for this. I was really close to building the Seattle Food Geek DIY circulator above, when I noticed one of his ideas for improving the design:

“After burning out my first set of heating coils, I realized that there must be a better method of heating the water. The coils are very effective and heat the water very quickly. However, I’m pretty paranoid about burning them out again, and they’re a pain to replace. I’ve found some commercial immersion heating elements, but they’re about $100, which inflates the budget for this project by quite a bit. I may try using the heating element and pump system from an old espresso machine, the kind that makes steam. Since it already has a self-contained heater and an pump, it might even be cheaper than the heating coils and aquarium pump.”

Well, this is what I ended up doing. I’m not sure it ended up being cheaper (those heating coils he used were really cheap!) but it was definitely fun to build, and the end result is working pretty well:

Top and side panels, in use

DIY circulator in action

Sous-vide Chicken

Sous-vide salmon, carrots, and beets

Rough bill of materials:

  • Kalorik EXP-20737 Aqua Line 1250-Watt 15-Bar-Pump Espresso Maker“, was $59.99 on Amazon
    • Pump
    • Heating element
    • Assorted hoses, fittings, thermostats, and wiring
  • Enclosure: Sheet metal cash box, $10 at Fry’s
    • Cut holes with a power drill and nibbler tool.
  • JLD612 PID Controller, $32.50 from Lightobject
  • PT-100 Temperature Probe, $19 from Lightobject
    • These probes are NOT waterproof, and the wiring between the cable and the sensor can be a bit flaky.
    • I ended up redoing the wiring, and insulating the probe with PVC hose and silicone kitchen/bathroom caulk
  • 25A zero-crossing solid state relay, $13.22 from Digi-key
  • Heavy duty 2 foot 15A power cord, $9.85 from Amazon
  • Fiberglass automotive exhaust wrap, $13.95 from Amazon
  • Local homebrewing supply store:
    • 2x male/female 1/4″ quick-disconnects. (Price: way too much. If you’re on a budget, skip these.)
  • Local hardware store:
    • Reinforced 1/4″ PVC hose, rated for potable water. 10 feet for $10.
    • Non-reinforced 1/4″ PVC hose, for the temperature sensor. 10 feet for $10.
    • Ceiling fan speed control (for adjusting pump power), $10
    • Hose clamps, 6 for about $1 each
    • Silicone kitchen/bathroom caulk
  • Junk drawer:
    • Heavy duty power switch from an old UPS
    • IEC receptacle from a broken power supply
    • Very old Radio Shack panel mount neon indicator light
    • A nicer knob for the pump speed control
    • Heavy-duty wire
    • Lighter gauge wire, for control signals
    • Wire nuts
    • Kapton tape
    • Hot glue
    • Nuts and bolts
    • 1/8″ Audio plug/jack for temperature probe

This turned out to be a really interesting design, because you can use it with nearly any water bath vessel. Even the lab-grade immersion circulators need a place for the circulator to stick out on top, and this often means making a custom lid. I usually use this machine with a small icechest, but I’ve also heated up water in plain soup mugs and mixing bowls. You just run three hoses in (inlet, outlet, and temperature probe) and you’re set. Of course, the more insulation you have, the easier it will be to keep the temperature steady.

On the downside, this design can take a while to heat the water. I think it took maybe 30 minutes to heat about a gallon of room-temperature water up to 140°F. This is certainly not limited by the heating element- the espresso machine heater is 1200 watts. However, I have a mechanical thermostat on it that keeps the heating element from rising too far above 120°C. It’s okay if we make a little bit of steam, but it’d be bad if the steam got too hot. So what ends up happening, is that while you’re initially heating the water, the PID is telling the heating element to run at full power, but the mechanical thermostat is still keeping it from overheating. So when you’re initially heating the water, our limiting factor is the pump’s flow rate. If it’s too slow, the inlet water isn’t coming through fast enough to cool off the heater.

I spent what seems like a week shopping for alternative pumps. I looked through McMaster-Carr, eBay, even tried a CPU water-cooling pump. That one was nicely high flow-rate… until you give it any sort of load, that is. And to be practical, this design really needs a self-priming pump. So, I stuck with the one that came with the espresso machine. It’s not actually that bad. The only tweak I had to make is to limit the pump’s power using a ceiling fan speed controller. Since it’s a solenoid type pump, this only limits the strength with which the solenoid slams from side to side. The actual flow rate is mostly fixed, since the solenoid is oscillating at your mains frequency. The reduced power helps the pump run much quieter and cooler, which is rather necessary when you’re running something continuously that wasn’t meant to.

Since assembling this thing, my boyfriend and I have cooked several meals in it. As long as we’re patient enough to let the PID loop fully settle before cooking anything, it’s remarkably accurate. I can routinely hold the water bath within 0.4 °F or so. Of course, sometimes the PID goes nuts and overshoots/undershoots too. I’m sure I’ll get more feedback on this once I deliver it to my friend 🙂

Hacking a Digital Bathroom Scale

People all around the internet have been doing cool things with the Wii peripherals lately, including the Wii Fit balance board. Things like controlling robots or playing World of Warcraft.

But what if you just want one weight sensor, not four? The balance board starts to look kind of pricey, and who wants to deal with Bluetooth if you don’t have to?

I’ve had a couple ideas for problems that could be solved by a cheap interface to the weight sensor in a common digital bathroom scale. The kind you can get for $15 or so at the local big-box store. For example, I’ve pondered using a grid of bathroom scales as an input device. You could use it to emulate a DDR pad, and there might be new applications that could benefit from analog weight readouts on each square of the pad.

The other idea is really Scott’s doing. He has a kegerator, and naturally we’ve been plotting to fill it full of all manner of sensors, actuators, and RFID readers. We’d like to have a continuous measurement of the keg’s weight, both to have some advance warning that it’s getting low, and to detect when an individual glass of beer has been dispensed. It seemed like if we could use the sensor from a digital bathroom scale, the filtered output would probably be accurate enough to detect the difference in weight from just one beer.

I’ve seen other projects to hack a digital scale. For example, this SD Card Bathroom Scale project uses a microcontroller to ‘read’ the LCD by decoding the signals used to drive it. This was a great idea, and he pulled it off quite well. But it requires a lot of wiring, and you’re still limited to the resolution and functionality of the original scale. I wanted to see if there was a simpler and lower-level way to hack a typical bathroom scale. And, for my particular scale at least, there is.

How a digital scale works

Old-skool analog scales (you know, with the needle that moved) were based on some clever gears and levers that converted pressure on the scale into compression of a big spring, then the spring’s compression into rotational motion that could drive a dial. But digital scales don’t really have any moving parts. They are mechanically designed to distribute your weight evenly to a bar or collection of bars which bend very very slightly under the pressure. Those bars are bonded to an electrical element that also flexes very very slightly, changing its electrical resistance. This is a strain gauge.

Inside the scale I hacked, you can see the two load-bearing bars. Each bar has two strain gauge sensors bonded to it. Measuring the difference in strain between the two sensors can tell you how much the bar is flexing.

Inside the modified scale

There are a lot of notable parts here:

  • There are two buttons mounted on the scale’s feet. These are connected in parallel. If either one is pressed, the scale will power on.
  • The vertical bars on the left and right are load cells, the mechanical parts that are designed to bend slightly. Each one has a tiny PCB with two strain gauge sensors. The two sensors share one common wire, so there are three wires going to each load cell.
  • The clip in the bottom-center originally held a lithium coin cell battery.

And on the main PCB:

  • A numeric LCD module, bonded to the PCB.
  • A microcontroller or ASIC of unknown variety. This is the digital chip that runs the scale- it’s a chip-on-board module which is soldered to the back of the main PCB.
  • Analog front-end. This consists of an LMV321 quad op-amp, a few transistors, and a heaping spoonful of passives. This amplifies and conditions the signal from the strain gauge sensors. I’ll talk about this more below.
  • Power switching. The analog front-end is very low-power, but to preserve battery life even more, the microcontroller uses a transistor to turn it off entirely when the scale is sleeping.
  • Hidden features! There’s a “CAL” header. If you short this header, wake up the scale, then un-short it, the scale will go into a factory calibration mode. The LCD displays some kind of raw reading in this mode, and it continuously updates.

Unmodified PCB

This is the only scale I’ve disassembled, so your mileage may vary. If your scale puts everything on a single IC, there may not be a way to hack it without building your own analog front-end. But if you get lucky (older scales may be more likely to use discrete parts) you may see something like this in the scale you disassemble. The separation of functionality into discrete analog and digital circuits makes this model of scale quite fun and easy to hack!

Reverse Engineering

This section will explain the process I used to figure out how this scale works. You might be able to use some of the same procedures on other types of digital scales.

  • Visual inspection: Noticed the op-amp chip, arrangement of the passives, how the strain gauges were connected, power switching.
  • Looked up a data sheet for the op-amp chip. Noted the power and output pins.
  • Used an oscilloscope to probe each of the four op-amp outputs, looking for a signal that seemed plausible for a microcontroller to measure. This would have to be either a fairly high-amplitude DC analog voltage, or some kind of variable-frequency signal.
  • Found this signal. Output D on pin 14 had three different kinds of waveforms: low when the scale is off, high when the scale is on but not actively measuring weight (microcontroller is doing calculations or updating the LCD?). When weighing, this pin is a pulse train whose duty cycle seems proportional to weight.
  • Traced this signal back to a pin on the microcontroller.
  • At this point, it might have been sufficient to interface to the scale by snooping this signal. But the pulse train is not present all of the time, so I’d have to have extra code to ignore the idle periods. And you’d have to simulate button presses to keep the scale awake. So, I wanted to figure out how to keep the scale in measurement mode all the time.
  • First step: Keep the analog front-end powered on. I traced the V+ pin on the op-amp back to a transistor that the microcontroller uses to power on all analog circuitry. I soldered a shorting jumper across this transistor.
  • Now when the microcontroller is off, the op-amp output is high rather than low. This means there must be some other signal that the microcontroller is outputting in order to put the analog frontend into measurement mode, or otherwise generate that pulse train.
  • Probed around the microcontroller with my oscilloscope, looking for interesting signals on the pins nearby where the op-amp signal enters.
  • Found another pulse train which was active only when the scale was in weighing mode. This signal seemed to be at the same frequency as the op-amp output signal. This one is normally low, but has brief high pulses.
  • At this point, I thought I had enough information to guess how the circuit worked. Traced where this signal goes, to verify. It is an output from the microcontroller which heads to a transistor in the analog front-end. I didn’t fully reverse engineer this, but I suspect it’s discharging a capacitor that’s used for integrating the analog weight signal.
  • Made the modifications discribed below, and hooked the analog front-end input and output up to a Propeller microcontroller. Verified my guesses by performing some experiments with the microcontroller.

Analog Front-end

This documents my understanding of how the analog front-end works in this digital scale. I didn’t reverse engineer the circuit itself, so this is really just a “black box” description based on observing how the circuit behaves.

The circuit’s input is a tiny resistance from four strain gauges. They are arranged as two independent load cells, each with two sensors that act as a differential pair. The front-end amplifies these tiny differences in resistance, and sums them into a single analog signal. For example, if the strain gauges were labeled L1, L2, R1, and R2 (two sensors each for left and right load cells), the analog summation would be:

Total = L1 – L2 + R1 – R2

This total is still an analog signal, and it’s fairly noisy. There would be a lot of different ways to convert this to a digital signal: a standard successive-approximation A/D converter, a voltage to frequency converter, an RC oscillator… This scale uses an approach that’s simple, cheap, and pretty accurate for situations where you’d like to dynamically make tradeoffs between sample rate and accuracy. It uses an integrator and comparator.

In this approach, there is a capacitor which can charge or discharge depending on the state of a signal from the microcontroller. I’ve been calling this the “Reset” signal. When Reset is low, the capacitor slowly charges at a rate which depends on the analog Total above. This is an analog integrator. When Reset is high, the capacitor discharges quickly. This voltage across the capacitor is fed to a comparator, where it’s compared to a reference threshold. If it’s larger than this threshold, you get a logic “1” out, if it’s smaller you get a logic “0”.

This starts to look a lot like a closed-loop feedback system. In fact, you can even think of it as an electronic equivalent to the old mechanical balance. Instead of balancing two physical weights on a lever, you’re balancing two electric currents which are trying to charge or discharge the integration capacitor. If the capacitor voltage is too high, you need to drain it a bit. If it’s too low, you need to let if fill up. If you keep the capacitor voltage oscillating right around the comparator threshold, it’s just like you’ve balanced a mechanical scale. Now you know how heavy the object you’re weighing is, because you know how much time you need to spend discharging the capacitor to keep it balanced.

I find this symmetry between the mechanical and electrical scale pretty elegant. It’s also practical- your accuracy is limited by electrical or mechanical noise in the circuit, and by your microcontroller’s timing resolution. But you can always integrate over longer periods of time in order to trade sample rate for accuracy. If you keep the capacitor balanced for a whole second, and add up how much time you spent discharging the capacitor over that second, you’ve just calculated the average weight with much more precision than you’d have if you measured the length of a single discharge pulse.

Modding the Scale

After figuring out the analog front-end, I really just wanted a way to use that by itself without worrying about the built-in microcontroller or LCD. This turned out to be really easy:

  • Remove the lithium battery and holder
  • Solder a jumper wire across the transistor that normally powers off the analog front-end. (This is visible in the photo below, near the red and black power wires.)
  • Cut three traces near the microcontroller: Reset signal out, comparator signal in, and button signal in. This separates the microcontroller from the analog circuitry, and it also prevents the microcontroller from waking up. It will stay turned off.
  • Solder a 5-pin ribbon cable to the board: Ground, Power (+3v), Buttons (optional), Reset out, Comparator in.

The wires on the left are power and ground. It’s hard to see here, but the traces corresponding to the three wires on the right were cut, between the wires and the chip-on-board assembly. From top to bottom, those wires are comparator, button, and reset. And that’s it! With that simple mod, the scale is ready to connect directly to any 3.3v microcontroller with two free I/O pins. I used a Propeller, but an AVR should work great for this too. If you’re using a 5V microcontroller, you’ll still want a 3v or 3.3v power supply for the scale. You may also want to limit the voltage on the reset output signal too, though I suspect this isn’t actually necessary.

Modified PCB

Software

I tested this mod using a PropRPM board and some jumper wires. All of the other stuff on the PropRPM board is unrelated to this project- no external components are necessary to talk to the scale, just two 3.3v I/O pins.

Testing the modified scale

The software is pretty simple. To measure weight, you need to toggle the “Reset” output on and off in order to keep the integration capacitor balanced around a comparator threshold. Pulling Reset high will quickly drain the capacitor, pulling it low lets the capacitor charge at a rate which depends on the total weight on the scale. You can take more accurate measurements by repeating this for more cycles, or take quicker measurements by repeating it for fewer cycles. On the Propeller, I use the system clock to measure the total amount of time that I spend letting the capacitor charge. Here’s a complete program that prints scale measurements to the serial port:

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  PIN_SCALE_OUTPUT = 3    ' Pulse high to discharge
  PIN_SCALE_INPUT = 4     ' Output from integrator

OBJ
  term : "Parallax Serial Terminal"

PUB main
  term.start(115200)
  repeat
    term.Str(String(term#NL))
    term.Dec(measure_raw(500))

PRI measure_raw(period) : raw_weight | timeref
  raw_weight := 0
  repeat period

    ' Reset, and wait for input to go high. This is its idle state.
    OUTA[PIN_SCALE_OUTPUT]~
    DIRA[PIN_SCALE_OUTPUT]~~
    waitpne(0, constant(|< PIN_SCALE_INPUT), INA)

    ' Turn off the 'reset' output. This starts integrating
    ' the pressure. When the analog integrator reaches a threshold,
    ' our input pin goes high. Time this.
    timeref := cnt
    OUTA[PIN_SCALE_OUTPUT]~~
    waitpeq(0, constant(|< PIN_SCALE_INPUT), INA)
    raw_weight += cnt - timeref

And that’s all it takes! I’m looking forward to trying this with a larger grid of scales. A powerful microcontroller like the Propeller should be able to simultaneously sample and filter measurements from several scales. This proof-of-concept looks pretty promising for the kegerator project, too. With an integration time of a second or so, it can easily measure weight accurately enough to count glasses of beer 🙂

P.S.  I’m pretty sure I just spent more time writing this blog entry than I spent on the hack itself. How silly is that?

“Luggable” power pack

Paul and I are leaving on a cross-country train trip next week, for Jen and Shawn’s wedding in Colorado. I’m sure the view will be great, and I’m bringing a handful of books- but Paul and I are geeks and we need our electro-doodads. If only we had a way to run our Nintendo DS and PSP for the ~30 hours that the trip will take…

I sifted through my stockpile of junk, and came up with this:

It’s kind of like a mega-size Minty Boost, or a heftier version of the Kensington power pack. The Minty Boost weighs in at about 6 Watt-hours, depending on the AA cells you use. The Kensington pack is rated at 7 Watt-hours, with a Lithium Ion battery. This brick occupies the middle-ground between the Minty Boost and a car jump-start battery, weighing in at 84 Watt-hours. It should run and charge a Nintendo DS for at least 30 hours.

It’s built almost entirely from junk that I had lying around the house: (Your house may vary.)

  • 12 Volt 7 AH Lead-calcium battery
  • Aluminum box, in my stockpile of project enclosures
  • Receptacle end from a cigarette lighter extension cable
  • DC-DC converter from an old Nokia phone charger (for a phone I no longer use). Swapped a resistor with a trimmer pot for 5V output.
  • USB sockets from a dead 4-port hub
  • Heavy duty wires and quick-disconnect plugs from a dead UPS
  • Odds and ends: Switch, mounting hardware, fuse holder, wire nuts, foam weather-stripping, JB-Weld epoxy, heat shrink tubing, LED, resistors

Parts I had to buy at the local Fry’s:

  • 10 Amp fuse (Pack of five for a few dollars)
  • 12V 1 Amp lead-acid battery charger ($20)
  • Cigarette lighter plug for the charger ($2)

Now here’s hoping that nobody thinks it’s a “hoax device”…

P.S. I’m still working on the Robot Odyssey DS port and in fact there are some interesting bits of UI working now- but I haven’t quite reached another blog-worthy milestone yet.

Mmm, crispy.

I hate power electronics.

This was my first attempt at fixing a broken Cuisinart cordless kettle.

The original symptoms: I notice the kettle occasionally turns itself off. If I turn it back on, it works again for a little while. This kept up for a day or so, then it refused to turn on at all. I open it up, and one pole of the dual-throw relay (really, a combination on/off switch and thermal switch) had melted its plastic supports. The contacts no longer touched, so the kettle got no power.

The first fix: That pole of the relay was shot, but luckily there was another identical mechanism on the other pole. I could replace the broken pole with some other type of safety cutoff device, and it would be good as new. Ideally I’d use a thermal fuse for this purpose. The local Fry’s didn’t have any, so I used two 7 amp pico-fuses in parallel. Not ideal, but better than nothing.

So.. my fuses did their job, and my new wiring was fine. When I measured the resistances during reassembly, everything seemed fine. The first few pots of water after this fix are uneventful. Then I notice the bottom of the kettle (just under where my new wiring was installed) started getting really hot. Like, 300 degrees. This was starting to melt the plastic a bit. I open it up, and my wiring harness is what you see above.

So, what happened? I failed to fix the reason why the relay failed in the first place. I was assuming that the relay just used shoddy plastic, and it overheated because it was so close to the heating element. I assumed it was a design flaw. But, the other (presumably identical) relay pole was totally fine. It turns out that the original failure was a loose crimp in the joint that appears rightmost in the photo. The crimp wasn’t quite tight, so the wire rattled around in there a little. This added about 1 ohm of resistance when it was in just the wrong position. A manufacturing flaw.

This kettle nominally runs at about 12 amps. At 12 A and 120 V, a 1 ohm resistor will dissipate 144 watts. Yow.

So, I just replaced that entire section of the wiring harness with two new fuses and two brand new crimps. First pot of water was a success, and I rewarded myself with some irish coffee. We’ll see how well it holds up. I might find myself ordering some slightly better quality crimps and some actual thermal fuses if this fix also has problems.

(Buy a new kettle? Nevar!)