It turns out there there are quite a few versions of the “same” components out there. Uploading sketches to an Arduino-on-a-breadboard is trickier than it first appears.

The Arduino-on-a-breadboard showed that we can get a lower power version of the same architecture. However, in doing the measurements I used a microcontroller already loaded with the code I used for the power measurements (sleeping and blinking). Trying to change this code and upload it via the USB breakout board didn’t work — repeatedly.

It turns out that the breadboard tutorial on the Arduino web site is actually flawed for the current versions of the components concerned. There are actually two problems: the microcontroller needs to be manually reset before uploading a sketch; and the USB breakout board needs slightly more supporting electronics to talk to the microcontroller.

The first problem stems from the microcontroller needing to be reset before code can be uploaded to it. Essentially the reset makes the bootloader wait for code for a few seconds, and start the existing program if none arrives. On older Arduino models you have to physically reset the board using the reset switch just before uploading a sketch; on newer models, this reset happens automatically. Setting up the breakout board to reset the microcontroller immediately before it tries to talk to it will solve this.

The second problem is more subtle. The USB breakout board is actually a USB to serial converter. The tutorial suggests that it is enough to connect the transmit and receive (Tx and Rx) lines to the microcontroller, but this turns out not to be the case: one also needs to connect some handshaking lines to make the system synchronise and communicate correctly. I eventually found a post that explains this: however, that post is flawed too, because it relies on a particular pin-out for the USB breakout board that’s different tothe one I have. So here’s a debugged explanation of what needs to happen.

We need to connect the basic TxD, RxD, Vcc and Gnd lines on the breakout board as you’d expect. The picture to the right shows the the underside of my breakout board, with the pins named. If we number the pins counter-clockwise from the top left (so DCD is pin 1, TXD is 9, TXLED is 11, and VCC is 13), we connect pins 3 and 10 to ground, pin 13 to power, pin 9 to pin 2 of the ATMega microcontroller, and pin 5 to ATMega pin 3.

What now also need to happen is that we need to connect the CTS and DTR lines to something. DTR (Data Transfer Ready) is sent low when the USB has data ready: we want this to trigger a reset of at ATMega. We then need to send CTS (Clear To Send) low so that the board starts sending data. This is basic serial-port handshaking. The timing can be accomplished using an RC circuit consisting of a 100ohm resistor and a 100nF capacitor attached appropriately. Putting this circuit onto the breadboard sorts out the handshaking, and the Arduino IDE happily uploads sketches just as it would to a “real” Arduino.

The net result of this is to add some more wiring to the USB end of the Arduino breadboard:

Note the resistor and capacitor. (The red wire crossing the breakout board is a Gnd connection, needed because my breadboard only had single power rails top and bottom.) The circuit involved is as follows:

For my particular breakout board shown above, this means connecting pin 7 to the capacitor and pin 15 to the following resistor. (It’s this last step that the post gets wrong — or at least uses a different pin for CTS.) The net result is an Arduino-on-a-breadboard that looks like this:

Somewhat more complicated, but rather more functional.

I think you have to maintain a sense of perspective about these issues, annoying as they are: in many ways it’s good that the components change and evolve rather than staying exactly the same, as it means that they’re being developed and refined over time. On the other hand, it means you have to be very circumspect about following blindly the tutorials and explanations on blog posts from even a relatively short time ago.

Putting an Arduino together from scratch lets us look at where the power consumption might be reduced — and is just an interesting thing to do anyway.

One of the most exciting things about the Arduino is that it’s open-source, so you can build them yourself — and potentially vary the way they’re put together for specific projects, which is very useful as a starting point for people (like me!) who aren’t hardware engineers.

The main challenge for sensing with Arduinos seems to be their power consumption, and the obvious way to address this is to see whether there are things to be done to reduce the power drain, for example by addressing the issue of the quiescent current of the power regulator.

As a starting point, I used an on-line guide to build an Arduino on a breadboard:

Actually this isn’t a “full” Arduino as the analogue to digital converter (ADC) isn’t properly set up, but it has the basic components of microcontroller (the same ATmega 328P as on an Arduino Uno), LED, reset switch, power, and USB. The breakout board at the left-hand side is the USB adapter, while the cluster of components on the right is the power regulator. At present I’m powering from batteries; one can also power from the USB, or from a wall power supply via another breakout board, but this way allows the same power measurement regime as earlier.

Measuring power for a simple “blink” program gives the following result:

Activity	Power mode	Current
Nothing	Deep sleep	4.5mA
Flashing LED	Awake	17mA

So in deep sleep mode the system draws about a seventh the power as a “real” Arduino. This is all down to the choice of voltage regulator: an L7805 with a design maximum quiescent current of 6mA. To put this into perspective, a system that could last a week on a standard Arduino board would last the best part of two months in this configuration. Put another way, we can build a sensor mote with an Arduino architecture and dramatically increased lifetime by changing a core component and using SleepySketch to keep the system asleep by default.

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.  

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: (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.