Ambient backscatter

An interesting article on how to power sensors and other "Internet of Things" devices.

A group at the University of Washington has developed a way of making use of "stray" radiation to power simple radio transmitters and receivers. Rather than use a dedicated power source, whether on-board like a battery or transmitted as in near-field communications, this technique makes use of the ambient radiation of cellphone signals, wifi networks and the like to provide enough power to energise a simple radio link.

Recycled Energy: Ambient Backscatter Allows Wireless Communications with no Batteries

If it works reliably, this'll be a huge contribution to low-power environmental sensing as well as to the applications the authors are targeting.

How to write an abstract

An abstract is an advertisement, not an introduction.

I've spent much of this week working with MSc students writing their dissertations, and this has inevitably led to the part of a dissertation that often causes the most pain to write (and read, for that matter): the abstract.

What is the abstract of a report or paper? What it isn't is an introduction or guide to the rest of the document: that, unsurprisingly, is what the introduction is for. The goal of an abstract is much simpler: it's intended to persuade the reader to read some or all of the rest of the document. It may be surprising that this is an issue, but in a world in the grip of an information explosion it's clear that readers' attention is a limiting quantity in information processing. As a reader, should you bother to read a paper? Or not? And how do you make this decision?

Many new researchers, when confronted with a paper, start at the front and work forward. More experienced researchers know this is a mistake that leads to reading whole tracts of irrelevance or nonsense. (The former is worse: nonsense at least has occasional entertainment value.) This leads many people (myself included) to adopt a non-linear reading style:

  1. Read the abstract
  2. If still interested, read the conclusion
  3. If still interested, read the introduction
  4. If it's really interesting, read the rest of the paper
(There are several variants, a couple of which are described here and here.) The point here is that we can filter out papers of lesser interest to reserve time and head space for the most interesting. Only if the results grab your attention do you need to spend time discovering the detail of how they were obtained -- rather than doing that work only discover that you don't care about the results being reported.

The abstract is the key: without a decent description of what the paper is about, the discerning reader will not proceed even to the introduction, and therefore any work contained in the paper will remain unread -- and therefore be largely worthless.

So how does one write a decent abstract? Most experienced scientists have their own technique, and the approach does need to vary from field to field and for different paper styles: a review paper is different to a piece of primary research. The approach I've come to rely on for research in computer science and mathematics can be described succinctly as the five-sentence abstract. I've found five sentences seems to be about optimal, structured as follows:

  • The area of the paper (1 sentence). The problem area to which this paper makes a contribution.
  • The issue the paper addresses (1 sentence). Presumably the area is not yet fully explored, and you've found a problem that needs tackling -- otherwise what's in your paper?
  • What you've done, the results you've obtained (2 sentences). The key contribution of the paper, what you've added to practice and/or knowledge
  • What this means (1 sentence). Why should anyone care?

Let's do an example, from a paper I've always wanted to write about finding unicorns:

There are lots of interesting animals out there, many of which have horns. No-one has yet reported observing any one-horned horses, however. We describe our research survey of the horses of the West of Ireland. While we found many horses, and many other horned animals, we failed to locate any horned horses. We conclude that further research is required to find unicorns, preferably in an equally pleasant holiday destination.

OK, perhaps not a great example. Let's try another, from a real paper:

In the domain of ubiquitous computing, the ability to identify the occurrence of situations is a core function of being context-aware. Given the uncertain nature of sensor information and inference rules, reasoning techniques that cater for uncertainty hold promise for enhancing the reasoning process. In our work, we apply the Dempster Shafer theory of evidence to infer situation occurrence with the minimal use of training data. We describe a set of evidential operations for sensor mass functions using context quality and evidence accumulation for continuous situation detection. We demonstrate how our approach enables situation inference with uncertain information using a case study based on a published smart home data set.

(Taken from McKeever, Ye, Coyle and Dobson. Using Dempster-Shafer theory of evidence for situation inference. In Proceedings of the 4th European Conference on Smart Sensing and Context (EuroSSC). Volume 5741 of LNCS. Springer-Verlag. Guildford, UK. 2009.) The abstract goes from domain to challenge to approach to significance: having read it, the reader hopefully has a fairly good idea of what the paper contributes to which domain, and why this contribution is significant (in the authors' minds, at least).

Shorter is often better, of course:

Wireless sensor networks are attracting increasing interest but suffer from severe challenges such as power constraints and low data reliability. Sensors are often energy-hungry and cannot operate over the long term, and the data they gather are frequently erroneous in complex ways. The two problems are linked, but existing work typically treats them independently: in this paper we consider both side-by-side, and propose a self-organising solution for model-based data collection that reduces errors and communications in a unified fashion.

(From Fang and Dobson. Unifying sensor fault detection with energy conservation. In Proceedings of the 7th International Workshop on Self-Organising Systems (IWSOS'13). Palma de Mallorca, ES. May 2013.) In this case my student Lei messed with the sentence structure because we wanted to get across the idea that the main problem was the totality of the existing approach to the problem, which we wanted to address as a whole. The abstract still follows the basic structure, and I think is stronger for being shorter.

No rule of writing is hard-and-fast, of course, and so you'll often find great abstracts that adopt a completely different approach. I don't think this matters so much as ensuring that the abstract is fit for purpose: an enticement to read further.


Paul Lockhart


This is a quite phenomenal tour de force by a talented and enthusiastic mathematician keen to break down the mystique and barriers to the subject. He does do spectacularly well: this little volume covers an amazing amount of ground, from simple measurement concepts and problem-solving all the way up to the ideas that underlie some of the most modern pieces of mathematics like differential forms and the calculus of variations. On the way everyone will learn something they didn't know, in my case the relationship between natural logarithms and conic sections.

Finished on Mon, 05 Aug 2013 08:33:39 -0700.   Rating 5/5.

Inside Hitler's Bunker: The Last Days of the Third Reich

Joachim Fest


This is the book on which the film "Downfall"was largely based, and is I think the only treatment of these events by a German author. Fest exposes a lot of the research and interpretation that's happened since the other, classic histories were written, and gives a very insightful analysis of how the bunker doors into the context of Hitler's life and the end of the Third Reich. Well worth a read

Finished on Mon, 05 Aug 2013 08:12:50 -0700.   Rating 4/5.

XBee sleeping

Clearly saving battery power means getting the XBee radio to sleep at the behest of the Arduino. This turns out to be fairly simple, but does require modifying the XBee shield slightly.

Our previous measurements indicate that the XBee draws about 45mA of current -- something we have to save for battery-powered nodes. Fortunately XBee radios have a hardware-controlled sleep mode, so the Arduino can sleep the radio when not in use.

Since XBees work as a mesh network, it's clearly going to be an issue as to when a radio sleeps, and for how long -- since when asleep the radio can't route packets, and so the network starts to break down. But that's a higher-level concern: for the moment, we'll focus on the mechanics of getting the XBee to sleep.

Pins relating to XBee sleep mode

The basic mechanism is simple, and involves hardware and software. At the hardware level, the XBee uses pin 9 (shown in red right) as a control pin. This pin can be used to sleep the radio: setting it to 3,3V ("high" or "asserted") causes the radio to sleep; setting it to 0V ("low" or "deasserted") wakes the radio up. The XBee only takes account of the pin when in certain sleep modes, however: these are analogous to the Arduino's sleep modes. This is the software part: the XBee needs to be placed into the correct sleep mode, and can then be controlled from the Arduino.

Also note I/O line 7, pin 12 (in green): we'll come back to this later.

We'll deal with the hardware part first, and then the software.

Getting access to the sleep pin

The XBee shield doesn't connect the sleep pin to anything by default, so to control it we have to connect it. There are several ways we could do this, with the simplest being to solder a wire from the pan on pin 9 to an appropriate header on the shield, which is then connected to a digital pin on the Arduino. For simplicity we'll start with a wire that's long enough to reach any header: we'll actually plug it into the header for the Arduino's D7 pin.

There's a slight concern about voltage levels in this approach, as the Arduino operates at 5V while the XBee uses 3.3V. Experimentally this doesn't seem to make a difference; for a production system we'd probably want to create a resistor network to drop the voltage to that needed by the radio, to avoid any risk of damage. We'd also probably want to solder a header to XBee pin 9's pad to make it easier to connect the wiring.

Setting the sleep mode

The XBee's sleep mode is controlled by a single AT command called (unsurprisingly) SM. The default (SM 0) is for the radio to be on all the time; SM 1 selects the pin-sleep mode described above, and is the one we'll be using as it places the radio under the (hardware) control of the Arduino. (There are other sleep modes where the radio sleeps under the control of its own internal timer. Some projects use the radio's timer to wake the Arduino rather than the other way round: we prefer to keep the Arduino in control.)

Setting the sleep mode is simply a matter of issuing the appropriate AT command. However, as with a lot of things to do with hardware, we have to set things up slightly first.

The first issue concerns the setting of the XBee's sleep pin. If we select pin-sleep mode with the pin high, the XBee will sleep immediately, which might not be what we intended. So if we've connected the sleep pin to D7, we need to set things up so that the pin is low to keep the radio awake, and then select its sleep mode:

#define XBEE_SLEEP 7                // Xbee sleep pin on D7

void setup() {
   pinMode(XBEE_SLEEP, OUTPUT);     // sleep control
   digitalWrite(XBEE_SLEEP, LOW);   // deassert to keep radio awake when sleep mode selected

(Some early mistakes showed that -- contrary to what might be expected -- the sleep pin defaults to high (send radio to sleep) rather than low. So this step is important.)

The next issue concerns the rather intricate behaviour of the XBee's other pins when sleeping. When the radio enters sleep mode, it asserts its I/O 7 line (pin 12) so that external devices know that it's asleep. This could be used to make sure that external peripherals wake up only when the radio is active, but for some reason the XBee shield's designers have connected this pin to the Arduino's reset line, which means that sleeping the radio will reset (and in fact freeze) the Arduino. Some posts suggest that solving this requires cutting lines on the shield, which might have been true for earlier shields but now isn't: we simply need to disable the output of this pin, using another AT command:

atCommand("D7", 0);

This disables the XBee's D7 line (not to be confused with the Arduino's D7 line, which we've attached to the XBee's sleep pin), which is enough to stop the Arduino freezing. on sleep. (Yes, this did take quite a while to work out, since you ask...)

We can now put all this together to place the XBee into SM 1  and let the Arduino sleep it at will:

#define LED 13
#define XBEE_SLEEP 7                // XBee sleep pin on D7

void setup() {
   pinMode(LED, OUTPUT);            // LED signal
   pinMode(XBEE_SLEEP, OUTPUT);     // sleep control

   digitalWrite(XBEE_SLEEP, LOW);   // deassert to keep radio awake when sleep mode selected
   if(atCommand("D7", 1) | atCommand("SM", 1)) {
      // AT commands failed, flash frantically

Note that we've used local AT commands to set the radio's mode. It's also possible to do this statically using X-CTU.


XBee with sleep control

The results of all this hacking are that the Arduino can put the XBee into sleep mode whenever it wants to simply by asserting D7. The voltages on pins are maintained even when the Arduino itself sleeps, so it can put the radio to sleep and then sleep itself, wake up and wake up the radio.

Measuring current shows that the sleeping Arduino and XBee draw abour 35mA, the same as an Arduino alone. This makes sense, as the XBee datasheet suggests that when sleeping it draws current in the microamp range -- far too small for a normal ammeter to measure, and dwarfed by the quiescent current of the Arduino board (which still needs some work).

Waking the radio happens quickly when the sleep pin is deasserted, but it seems to take some time to re-connect to the mesh co-ordinator: around 7s, in fact, which is a little strange and needs some more exploration.

Issuing AT commands

Controlling the XBee requires issuing AT commands. The XBee library has the low-level machinery to do this.

AT commands are the basis for controlling almost all modems, and the XBee is no different. In API mode, AT commands are issued in a similar manner to sending data. The Arduino XBee library has the low-level code needed, which can be wrapped into a slightly easier-to-use form.

The basic approach is to send an AT command request packet and then read a returned packet acknowledging the command. For the moment we'll stick to "setting" commands, where the AT command takes an integer parameter: the other are needed less frequently. We construct the request packet, send it, read the response, and check that all went well. This isolates the rest of the program from the message exchange, but also hides the exact nature of any error.

#include <XBee.h>

XBee radio;

int atCommand( char *command, uint8_t param ) {
  // send local AT command
  AtCommandRequest req = AtCommandRequest((uint8_t *) command, (uint8_t *) &amp;param, sizeof(uint8_t));

  // receive response frame
  AtCommandResponse res = AtCommandResponse();
  if(radio.readPacket(500)) {                               // read packet from radio
     if(radio.getResponse().getApiId() == AT_RESPONSE) {    // right type?
       if(res.isOk()) {                                     // not an error?
         return 0;

  // if we get here, return a failure
  return 1;

This function can be used to issue the different control codes for the radio. Some parameters can be set using X-CTU when the radio firmware is installed, but commands are sometimes needed at run-time too.

Basic power measurements

Some initial measurements of power consumption.

How much power does Arduino sleep mode save? The simplest way to work this out is to power an Arduino from a battery pack and measure the current being drawn in the different modes. A simple program to demonstrate the different modes is:

  • Normal delay() loop
  • Deep sleep for a period (deep sleep)
  • Flash the LED (awake)
  • Flash the LED differently while sending out radio messages (awake and transmitting)
We perform these tasks repeatedly, keeping them going for 10s each to let the power draw stabilise.

The results are as follows:

Activity Power mode Current
Nothing delay() loop 43mA
Nothing Deep sleep 33mA
Steady LED Deep sleep 34mA
Flashing LED Awake 45mA
Xbee (quiet) Deep sleep 72mA
Xbee (quiet) Awake 85mA
Xbee (transmitting) Awake 87mA

The good news is that SleepySketch makes it very easy to access the deep sleep mode, and to stay in it by default. This is good, as the normal approach of using delay() is quite power-hungry. The bad news is that the "at rest" power consumption of an Arduino even in deep sleep  -- the quiescent current being drawn by the voltage regulator and other components on the board, regardless of what the microcontroller is doing -- is about 35mA, with an XBee drawing an additional 40mA.There is very little difference in power whether the radio is transmitting or not (although the current being drawn looked more variable when transmitting, suggesting that there's some variation happening faster than the ammeter's sample time).

The radio isn't put to sleep when the Arduino is asleep, which is clearly something that needs to happen: it draws power even when the Arduino is incapable of using it. Something to explore. Potentially more serious is the power being drawn when the Arduino is asleep. A battery pack with 4 x 1500mAH batteries will be drained in about 7 days (6000mAH / 35mA) even with the system asleep all the time.

[UPDATE 1Aug2013: made the table layout a bit clearer.]