Archive for October, 2008

Petty Joule Thief

You might be familiar with the original Joule Thief, a simple, homebrewable step-up converter often used to drive LEDs (with Vf of several volts) from a single 1.5V battery, or extract the last remaining juice from a battery that’s too dead for use in most real-world gadgets. The basic Joule Thief can suck power from low voltage sources where reasonable current is still available, but what if you want to go even lower? What if you want to suck juice from your neighbor’s WiFi signal originating just on the other side of the wall? RFID or other sensitive inductive-powering mutual-inductance shenanigans? Harvest power from a Peltier device across a relatively small thermal gradient? Solar-power a gadget on even the cloudiest of days? How about scavenging useful power from those annoying radio broadcasters who can find nothing better to talk about than celebrity gossip and which sports mogul was caught with steroids this week?

Recently I discovered a copycat energy-harvesting company trying to claim trademarks on the term “Joule Thief”, which, having been a staple of DIY electronics for about the last decade, cannot stand. So here’s a variation on the classic which a) timestamps the first use of another clever circuit name, and b) genericides the crap out of the bogus mark. So, without further crap, here is the Petty Joule Thief(r)(tm)(c)(processed cheese food):

This one, based on a monolithic IC designed for bootstrapping bigger step-up converters (Seiko S-882Z series), will start-up on voltage sources as little as 300mV, and continue boosting at even lower voltages, stepping it up to 2.4V – enough to drive most LEDs and a good many low-power microcontrollers these days. The circuit is not exactly innovative either (the off-the-shelf chip and a couple caps; basically right from the datasheet), but hey, 300mV guaranteed start! Unfortunately, actually laying hands on these chips is nontrivial for the average hobbyist; they’re not available on Digikey, or indeed any direct-sales establishment in quantities less than 300 units. You might get lucky if you call up your nearest Seiko sales rep and beg really, really nicely for samples (an office at an engineering company and a big mahogany conference table might help). So really this is more of an excuse to get the funny name out there while we wait for these guys to grow a clue and sell on Digikey, or someone like Sparkfun to buy a reel and start selling them by the each.

Unlike the real Joule Thief circuit, this chip implements a switched-capacitor charge pump scheme rather than an inductive one. Both require converting a DC source to AC using a low-power oscillator, but the similarity ends there. Imagine wiring a 1.5V AA battery to a breadboard and placing a capacitor across it, which of course then charges up to 1.5V. Now yank the charged capacitor out and plug it back in so that the pin that was on the battery’s “-” terminal is now on the “+” terminal, and the one that was on the + terminal is now tied to your load. The 1.5 of the battery is now in series with the 1.5V on the cap, so there is now 3V at the load.

The capacitor on the input (10uF or so should be plenty) is for power supply bypass; this may be helpful where the input source is low-current as well as low voltage. For simple constant loads like an LED, the output capacitor should be maybe just a few uF or could possibly be omitted entirely (I haven’t tested this). For “bursty” loads (e.g. intermittently-running sensor / microcontroller), the output capacitor should be sized large enough so that the load can get its business done before the voltage drops below a usable level. You could do some math, but experimentation is more fun. The chip’s output will automatically switch ON when the large output cap is full (2.4V), and OFF again when the voltage drops to about 1.8V.

The efficiency of boosting power from 0.3V to 2+V is not great, but it does allow you to use many extremely low-voltage sources (maybe at low duty-cycles, like a once-per-hour wireless sensor/transmitter) that otherwise wouldn’t be usable at all. Consider the possibilities…

Crap to non-crap generator. Patent pending! (yeah right) And no, this is not a very efficient way to harvest radio waves, but it shows the concept.


Last night I finished throwing together a workable version of the Weatherball, currently displaying a color code at the end of my flagpole to indicate whether tomorrow holds any interesting weather. Apparently cities and radio stations have been doing it since the 1950s, but now I have my own! The data is grabbed from the NOAA’s National Digital Forecast Database server (XML) using a quick C++ program, and currently acts on five variables: chance of precipitation, chance of hail, chance of tornado, chance of extreme wind, and cloud cover percentage. Any ‘interesting’ values in these fields are evaluated in order of decreasing importance (beginning with hail/tornadoes), and the most significant weather condition is sent to the das Blinkenlichten node in the ball at the end of the flagpole.

In the spirit of virtually all known Weatherballs to date, here is a not-very-catchy jingle expressing the color code:

If the weather ball is yellow/green, the sun’s expected to be seen
If the weather ball is gray, anticipate a cloudy day
If the weather ball is blue, it probably will sprinkle too
If the weather ball’s maroon, be prepared for a typhoon
And if the weather ball is red, forget the beach – head for the basement instead!

(And if the weather ball draws half an amp, the electronics have gotten damp – the Blinkenlicht inside the ball has been outside for nearly a year (just waiting for me to get around to writing the software) and seems to still work fine, but I really should weatherproof that sucker.)

Weatherball showing no interesting weather for tomorrow (yellow-green). Know what it needs now? More Power!

Here are the main parts – the ball is supposed to be a curtain rod capper.

The program to fetch weather reports from the interwebs and drive the ball

The DON’T PANIC flag* (Hitchhikers Guide reference; the house number is 42) is showing a bit of weathering, but is still intact. The flag pole is a piece of lightweight enameled metal rod from the big-box hardware store, intended for hanging stuff in closets. The bubbly clear ball on the end is a decorative curtain-rod endcap from Ikea. A set screw on the side allows it to be attached to rods of various diameters. The exposed clear plastic extends through the inner diameter of the endcap some on the inside, allowing the LED node placed in the base to light up the ball (though not brightly enough for my tastes; may beef it up a bit later). The material can also be drilled out to embed the LED further into the ball, if desired.

* If McCain gets elected, it will be replaced by a bright red PANIC! flag, and the weatherball recoded to display the current terrist alert level. It will operate briefly in this manner while I search for a homebuyer and a cheap one-way ticket to Canada…

Hiking in the Middlesex Fells

Some pictures from our hiking trip a couple weeks ago (Krista, myself, Jane, and Matt). Holy crap, is it fall already? How did that happen?

Some stuff on Paypal

I’ve been using Paypal as the payment-handling service for my trance vibe project, and overall it’s not too bad. I can even print my own postage for domestic shipments, sticky on a label and not have to drive to the post office to send out an order anymore. But there are a few things about it that are really broken.


Assembler Interpreter for microcontrollers – sane?

I’m thinking of how much work it would be to write an assembler interpreter in PIC assembler. Probably sounds like the dumbest idea in the world, right ;-)

I’ve been toying with this idea lately for sort of futureproofing microcontroller-based designs, and adding some new possibilities for specific applications (polymorphic / self-modifying code, security applications, Arduino shields with their own drivers built in, etc.). Basically, the ability to load executable code from some arbitrary source and run it from RAM, the way we’re used to with general-purpose computers. The key problem in this idea of course is that typical microcontrollers can only execute code from their internal Flash memory, not RAM. There are few hacks out there that straddle the line between bootloading and execution, e.g. load code from (arbitrary source) and write it to an unused block of Flash, then execute it, then load some more code over it, etc., but this could wear out Flash memory pretty quickly. The only way to execute something directly from RAM is if it’s an interpreted language. Rolling my own interpretive language and its interpreter in ASM doesn’t sound like much fun, let alone getting anyone else to adopt it. It seems like the “least-work” approach would be for the interpreter to take its input in the form of MCU opcodes directly, looking them up in a jump table and executing the corresponding instruction from Flash ROM. That avoids having to write your own language and some complicated parser for it, and documentation for the language, and debugging tools, and…

This simplistic explanation works for basic operations (register reads and writes; you could use this to bitbang some new piece of hardware on the GPIO pins that didn’t exist when you released your gadget), but breaks down a bit when dealing with handling calls/gotos and code addresses, and where to safely stash all the interpreted code’s variables. I think I need to put a bit more baking into this idea for that reason, but it seems mildly promising so far.

(And no, I’m evidently not the first person to have this idea. When searching to see if someone had already done it, no working implementations, but Michael Millikan mentions a similar idea on PICList (see Mar 3 2004 entry).