August 2007 - Near Future Laboratory

The Benefits of Slowness

Jan Chipchase’s recent image provocation on slowness had me thinking about what sorts of things can be slowed down and why one would want to slow them down. He shows an image of an automated espresso maker delivering a deliciously thick and gooey latte. I’ve noticed that the automatic coffee machine here is paced as well — it’s unlike the traditional urn where you turn the spigot and the stuff just pours out. The whole coffee beans pour down through the hamper, grind and the coffee is roasted. It’s not regal in its pace by any means, but there’s a bit of patience required that is about what it takes to get a decent cup of coffee to order.

The pace of digital networked social life is frantic at most times, at least for me. Can I slow down some of those activities in a meaningful way? Is there a middle ground between fast-as-you-can and “turning off.” In other words — can there be a pace for some activities that’s more leisured or reflective? And then does slowness bring some sense of calm, of enjoyment for having time to spend reflecting on a communique from a friend or loved one?

SmartDust — Battlefields and Cornfields

Struck with a heavy irony last night as I was responding to an inquiry about Blogjects, Smart Dust, Smart Technology as might be realized in the year 2030 that Smart Dust has been variously pitched as a something for the battlefield (remotely track enemy troop movements, etc), on the one hand, and the cornfield (measure current environmental conditions, existence of little critters eating crops, etc), on the other. It’s not surprising I suppose, given the intricate web of the military industrial light and magic complex, and the deeply imbricated way in which the socio-technical apparatus has positively soaked through our lives so that you can effortlessly find meaning for things like “Smart Dust” in what you might imagine are entirely different sorts of “fields.”

Gestures and Interface: Things To Do With Your Finger

What are the boundaries of interfaces for our digital lives? Our fingers? How can the gestures we use to interact with our devices extend to create new sorts of interaction rituals and interactive experiences that go beyond the digit interface? From simple switches found in old trucks, to the 19 tactile buttons on the guidance computer that took a few men from the earth to the moon, to the current fascination with a different form of tactile “touch” interface, to finger gestures for sign-language interactions to the early experiments with pre-Wii gesture interface — how we interact is all caught up in the interface between intent and action that is very much wound up in the same desire for connection as Michelangelo’s imagination rendered on the ceiling of the Sistine Chapel.

I’m interested in how this interface can be changed to create a new idiom for connected digital lives that are more playful and less burdensome. How can the core elements of the interface syntax be stretched and reformed into a new style and meaning for computation that reflects upon the fact that were beings who live in space and time and sometimes enjoy the friction of social engagement? Can there be a kind of interaction where time actually counts? Where it is not instantaneous email download style time? What happens when the gesture is consumed by time — so that one gesture “unit” extends over an period of several minutes or even hours? What about space? Can there be a way that digital experiences are not about conquering space and diminishing it to a blink of packet switched gigabyte optical fiber speeds? Sometimes covering ground is a good thing, and doing so at a human pace can be a welcome reminder of our physical selves. Suppose that hike counted for something in a different model of computing? Or passing by a familiar landmark — a street corner or pedestrian overpass — is like the gesture of moving a game piece in a video game?

Break Out Power — MAX761

Mobile devices suffer from a variety of design requirements that have created some pretty interesting challenges. One is power. How do you get small, portable, powerful technologies to run for a reasonable amount of time without weighting them down with car battery-sized power cells? I’ve hit this problem in all kinds of ways. Flavonoid, for example, tries to do quite a lot, and wants to consume a relatively large bit of power while doing so. By slowing the clock down, I’ve managed to reduce the power consumed quite a bit, and today’s microcontrollers will run at pretty low voltages (3.3, 3, 1.8 volts) if you can sacrifice clock speed. But, if you need to do lots of stuff, you have to compromise carefully.

Ideally I’d like to find a middle ground — run at a sort of low voltage, keep some of the speed for the processor, and keep the whole package lightby using small battery cell.

This device here — the Maxim IC MAX761 — is a special pulse-width modulated step-up converter, which means it can take a voltage on one end and generate a higher voltage on the other end. It does so with a pretty decent efficiency (86%), with a low supply current (110uA), and you can get away with a smaller inductor because it runs the PWM at a high frequency (300kHz). Running at high frequency is key — as the duty cycle of the switching increases, the output voltage you’ll see increases, which, in this device, you can then control through a resistor network on the output. Well, it works — it’s possible to get more-or-less whatever voltage you’ll need, with some current restrictions, from this guy. I plan on using it to generate this weird 7 volts I need for a backlight for an even weirder miniature bit addressable LCD display.

This break-out board actually supports three output voltages — one is that which is generated by the MAX761, which is variable, using that ginormous potentiometer (which could just be a fixed resistor.) And then two other voltage lower than the generated output with a set of LDO regulators that would go there on those empty pads on the right (like the LP2985) — perhaps 3 and 5 with the MAX761 generating 7 volts.

But, I’ve been here before. I needed 5 volts and wanted that without having to use something like a 9 volt battery (so uncool, and really not much energy available in the usual alkaline cells), and without putting two 3.7 volt LiPo’s in series or something like that. In fact, I had hoped to use a simple and small coin cell. I came across the NCP1402, a micropower step-up converter that’ll give up to 200mA.

Here’s a project I did to better understand how to work some Jedi with power. The Torture Board. I made this break-out board to find a way to get 5 volts from a 3.5 volt or less battery. It’s mostly an exercise, really, for the time when one of my mobile projects will only work at 5 volts and using a 9 volt cell and a regulator is just bad and bulky and 9 volt cells are so old fashioned looking and boxy and expensive. I found this device, the NCP1402 that does the trick. Of course, I completely fracked up the schematic for testing it. I mean, I really screwed it up. Strangely, I sent off the board with a bad schematic, but the schematic in Eagle is fine — I must’ve fixed it in a haze, I guess, after sending it off. In any case, when the boards came back, I just sort of looked at them and shrugged and figured some day I’d wire it up. That day came, and it was a disaster. I hooked up a 3.7 volt LiPo cell and expected to see 5 volts on the output and be done with it. Instead, I found 12 volts! Yeek!

I reworked this one so much with hot air and an iron? It looked like a creme brulee when I was done.

All kinds of problems. Look at that! The diode (middle) has a trace shorting it the hell out! And that trace between pins 1 and 2 and pin 5!? What’s that doing there? I must’ve been loaded when I sketched this schematic..look at that — Vout (1 & 2) connected to the wrong side of the diode!? C’mon..

Okay..lesson learned? Double, triple check my schematics. Also, that trace under the chip footprint? I couldn’t see that when I tried to repair the board with the components laid out, so I missed that problem. I spent probably two or three sessions of an hour or so each trying to figure out what was going on here. It’s confusing partly because of the one-way conductivity of the diode. With it in place, checking continuity can get confusing at times.

Here I started putting things right by cutting traces.

That trace between 1/2 and the right side of the diode, and the trace between 1/2 and 5 in the footprint of the NCP1402 needs to be cut..

The right schematic.

Finally..5 volts from a little 3.7 volt LiPo cell. I mean, this isn’t rocket science, or it shouldn’t be. I think I just sort of assumed that the boards are “right” even though I made designed them and never tested them. Something about something arriving as a manufactured little toast-point thing put me in the mind frame of, oh..finished component..this’ll work just fine. Sort of like getting a television from the store and, of course — it’s going to work, no problem.

Version Version Version Version Version Version Version

I’m in a fit of over-design. Here I am on the sixth edition of Flavonoid, which is going rather well. It does pretty much everything I would like it to do, save a proper rest mode, some little bit of recoding to make it more fuel efficient, a pedometer (step-counting) mode per Dennis’ request and, well — mostly commissioning a proper enclosure of some sort for it.

And then I had a number of things that sort of bugged me. One was the relatively low level of oomph with which the device could charge over USB. So, I started thinking about a number of power-related things. One idea (that the seventh edition will have) is a low-battery circuit that’ll allow the device to go to sleep when the battery is so low that it should be charged. For that I’m trying out the MAX6439 to raise a flag when the battery starts to bottom-out. Then I started thinking about a non-fixed battery — one that could be replaced and recharged in a normal recharger. So, I added that. Then I started thinking about a non-fixed battery being put in wrong way ’round which would definitely blow out the LDO regulator I’m using which isn’t, like..so great — so I added a little circuit using the MAX4636 CMOS switch to quickly fix that situation. Then there was the kind of annoyance of the real-time clock loosing track of time when power is removed — so I added a coin cell to keep the real-time clock juiced even when the proper battery has gone flat. And I knuckled into my own weird design fetish about things that don’t turn off and added a switch..so Flavonoid can be turned off..but it’s a very very small switch so maybe I won’t turn it off except in weird situations, like getting on an airplane or whatever.

I took off the reset pushbutton because I realized I was never hitting reset, pretty much. I left two plated holes so I could put a little reset jig together if I needed to, which I won’t, cause I can now turn the thing off and then on, or reset it any number of other ways. Here is the layout for version 7, now somewhere in China coming to be.

Lately I’ve been walking around with one on my hip and one in my pocket to capture some data. I wrote a little Python script that connects to the Flavonoid over USB, grabs the data and then tosses it up to the Flavonoid mothership database. I’ve also started jotting down how many steps the pedometer says for the day. I’m comparing pedometer steps to Flavonoid “data points” just for grins and to check for any correlation or consistency. These days, I’m not particularly physically active — I move back and forth between the bench and the desk, spend a few days a week doing more or less the same at Nokia — and that’s pretty much it. But, hopefully when others get theirs or if I try and do anything other than “test” myself, some insights will develop.

I’d actually be more interested in seeing some cool offline gaming style games develop..

In The Midst Of Design-Technology

In the midst of trying to finish this first run of Flavonoid boards — getting the firmware right, finding little gotchas in the design, little mistakes in the assembly process — I keep flipping back and forth between thinking about the minutiae of assembly and the craft work, and the 6-mile-up design theme. The minutiae is obsessive and completely tunes your head for basically just sitting in front of the tube (writing code, debugging code you’ve written, finding work-arounds, banging my head, asking Todbot for help with this and that.) Sometimes I almost forget why I’m making this thing.

So, for my own sanity. The Near Future Laboratory — Nicolas and I — are interested in experimenting with “offline gaming” — ways of interacting, particularly in mobile and pervasive contexts, that were digital and required some kind of engagement with physical aspects of the world. It was a way to begin investigating hybrid interaction rituals. Hybrid interaction rituals being those that coupled some action and activity related to the physical world, with digital practices.

One way we’ve been investigating this theme of offline gaming has been to speculate on simple kinds of game scenarios. One we are particularly keen on would work in the fashion of “accumulating” kinetic energy points by doing actual, physical activities. These kinetic nature of these activities — running, skipping, surfing, snowboarding, gardening — would accumulate these energy points which could be linked to power-ups of some sort within the digital game. So, physical activity in the normal, human physical world generates the potential for action in the digital game world, probably in an online environment. So, for example, your character in, say, WoW gets a — whatever — Rock of the Condor Sword because you’ve done a solid weekend of hiking and kyaking or something.

So, conceptually, there’s this mechanical linkage. You do something offline and see some representation of that offline activity, online, later.

Problem was — I really wanted to construct the device that would make that mechanical linkage. I played around with a few commercial pedometers, and thought about GPS, etc. I wanted the translation to be as seamless as possible. Dennis had experimented with using off-the-shelf pedometers translating the step numbers into a game grid. That’s the brilliant way about working on the problem. I personally found the pedometer a bit too instrumented. It wasn’t foot-falls I wanted to link to the digital representation of your physical activities — it was physical activity generally. So, more than just running or walking. But, suppose you garden? There’s not tons of walking to represent the activity. Or suppose you were a skateboarder or surfer? Pedometers aren’t particularly good for measuring that stuff.

I decided that I needed a more ambient accumulator of kinetic activity. A momentum-ometer. Or something.

At the most basic level, that’s what Flavonoid is — it measures changes in momentum across all real-world axes. What that means more simply is that it just records physical motion in every direction. It records this at time-based intervals that are configurable, and with a thresholding feature that allows you to ignore any motion below a particular threshold. Each data set records the accumulated changes in acceleration and the maximum change in acceleration for that period.

Two acceleration readings are taken at a time, with 100ms interval. The difference (change) in acceleration is what I record. Why change in acceleration? Because, by my estimation, that’s an indication of change in momentum, which is closer to work-done. I could be wrong — but its a convenient enough place to start. The main point is that I’m less particularly concerned with what the numbers mean specifically and more that they’re directly related to physical activity. No one would “count” accumulated changes in acceleration as they would accumulated number of foot-falls. But, these numbers can serve as a suitable input to the offline game experience just fine.

I also made this as a basis for a number of other projects within this general theme of creating hybrid interaction rituals. We needed some sort of device that could correlate physical activity and put it in a digital form that was amenable to a variety of different expressions. I had first hoped that a “connected” pedometer would work, generally — but many of these are closed systems, using proprietary interfaces. So, even if the pedometer did measure what I wanted it to measure (ambient activity rather than foot-falls), I couldn’t easily extract the data. That’d only work by hand, which wasn’t ideal.

Command Line

Here’s a revamped Flavonoid configuration console. This allows easy configuration over USB. There’ll be a few more commands in here for other features and crap, especially extracting the recorded data. This harkens back to the old school VT100 style terminal controls. There’s no drag-and-drop here, just words and commands. (Evocative of Don Norman’s bit on what he sees as a revival of the command line user interface. I wouldn’t say that this here in particular is a breakthrough, except in being retro.)

I like this mode of interaction. There are commands with parameters and that’s basically that. And output in a bottom area “annunciator” area. It makes the Flavonoid pretty much platform agnostic — anything that has a USB “COM port” and can obey VT100 terminal commands can interact here. And a keyboard.

This uses Pascal Stang’s cmdline library from his great avrlib for Atmel 8-bit MCUs.

Power Craft

Power. Faced with the design challenges of keeping things that don’t sleep awake as long as possible. One of the more intriguing aspects of the Flavonoid project has been to find ways that it can stay active and recording without it requiring a large, heavy battery. This battery here — the “Powerizer” — is about as big as I want to get. I also have some “flat-pack” style LiPo cells that might work well. The Powerizer is an industrial 3.6v 650mAh cell. Here Flavonoid is drawing about 18mA while recording data — the A2D converter is on and pretty actively sampling, the I2C/TWI bus is running frequently reading the time from the real-time clock. And every 15 seconds the LED blinks for a moment just so I know its alive. It’s also running a command line console interface over USB, so the FT232RL RS-232<->USB chip is spun up.

One problem I faced — still facing — is how to recharge the battery, which is basically “fixed” (non-removable, or only removable by removing soldered connections.) The design presently uses the Maxim MAX1555, which a chip that will charge a single LiPo cell over USB or from a +5 volt, higher current source, about 200mA, whereas USB will max out at 100mA. My laptop’s USB port won’t charge at more than 80mA at best. The idea here is that USB charging would be more convenient than having another wall plug and wire running around. Since the Flavonoid uses USB for configuration and downloading data, you’d have it hooked up over USB anyway. I assumed USB would be fine, and generally it is. But the times that I’ve tested the Flavonoid’s ability to run for a couple days, the battery went way low — 1.8v — and I had to recharge it from the higher current +5v source. Getting the Flavonoid to charge in the flat-battery circumstance is tricky. Presumably, since there’s no on-off switch, the Flavonoid is trying to start up, which draws a modicum of power, making it more difficult for the battery to just chill and charge.

What’s the alternative? Well, the immediate fix is to keep the Flavonoid plugged in at night so it maintains its charge. And I’m looking at adding a battery monitor (Maxim MAX6439) that will be able to let the Flavonoid microcontroller know when the battery voltage drops to a certain level. There’s built-in hysterisis so the battery needs to go above a specified voltage before the MAX6439 will let it know that its back in some kind of nominally revived state. The thinking here is that the battery monitor could trigger a pin-change interrupt that would put the Flavonoid to sleep so it draws barely any power at all. When the battery is back to normal, it’ll come back to and carry on as usual.

Techne

From a distance, the craftwork of prototyping speculative devices is really, really exciting to me. Thinking about design, electronics, construction, developing activated objects that actually work? That’s great.

From 10 millimeters, under a jeweler’s headset with tiny, tiny 30 gauge wires popping off .005 inch integrated circuit pins? I feel like a misunderstood King Kong or something.

I wanted to learn more about debugging at the microscopic scale with hardware, and this seemed as good a time as any. The debugging process essentially takes over the microcontroller, exposing all the little inner secrets — registers, program counters, memory, etc — and lets you step through your code line-by-line. The alternative is either to blink LEDs (if any are attached) and try to assume what might be going on based on that, or the old standard print to output, which means you have to roll a few libraries to actually do that, and have some sort of way of getting the microcontroller’s UART to talk to your computer. (Many of the projects I do have that feature as part of the design, but generally that isn’t always available.)

This has been working “okay” for Flavonoid, mostly because I rigged an interface for JTAG boundary scan debugging as an afterthought for this particular spin of the Flavonoid board. You can see it hasn’t gone super great — one of the little 30 gauge white wires there — the one sitting by itself on the right — keeps popping off the MCU, and I’m getting increasingly reluctant to hand solder it back to its pin again. It’s supposed to be attached to one of the multifunction pins on the Atmega324p that’s used for the boundary scan protocol. The heat and possibility of shorts makes me nervous. All the board soldering things on and off causes incremental problems — like the short to ground between a via and the spot on the board where the battery ground attaches just cause a little solder joined them. And the via was to the UART transmit so communication was only one way from the computer to the board, which was perplexing after everything worked. And perplexing for a couple of hours. Hours.

There are craft lessons learned here. Don’t put susceptible vias too close to other things where solder might cause a short, which means more closely inspecting board layout for such things, and creating special rules. Most vias won’t be near something of this sort, but occasionally they will. (Such was the problem with the first run of MobZombies boards where a via was placed way too close to a large ground pad that lived underneath a $35 tiny, leadless gyro.) A book of design rules-of-thumb would be useful to create.

Same with rules about creating accessible debugging test points. I had been conscious of this, but not for the ultra-useful boundary scan debugging. Part of what makes it useful — maybe one of the biggest reasons — is that it exposes all of the registers so you know right away whether you called something by the wrong name by mistake — a common problem when registers are named very similar things and bleary, late-night eyeballs are not as attentive. PORTA PINCA start to look the same after awhile.

There’s also this peculiar boundary scan process that I remember hearing about back in the day what when I was helping design relatively gargantuan integrated circuits. There was this test procedure where you could shift in and out data to individual parts of the device and figure out what was going on inside without having to actually connect directly to the chip. You could essentially send in a message that would set the state of various parts of the chip and retrieve state. There are these bits of logic that essentially sat in between pins and other logic that can either get or set the state of the innards when its in test mode. When your chip isn’t in test mode, the boundary scan cells that sit in there between the pins and logic are made invisible so they don’t effect the operation of the thing. The JTAG part stands for Joint Test Action Group — pretty vague — that was summoned into existence to figure out a standard way for testing digital electronics.

So, well — I think there’s something to be learned here that is not just about the minutiae of electronics and microcontroller debugging. There’s a character of design here that I’m enjoying and that deserves more attention. This is a process that is part of the circulation of ideas — from what is possible to what can be imagined and then, how do you construct it? As I collaborate more and more with innovation groups, designers, products people I am hopeful that more of the craftwork of creating what lies below the surface will be much more integral to the conversations these folks have. So that hardware craftwork is not outsourced but integrated in the concept, design, fabrication process.

Why do I blog this? Thoughts about the process of prototyping/sketching as a kind of design that’s part of “Design.”