Simon Dobson (Posts about arduino)

Citizen sensing with Arduino

Simon Dobson — Thu, 24 May 2018 12:26:34 GMT

Introducing some notes on low-power Arduino programming.

In 2013 I did a summer project on using the Arduino as a platform for "citizen sensing". This rapidly became an exploration of how to create hardware and software that can do sensing while operating in a very low-power regime, such as one would need for an environmental sensor.

There were several results from this project -- one of which wasn't an actual solution to the motivating problem I'd come up with. However, it did generate a lot of notes about low-power Arduino programming, both for hardware and software, and a software library that embodies some of them

I recently decommissioned the web site I was using to host this content, so I've ported it onto my main blog as a collection of research and development notes in case it's still of interest to anyone.

First SleepySketch release

Simon Dobson — Tue, 07 Jan 2014 12:36:14 GMT

Happy 2014! We're particularly happy to be making the first release of the SleepySketch library for writing low-power Arduino sketches. SleepySketch changes the way you write Arduino sketches by letting the library, rather than the main body of the sketch, decide when to run code. The sketch stays asleep as much as possible, with the Arduino placed into a low-power state to preserve battery. This is a first release of SleepySketch, for comments. It provides a sketch framework, a basic sleep manager, and an example "blinkenlights" demonstration to show how the system fits together. Future releases will provide more flexible sleep management and support for component-level power management for common components like Xbee radios. You can download SleepySketch v. 0.1 from here.

Scratch: visual programming for Arduino

Simon Dobson — Tue, 08 Oct 2013 07:00:12 GMT

For some people, traditional programming is daunting. This needn't be the case, and there are several more visual programming studios available -- one of which has now come to the Arduino. Scratch is a long-running programme from MIT that lets non-programmers -- and especially kids -- get started writing complex programs. It comes from the family of languages that include Squeak and Etoys, all intended to demystify programming and computers. Scratch has now come to Arduino by way of S4a, that lets people develop sketches using a very visual approach: A Scratch program It's hard to describe exactly how this sort of visual programming works, and it's definitely not suitable for all tasks: typically it's better for exploratory and experimental, "play" approaches rather than more detailed and complex processes. But it'll be great to see whether this is appropriate for many of the applications the Arduino finds a home in -- and even more so to explore it for what we're trying to do here at Citizen Sensing.

Uploading sketches to a breadboard Arduino

Simon Dobson — Wed, 28 Aug 2013 20:50:04 GMT

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.

Low-power Arduino-on-a-breadboard

Simon Dobson — Tue, 27 Aug 2013 10:47:45 GMT

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.

XBee sleeping

Simon Dobson — Fri, 02 Aug 2013 14:41:30 GMT

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.

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
   Serial.begin(9600);
   radio.setSerial(Serial);

   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.

Results

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

Simon Dobson — Fri, 02 Aug 2013 11:03:54 GMT

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));
  radio.send(req);

  // receive response frame
  AtCommandResponse res = AtCommandResponse();
  if(radio.readPacket(500)) {                               // read packet from radio
     if(radio.getResponse().getApiId() == AT_RESPONSE) {    // right type?
       radio.getResponse().getAtCommandResponse(res);
       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

Simon Dobson — Wed, 31 Jul 2013 17:12:55 GMT

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.]

Understanding Arduino sleep modes: the watchdog timer

Simon Dobson — Tue, 23 Jul 2013 14:21:27 GMT

The Arduino has several sleep modes that can be used to reduce power consumption. The most useful for sensor networks is probably the one that uses the watchdog timer.

Powering-down the Arduino makes a lot of sense for a sensor network: it saves battery power allowing the system to survive for longer. Deciding when to power the system down is another story, but in this post we'll concentrate on documenting the mechanics of the process. The details are necessarily messy and low-level. (I've been greatly helped in writing this post by the data sheet for the Atmel ATmega328P microcontroller that's used in the Arduino Uno, as well as by a series of blog posts by Donal Morrissey that also deal with other sleep modes for the Atmel.)

Header files and general information

To use the watchdog timer, a sketch needs to include three header files:

#include <avr/power.h>
#include <avr/wdt.h>

These provide definitions for various functions and variables needed to control the watchdog timer and manage some of the other power functions.

Power modes

A power (or sleep) mode is a setting for the microcontroller that allows it to use less power in exchange of disabling some of its functions. Since a microcontroller is, to all intents and purposes, a small computer on a chip, it has a lot of sub-systems that may not be needed all the time. A power mode lets you shut these unneeded sub-systems down. The result saves power but reduces functionality.

Power modes are pretty coarse control mechanisms, and can shut down more than you intend. If your project is basically software-driven, with the Arduino making all the decisions, then a "deep" power-saving mode is ideal; on the other hand, if you rely on hardware-based signals at all, a "deep" sleep will probably ignore your hardware and the Arduino may never wake up.

The watchdog timer is used to manage the "power-down" mode, the deepest sleep mode with the biggest power savings.

Watchdog timer

The Arduino's watchdog timer is a countdown timer that's driven by its own oscillator on the microcontroller. It's designed to run even when all the other circuitry is powered down, meaning that the microcontroller is drawing as little power as possible without actually being turned off completely.

Why "watchdog" timer? The basic function of a watchdog timer is to "bite" after a certain period, where "biting" means raising an interrupt, re-setting the system, or both. A typical use of a watchdog is to make a system more robust to software failures. Since the watchdog is handled by the microcontroller's hardware, independent of any program being run, it will still bite even if the software gets stuck in an infinite loop (for example). Some designers set the watchdog ahead of complex operations, so that if the operation fails, the system will reset in a short amount of time and end up back in a known-good configuration. At the end of a successful operation, the program disables the watchdog (before it bites) and carries on. Of course this assumes that the operation completes before the watchdog bites, which means the programmer needs to have a good idea of how long it will take.

Setting the time-out period

It's as well to understand how watchdog timers on microcontrollers work. Typically they have a fairly coarse resolution, counting a fixed number of timer ticks before "biting" and performing some function. In the case of the Arduino, the watchdog timer is driven by the internal oscillator running at 128KHz and counts off some multiple of ticks before biting. This value -- the number of ticks counted -- is referred to as the "prescalar" for the timer.

The prescalar is controlled by the values of four bits in the watchdog timer's control register, WDTCSR. To set them up, you pick the value of prescalar you want and set the appropriate bits. If the bits contain a number ( i ), then the watchdog will bite after ( (2048 << i) / 128000 ) seconds. So ( i = 0) means the watchdog bites after 16ms; ( i = 1 ) produces delay of 32ms; and so on up to ( i = 9 ) (the largest value allowed) means the watchdog bites after about 8s.

The word "about" is important here: the oscillator's exact frequency depends on the supply voltage to the chip and some other factors, meaning that you should be conservative about relying on the delay time.

Writing the appropriate value of ( i ) into the control register involves representing ( i ) as a four-digit binary number and then writing these bits into four bits of the register -- and unfortunately these bits aren't consecutive. if ( i = 7 ) for example, then this is 0b0111 in binary, so we write 1 into bits WDP0, WDP1 and WDP2, and 0 into bit WDP3, and 0 into all the other bits:

WDTCSR = (1 << WDP0) | (1 << WDP1) | (1 << WDP2);

The phrases of the form (1 << WDP0) simply takes a binary digit 1 and shifts it left into bit position WDP0. The | symbols logically OR these bits together to generate the final bit mask that is assigned to the control register.

Actually there's a little bit more to it than this, as we can't change the watchdog's configuration arbitrarily. Instead we have to notify the chip that it's configuration is about to be changed, by setting two other bits in the control register and then performing the updates we want:

WDTCSR |= (1 << WDCE) | (1 << WDE);

Setting WDCE enables changes in configuration to be made in the next few processor cycles, i.e. immediately. Setting WDE resets the timer.

Finally we enable the watchdog timer interrupts by setting bit WDIE. When the watchdog timer bites, the microcontroller executes an interrupt handler, re-starts the main program, and clears WDIE. Any further interrupts, if the time is re-enabled, will then cause a system reset.

WDTCSR |= (1 << WDIE);

So the complete code the setting up the watchdog timer to bite in 2s is:

set_sleep_mode(SLEEP_MODE_PWR_DOWN);              // select the watchdog timer mode
MCUSR &= ~(1 << WDRF);                            // reset status flag
WDTCSR |= (1 << WDCE) | (1 << WDE);               // enable configuration changes
WDTCSR = (1 << WDP0) | (1 << WDP1) | (1 << WDP2); // set the prescalar = 7
WDTCSR |= (1 << WDIE);                            // enable interrupt mode
sleep_enable();                                   // enable the sleep mode ready for use
sleep_mode();                                     // trigger the sleep

/* ...time passes ... */

sleep_disable();                                  // prevent further sleeps</pre>

Interrupt handler

What happens when the watchdog bites? It causes an interrupt that has to be handled before the program can continue. The interrupt could be used for all sorts of things, but there's often no point in worrying about it: but it still has to be there, to prevent the microcontroller just resetting. The following code installs a dummy interrupt handler:

ISR( WDT_vect ) {
  /* dummy */
}

The WDT_vect identifies the watchdog timer's interrupt vector.

While this might seem like a waste of time, it's important to have an interrupt handler as the default behaviour of the watchdog timer is to reset the microcontroller, which we want to avoid. It's also worth noting that, once enabled, the watchdog timer will keep biting, so the interrupt handler will be called repeatedly. (Put a print statement in the hander to see.) This doesn't cause any problems.

API communications now working

Simon Dobson — Sat, 06 Jul 2013 11:12:05 GMT

A small sensor network now working, with two edge devices talking to a base station.

This step of the project accomplishes two things: is gets API networking mode working for the XBee radios, and makes sure the the interaction between software on the Arduinos and software running on the base station work too.

The data stream is simple enough: each Arduino counts up from 0 to 255 every 5s, passing the result up to the co-ordinator radio. A Processing program on the laptop collects the numbers and prints them. Naturally they become somewhat intertwined as their clocks aren't quite synchronised.

Actually this is enough to perform a simple radio survey to check transmission distance: we can move the radios away from the base station until they lose contact (nominally 100m for these 2mW radios, in reality probably substantially less), then move back into range, and then move one of the radios again to check that it meshes with the intermediate node in reaching back to the base station. This will also check that battery power works.

The software is quite straightforward, and the xbee-arduino library handles all the low-level communications -- although it's very low-level, fine for the experienced programmer but probably all but mystifying to anyone not used to this kind of software. The corresponding Java xbee-api library is slightly more friendly, but only slightly: they probably both need wrapping into a framework that hides the radio nastiness.

I think the biggest hurdle for this sort of system is the data format -- or, more precisely, the need (or desire, at least) to to use C at one end and Processing/Java at the other, which means that the data on the wire is being described twice. A framework approach could use (for example) JSON, although there'd still be a need to make sure it was compactly encoded and transmitted.