Applications
What could you do with such a device?
- send email to other users of similar devices, as voice (perhaps encoded at 16 kilobits per second).
- essentially this lets you talk to friends and family even when they’re not nearby.
- send it over the Internet as well, perhaps using Bluetooth to a cellphone.
- keep notes to yourself — prices, to-do items, etc.
- compose and publish vocal essays, prayers, songs, etc.
- listen to the essays, etc. of others
- be notified of events happening out of your sight but within multihop radio range
- use voice synthesis software to read existing text, such as email or ebooks
- a small camera with OCR would help here
Most of these applications would run over a dynamically-routed mesh network that was mostly disconnected most of the time, so they would probably need to do store-and-forward flood-fill — transmit each piece of information to many more nodes than the shortest path, in hopes that one of them will eventually be able to relay it to its destination.
The rest of this page tries to estimate the feasibility of such a device.
Existing similar devices and related work
Perhaps the machines built for the Berkeley Motes project (the Intel iMotes and the Atmel ATmega-based MICA motes from Crossbow ) and similar sensor-network projects could be adapted for personal-terminal use. In particular, the MICA motes’ CPUs consume 24 milliwatts when running at 4MHz and 50 microwatts when asleep; they have 512K flash, 25x25x6mm (not including battery), a 40-kbps radio (30mW receive, 75mW transmit), and a 10-bit ADC.
Jason Hill built a smaller Berkeley mote version called Spec that’s a 2×2.5mm ASIC (in .35-micron), requiring only external oscillator, power, and antennas; the materials cost of that whole system is estimated at $0.62 plus antenna, and it includes:
an AVR-like RISC core… 3K of memory, 8 bit On-chip ADC, FSK radio transmitter, Paged memory system, communication protocol accelerators, register windows, 32 Khz oscillator, SPI programming interface, RS232 compatible UART, 4-bit input port, 4-bit output port, encrypted communication hardware support, memory-mapped active messages, FLL based frequency synthesizer, Over-sampled communication synchronization,…
Power sources
There are several possibilities here: disposable batteries, mechanical generators, grid power, solar cells, and car-battery (or motorcycle-battery) power. Since this is a popular problem, there are several other solutions on the horizon , including methanol-powered fuel cells, body-heat-powered thermocouples, piezoelectric ambient vibration harvesters, MEMS internal-combustion engines, and beta-particle-harvesting nuclear “batteries”.
Disposable batteries
These are widely available and can supply a lot of power — AA cells can supply 100mA to 500mA (according to eyespyvideo’s AA and AAA battery tests; otherpower confirms they can supply well over 60mA; Duracell claims its alkaline AA batteries can supply around 300 mA at 1.1V) but cost a substantial amount of money — comparable to the up-front device cost. One of the sales-points of the Freeplay wind-up radio is that it doesn’t have expensive removable batteries that can be stolen or hoarded by higher-ranking family members.
Connections to disposable batteries are very simple and cheap, costing a few cents, but they suffer from mechanical wear and breakage.
Mechanical generators
Trevor Baylis’s Freeplay foundation’s Lifeline radio has a wind-up spring that powers an electrical alternator to power the radio. Even more than disposable batteries, these can practically supply large amounts of power, up to several watts; however, they also wear out and break, unlike the other power sources discussed here.
I don’t know how much useful mechanical generators cost, but I think they can be manufactured for $1 or less, since they are simply electrical motors. However, the Freeplay radios’ pricing seems to start at $60 , or maybe $52.
You could even consider putting only the coil of the generator on the device, perhaps rectified with a germanium bridge, and allow users to charge it by changing the magnetic flux in its environment. Any sufficiently-strong permanent magnet would work. This design has no moving parts; a variant of it is the Forever Flashlight, which contains the permanent magnet inside of it. While the magnet is a moving part, its surface can wear a great deal without making it less useful, rendering this system essentially maintenance-free, if heavy and noisy.
Grid power
In places where grid power is available at least once a week or so, it’s possible simply to charge the device’s internal batteries from it then. However, this requires power-supply electronics to step down the mains power to the low voltages used by computing devices, which cost money — I don’t know how much — and does limit its applicability and convenience. Also, it may impose a tight power budget, since charging happens only rarely.
Solar cells
half-square-foot solar cell provides 1.8 watts, costs $57
0.2mm-thick PowerFilm amorphous power cells supply 22 mA at 3V in 50x37mm, or 25 mA in 100x25mm, or 50mA in 100x37mm, or at 6V, supply 100mA in 100x150mm. These numbers are all around 30-40 microwatts per square millimeter, and all refer to direct sunlight. Also, they seem to weigh about 8 milligrams per (peak) milliwatt, and cost about $4 plus 5.6 cents per peak milliwatt ($8.89 for the 22mA/3V, $7.89 for the 25mA, $13.89 for the 50mA, and $33.89 for the 6V/100mA). I’m guessing that the $4 per item cost is mostly the cost of buying items in quantity 1 for retail. Other vendors offered 3V/50mA 114x37mm thin-film panels for $2.75 in quantity, which is about 1.8 cents per peak milliwatt, as of five years ago, or 3V/50mA at $5.95 in quantity one.
Since the solar cells only charge during the day, they would put the device on a tighter power budget than the other power-source candidates, except possibly grid power — 150mW solar peak permits perhaps 25mW average usage.
New flexible solar cells producing almost three times as much energy are in development at the University of Toronto, but designing a device based on these is risky.
Car or motorcycle batteries
In much of the world, car and motorcycle batteries are much more ubiquitous than grid power (e.g. Design that Matters claims that “ the most common source to be found in Mali is a 12VDC lead acid battery, typically used in car/truck or motorcycle applications “, and they are also closer to the low-voltage DC power needed by portable electronics. Perhaps connecting to one of these batteries periodically could serve to recharge such a device with minimal additional charging circuitry — perhaps a cheap DC-DC converter.
In a digital-pony-express system like the Cambodian Motoman system , email moves from town to town by motorcycle anyway; in the absence of any other power source, you could get your charge at the same time as your email, particularly if you can charge quickly.
CPU
There are many CPUs that can operate under 25 milliwatts at a few MIPS; Atmel’s AVR-based FPSLIC (AT94K05/10/40AL) claims 100 microamps standby plus 2-3 milliamps per MHz , at close to one MIPS per MHz, at 3.0-3.6V — so that’s 0.3 milliwatts plus 6-10 milliwatts per MIPS, plus a 5K-40K-gate FPGA. 16x16mm TQFP, e.g.
FPGAs might be interesting for audio applications if they can do codecs more power-efficiently than a CPU, which seems plausible. Certainly codec ASICs use much less power than CPUs running the same codecs in software.
FPGAless CPUs like the ATtiny11 can use still less power: it runs at 4MHz on 6.6mW, idles at 1.5mW , and has a power-down mode of under 3 microwatts, and can be throttled up to 8MHz. That’s in an 8-pin PDIP/SOIC. These CPUs cost around $1.50 in quantity one from Jameco .
The CPUs mentioned so far are rather cramped; they’re amply fast enough to handle basic control applications, but their RAM is tiny. It seems that it’s hard to find CPUs with more than a few kiB of on-die RAM; but moving up to the high-end, Atmel’s ARM920T-based feature-packed AT91RM9200 still uses only 60mW at 200MIPS, 31x31mm. (I can’t find pricing data on it, though.) The similar EP9302 from Cirrus is supposed to cost $10 in volume , but uses dramatically more power, around 500mW. Other low-power Atmel ARM microcontrollers cost $9-$25 each, even in volume, from Digikey ; the cheapest ($9) is the AT91M40800-33AI-ND , which does 40MHz; static power consumption ranges from 12.5 to 250 microamps at 3.6V, so under 1mW (possibly dramatically under), and dynamic consumption is around 1-5 milliwatts per MHz, plus up to about another milliwatt per MHz for peripherals. It’s been available since 2000, so I suspect that today’s CPUs could do considerably better than 1 MIPS per milliwatt, perhaps 4 MIPS per milliwatt. But maybe they would cost more.
Ideally you’d be able to run off-the-shelf software for as many features as possible; I think this MMUless ARM CPU can run uCLinux, but I’m not sure.
Energy storage
The quantities of energy required to be stored for such a device might occupy a wide range; solar pagers might need to store only enough energy for night operation, which might be quite minimal, while pagers powered off the grid might need to store enough energy for a week’s operation, and at the extreme end, a device the user can re-power by shaking (like the Forever Flashlight) might only need a few minutes of power consumption. It appears that 25mW power consumption when active may be a feasible power budget; perhaps the devices might be active for an hour or two per day, yielding 2mW average power consumption, plus idle, which might be another 2mW for a total of 4mW, or 1.3 mA at 3V.
So an energy storage system might usefully store anything from 1 mAh (if the user can easily add more energy) to 20 mAh (for a system solar) to 110mAh (for a weekly-grid-charged system).
These numbers are on the very low end for rechargeable batteries; in fact, it’s down in the range where carbon aerogel “supercapacitors” can work. Commonly these cost less than $1, can be charged to 2.8V, and have a capacitance of a farad or so, which means they hold one coulomb (ampere-second) of charge per volt. An ampere-second is about 280 mAh, so while discharging from 2.8V to 2.0V, such a capacitor delivers 220 mAh, or 530 mWh.
Capacitors weigh more, cost more, and take up more space per unit of energy storage than batteries; their advantages are that they can be charged very quickly (typically they can be charged at 30A, so they can be fully charged from empty in 93ms) and they can survive more charge cycles than a battery (they are commonly used in applications where they are partly charged and discharged tens or hundreds of times per second, and survive for many years.) Clearly the ability to fully charge in well under a second is more important if you’re charging from an itinerant motorcycle than if you’re charging from a solar cell.
(to do: insert actual cost and size figures in this section)
Volatile memory
I think DRAM is far too power-hungry for such a device, so static CMOS RAM may be the only usable alternative. A few megabytes would be nice in order to support a wide range of applications, but only a few kilobytes are needed for the basic networking and voice-mail logic. However, if the CPU is running audio codecs, it will probably need at least a few hundred kilobytes to support that.
(to do: insert actual cost, power consumption, and size figures in this section)
Nonvolatile Memory
There are only two presently feasible alternatives for nonvolatile memory in such a cheap and low-power device: “flash” EEPROM, and nothing. The “volatile” memory might be sufficiently nonvolatile under some circumstances; if it can survive for weeks or months on the residual energy stored in the energy storage device when the device has too little power to run the CPU, particularly if recharging is quick and easy (as with the mechanical generator and solar types), the advantage of “flash” may be small.
(to do: insert actual cost, power consumption, and size figures in this section.)
Radio
Communication costs a lot of power , with each bit transmitted costing at least as much as a thousand CPU instructions. Typical medium-range radios consume 1-20 milliwatts and have ranges from meters to tens of meters.
It would be useful if the radios were compatible with other widely-deployed devices, such as Bluetooth phones, to provide Internet connections without further NRE efforts and deployment risks. Bluetooth data transfers practically run at a few hundred kbps, so could transfer voice messages coded at 16kbps around 10x-50x real-time; an hour of voicemail might transfer in 2-5 minutes.
The Mote devices use their own low-speed radio protocol to transfer data between them at a few tens of kilobits per second. In general, you can get longer range by either decreasing bit-rate or increasing power usage.
One of the power-saving features of the Motes is that they run their radios in receive mode (costing 30mW) only a small fraction of the time, when they expect to be receiving data. As long as their peers know when to expect them to be listening, they can schedule data transfers for that time.
If our average power budget is on the order of 4mW, and listening on radio costs 30mW, we probably need to keep its duty cycle under about 1%.
TDM power control
Most of the following techniques were explained to me by Barbara Hohlt from the Berkeley Motes project, although the system described is not the same as the one she designed — only inspired by it.
If you listen at certain predetermined times for new conversations, you can achieve this low duty cycle. I’ll refer to the period of time you’re listening as your “timeslice”. Your timeslice recurs at regular intervals; I’ll call this interval the “cycle time”. And, finally, you need to transmit a heartbeat or “beacon” packet every few cycles that contains your node id, clock reading, and timeslice assignment, for synchronization and network topology maintenance; I’ll call this the “heartbeat interval”.
In real TDMA systems, you are only allowed to transmit or receive during your assigned timeslices, and you have to allocate them dynamically through a process of negotiation. In this system, none of this is necessary; you simply assign yourself a timeslice and periodically tell your neighbors when it is, and they will wait until that timeslice to initiate conversations with you. Multiple-access interference can be handled simply by retransmitting unacknowledged frames a small random number of cycles later.
The timeslice-length we choose is limited on the low end by clock drift considerations, and on the high end by latency and promiscuity considerations.
Clock-drift considerations merely say that your timeslice must be large enough to accommodate your neighbor’s relative clock drift to your own. Typically quartz clocks have accuracy close to a part in a million, so your timeslices need to be no smaller than perhaps 1/100 000 of the heartbeat interval.
Data-rate considerations might seem to say that our timeslice must be long enough to receive a useful amount of data, but since the timeslice allocation is only used to allow neighbors to initiate data transfers, it does not. The transmission can continue as long after your timeslice as desired, as long as the conversation remains active.
Periodically, in order to connect with new neighbors, we will want to listen through a whole heartbeat time in order to detect unexpected beacon transmissions from new neighbors, which I term “promiscuous reception”. This will require orders of magnitude more energy than our regularly scheduled listening, and so should happen orders of magnitude less frequently. But it must happen often enough to guarantee the discovery of new neighbors with acceptable latency.
Gossip can tell you about new neighbors that your neighbors already know about, but when two previously disconnected groups connect, it’s desirable to discover this relatively rapidly. For example, when the farmer comes home from working alone in the field, it is desirable that his messages to his friends and family be transmitted within a few minutes.
So at least every few minutes, you have to promiscuously listen through a full hearbeat interval. Keeping the duty cycle low means that a full heartbeat interval should be no more than 1/1000 of a few minutes, so it’s at most less than a second.
The number of cycles per heartbeat
If you were to tell each of your neighbors your clock reading every interval, then your time-slice could be 1/100 000 of the interval. For example, you could listen for 50 microseconds out of each five-second interval. This gives your radio a receive duty cycle (in idle) of 1/100 000, which is great, but also a transmit duty cycle of perhaps 10/100 000, if you have ten neighbors on average, and that costs perhaps 20 to 40 times as much. (You can reverse this by broadcasting your clock reading during your own time-slice and listening to your neighbors’ broadcasts during their time-slices — now you have a transmit duty cycle of 1/100 000 and a receive duty cycle of 10/100 000. But there’s a better solution.)
If, instead, you transmit your own clock reading every six intervals, you must use a larger timeslice: 6/100 000 or so — and that becomes your idle receive duty cycle. But now your transmit duty cycle is only about 10/600 000, or 1.3/100 000. (This assumes you can transmit your entire clock reading within your window, which may be unreasonable.)
Practically speaking, idle duty cycles of less than 1/1000 probably provide no additional benefit, since reducing your 30-microwatt-average idle radio to 15 microwatts won’t make a significant difference in the average power consumption of the device. So you could listen for 100 microseconds out of each 100 milliseconds and transmit your clock reading once every 500 milliseconds.
There’s another alternative to listening through a full transmit interval, which is random occasional transmission and receiving.
Audio Codec Hardware
Specialized codec hardware can often use two orders of magnitude less time and, I believe, less energy than general-purpose von Neumann machines running the same codecs in software.
There are two other alternatives: FPGAs, which I think use more power than ASICs (perhaps an order of magnitude?) and less than CPUs to perform such functions, and DSPs, which are general-purpose CPUs specialized for such applications (so they can do them in fewer clock cycles — I don’t know about less memory). In addition, CPUs tend to require substantial amounts of memory for such codecs.
(to do: insert real cost, power consumption, and size figures here.)
Audio Input and Output
A 10- or 12-bit ADC sampling at 8kHz is quite adequate for recording voice, although more doesn’t hurt; many microcontrollers include such devices in the chips themselves, and can be connected directly to a small dynamic microphone input with a DC offset. Typically DAC output in such devices is handled by PWM plus filtering, and I think the outputs on such microcontrollers are sufficient to drive earphones. I don’t know how well this works for voice.
External ADCs and DACs along these lines are relatively cheap and low-power as well, and at least the DAC can be entirely powered down much of the time.
If audio is the only user input into the device, however, it needs to be listening enough of the time to know when you call its name. Perhaps you could start by detecting sufficiently-loud sounds with passive analog circuitry (a band-pass filter to pull out sounds in the range of voice, a rectifier to convert to DC, and a very simple low-pass filter to ignore sufficiently short sounds) and use that to wake up the CPU; or use some kind of mechanical or capacitive switch to get the CPU’s attention.
Perhaps, though, you could run the device continuously at low speed; can you run a modern DSP or FPGA at 10000 MACs per second for a fraction of a milliwatt in order to do voice processing constantly? You can run 100 000 cycles on a non-DSP each second; on the Atmel chips mentioned previously this would cost 0.1 to 0.5mW. Presumably a chip designed for this could do it for less.
All of this attention-processing stuff would be unnecessary when the device had run too low on power to run the CPU anyway, so it doesn’t count against the power cost of retaining SRAM as NVRAM.
(to do: include real power costs of ADC on the Atmel chips, external ADC/DACs, and size and monetary costs of the latter as well)
Conclusions
Credits
Kragen Sitaker wrote the first draft of this document; it came from discussions with Rohit Khare and Smruti Vidwans, and Dan Gould provided some useful insights as well. Barbara Hohlt told me about TDM power control.