As I’ve started to dig into [FreeRTOS], I have found too few useful compilable examples on how to get started. The FreeRTOS tutorial is complicated and theoretical. It doesn’t leave you with any working running code. The Officially Supported demo for STM32 works, but it’s way too complicated, and assumes you have lots of hardware. Not a great way to get started. Maple comes with a tragically simple freertos-blinky.cpp, but all it does is show you how to blink the LED. What’s next?? Fortunately, I came across a page of FreeRTOS examples for WSN430 that helped a lot.

In this blog post, I wanted to share my own experience with porting real code to FreeRTOS, which does something more useful than blink a light, but not something unfathomably complicated. Along the way, this will explain how to exploit many of the features of FreeRTOS

Get the code from github: https://github.com/maniacbug/FreeRTOS

Warming up: The easy examples

My FreeRTOS port contains four simple examples, which serve as good warmups to understand FreeRTOS. They are best approached in this order:

1. Blinky. The usual suspect… Blinks the LED, FreeRTOS style. Obviously overkill for this simple case, but it should help show what’s going on.
2. Twotasks. Blinks the LED AND prints a message, both on separate timers.
3. Buttonled. Toggles the LED when you press and release a button on Pin 2. Demonstrates one way to handle debouncing.
4. Manybuttons. Prints the state of many buttons when they change state. Demonstrates how to use parameters for a task, using the same task handler for multiple buttons.

RF24 pingpair

My final goal for this post is to port the very simple ‘pingpair’ example from RF24. This is the ‘hello world’ of RF radios, sending a message back and forth between two radios.

Tasks

Let’s start by looking at the tasks. These are the main worker bees of a FreeRTOS application:

• vSendTask: Periodically sends a packet to the other unit
• vReceiveTask: Waits for incoming packets on the payload queue, and prints them out to the Serial. Then prepares an ack packet for the next received packet.
• vStatusTask: Waits for status information on the status queue, and prints them out to the Serial
• vRadioSoftIrqTask: Handles the work of the radio interrupt.

Interrupt Handler

The handling of interrupts is particularly interesting, using a ‘soft irq’ to do the real work. The idea behind this is that the interrupt handler does the absolute minimum possible work in the handler itself. In this case, all it does is wake up the vRadioSoftIrqTask, and return to regular processing. The problem with doing a lot of work in the interrupt handler is that EVERYTHING is put on hold while it executes, without regard to whether there is something more important happening. In the case of RF radio, receiving an incoming packet is important, but there is a 3-packet FIFO buffer, so we can wait a bit before processing them if something more important is happening.

Semaphores

• xRadioIrqSemaphore: This is the mechanism that the radio irq uses to launch the softirq. The vRadioSoftIrqTask simply waits forever on this semaphore, and the radio irq handler simply posts to this semaphone and exits.

Mutexes

Mutexes are used to protect resources where we only want to have one task using them at a time.

• xRadioMutex: All accesses to the radio are protected by this mutex, otherwise a high-priority task could interrupt a lower one who is currently using the radio for something else.
• xConsoleMutex: Ensures that two things don’t write to the serial console at once. Currently, I wait on the mutex. To avoid deadlocks, it may be better to just abort if it’s not free. So far this has not been a problem.

Queues

Queues are how we pass information between tasks. Some tasks generate information, another task consumes it and does something with it.

• xPayloadQueue: When the radio receives a frame, it places it into the Payload Queue. This way the radio’s softirq can be decoupled from the application logic. The radio fills the queue, and the application consumes it to do what it likes.
• xStatusQueue: Status messages are placed into this queue.

Porting Decisions

When porting FreeRTOS, there are a few decisions to be made. These are embodied in FreeRTOSConfig.h

• Memory allocator. I use heap_1.c, which is manages a static heap, and allows allocation only. No memory is ever freed. I think this is appropriate for a microcontroller with 2K SRAM.
• Heap size. 1500 bytes of heap seems to be the practical limit.
• Minimum stack size. 100 bytes of stack per task was the limit I found under experimentation, but 150 was better. Most tasks that do anything will need to be created with a 150+ stack size.

FreeRTOS on Arduino Uno?

FreeRTOS works great on 1284P and Maple. After some heavy experimentation, I was able to get the pingpair sketch working on an Arduino Uno clone. It turns out that a heap of 1300 and per-task stacks of 150 did the job. In total, 380 bytes of SRAM remain free when the sketch is loaded.

The question is whether this is a good idea. This is just a simple ‘hello world’ for radios, 380 bytes doesn’t leave much for more complex application logic or more tasks.

This post follows the Getting Started with nRF24L01+ on Arduino. If the resulting board from that is a little too rough around the edges, it can be built instead on a proper prototype shield for a few more dollars.

Stuff we need

New Parts

The changes from the original Getting Started board are that you need these parts instead of the corresponding parts from that post.

• Bare PCB Arduino ProtoShield $3.00
• Arduino Stackable Header Kit $0.90

Same Parts

You still need these…

• 2.4G Wireless nRF24L01+ Module $4.00
• 2.54mm 2x4Pin Female Header (5Pcs) $1.50
• Solder cable – 7cm (10pcs) $0.50 (Or get some wire at Home Depot and cut it yourself)

Building it

Follow the instructions in the Getting Started with nRF24L01+ on Arduino. The protoshield doesn’t have labels on the grid, so you can use the photos for reference.

Using it

The stackable headers are handy because you can stack another sheild atop it. However, the radio is a little too high for that. You have a couple options:

• Skip the 2×4 header and solder the module directly to the shield.
• Add a second set of stackable headers, so the shield atop this one is up a bit higher still.

The NanodeUIP web server provides a mobile-optimized web page to control and monitor your Ethernet-connected Arduino. All you need is an Arduino and an ENC28J60-based Ethernet shield, or get a Nanode which combines the two together.

The home page shows the three functions the webserver can handle:

• Monitor Buttons
• Control Lights
• Monitor Sensors

Buttons

The ‘Buttons’ page shows the current state, HIGH or LOW, of a pre-defined set of digital input pins. See ‘Configuring’ below for details on how to change which pins are reported and what they’re labeled.

Press the ‘Refresh’ button to update the current state.

Lights

The ‘Lights’ page allows control of a pre-defined set of digital output pins. While they’re called lights, they could really control anything like a motor or camera or anything the Arduino can do.

Sensors

The ‘Sensors’ page shows the current value of a pre-defined set of analog input pins. Press the ‘Refresh’ button to update the current state.

jQuery Mobile

The UI relies on jQuery Mobile for a pretty interface that’s optimized for a mobile phone. All the CSS and JavaScript files are hosted by jQuery, so the Arduino web server just needs to point the browser at the right place to go get them. The extra markup doubles the size of the HTML, but there is still plenty of flash memory to spare.

NanodeUIP

NanodeUIP is an Arduino-compatible library for ENC28J60-based Ethernet hardware, like Nanode and EtherShield. It’s based on uIP, a mature, stable, well-documented TCP/IP stack. The library was originally created by Stephen Early based on Adam Dunkels’ uIP and Guido Socher’s enc28j60 driver. My fork adds numerous examples, including this one.

Getting it

This web server is included in my NanodeUIP fork as an example, see examples/webserver.

Using a Nanode, you can upload this sketch straight away to your unit and all is well. You can watch the boot-up messages in the serial monitor, and this will tell you what IP address it used. Load up that IP address in your browser, touch “Lights”, and toggle the “Red Light” switch. You should see the Nanode LED turning on and off as you do it.

The default buttons are on pins 2,3 and 4. Try connecting those to ground and refreshing the ‘Buttons’. The default sensors are on analog 0 and 1, so likewise try connecting those to ground or VCC and refresh to see the values change.

Using on EtherShield

For an EtherShield, it’s almost as easy. There is a line right at the top of the sketch you’ll want to un-comment. After modification, the first line of code says this:

For a regular EtherShield, with the chip select pin on #10, that is all you need to change. If you’ve got something custom with a special CS pin, change the networking bringup section in setup(). Change the ‘SS’ in this line to the pin you need.

Configuration

The main thing a person needs to change in order to make the web server useful is to describe the pins which need monitoring and control. This is done in the webserver.ino file. Look for the “Pin Descriptions” section.

The first code block lists the human-readable labels of all the pins. What do you want to call them? Each label needs its own line here, because it must individually be placed into program (flash) memory.

The following block defines which digital output pins are controllable through the ‘Lights’ page.

The following block defines which digital input pins are monitored on the ‘Buttons’ page.

The following block defines which analog input pins are monitored on the ‘Sensors’ page.

Finally, the following function is called at startup to set the pins to the right input/output direction, and to register the pins with the CGI handler.

Flash Filesystem

The web server builds a simple file system in program memory (flash), so it can serve those files back out to clients who request them. It is not necessary to modify the files on the flash filesystem under normal use. For more advanced use, it’s interesting to look under the covers. For a good explanation of what’s involved, let’s take a look at the Makefile in the fs directory.

The purpose of the Makefile is to create three files in the root directory. fs.cpp will contain the files themselves, transalated into C arrays so they can be processed by the compiler. files.h lists those files out, so they can be referenced by dir.h which works as a directory listing of files.

The INFILES are the files from disk which will be compiled into the flash filesystem.

The first step is to run xxd on all the input files, turning them into C files. These C files are collected in the xxd directory. They are run through an awk script to put them into program memory.

Next, the files are scanned into a directory structure using another pair of awk scripts. dir.h contains entries for each file, telling us the name of each file, where it’s located in memory, and how large it is.

Finally, all the C files are collapsed into a single CPP file, and copied up to the sketch folder.

Common Gateway Interface (CGI)

CGI is the old-time term for web pages generated by code. This harkens back to a day when it was something new, because people actually hand-wrote HTML pages. Sounds shocking now!

uIP differentiates between three sources of HTML:

• HTML files (served by the httpd_fs file system)
• Server-generated HTML files (also served by the file system, but processed for special commands)
• Scripts (created by the httpd_cgi subsystem)

A file with an .html extention will simply be written straight out to the client when it’s requested.

An .shtml file is an html file with special handling. From an SHTML file, you can include other files, or run scripts.

A script causes one of the registered CGI handlers in httpd_cgi to be called. This is what’s used to generate the dynamic portion of the HTML result, including the current state of pins, and of course selecting which pins to display at all.

Sparkfun sells a nifty little gadget to control your project remotely using nRF24L01+ radios. It’s a small key fob with 5 buttons, which transmits codes when you press each button. Today we’re going to explore how to receive those signals using the RF24 library. This is all thanks to Kirk Mower who sent me these units for Christmas. Thanks, Kirk!

Parts

Connections

Connecting the Sparkfun transceiver unit to an Arduino using a breadboard is easier than with the typical modules. Does that make it worth $20 over $4? You’ll have to decide that. To connect it, we can follow the guidance on my previous post, Getting Started with nRF24L01+ on Arduino. Wiring it this way means we can use all the RF24 examples, which are set up to use these pins by default.

Sketch

This is now an example for the RF24 library, nordic_fob.pde.

Setting up the radio is simply a matter of matching the radio parameters on the receiver with those of the transmitter. We can refer to the device firmware for the transmitter settings.

The payload sent by the transmitter is 4 bytes long. The first is one byte containing the current state of the buttons. The low 5 bits correspond with each button, and the bit is 1 when the button is up and 0 when pressed. Bytes 2 & 3 are a 16-bit sequence number I call the ‘id’. Every time the unit sends a packet, the sequence number is increased by 1. The 4th byte is not used. So this is what our payload looks like:

The main loop simply listens for packets, and dumps out the results, translating the button bits into words so it’s easier to read.

I’ve seen plenty Internet Radio examples out there on various platforms, but none on Arduino. Is 2K memory just too little to stream radio effectively? Thought it was time to find out. Turns out it’s no problem at all. Using uIP on ENC28J60 for networking and VS1053 for playback, a stock ATmega328p-based Arduino can stream Internet Radio no problem with plenty RAM to spare.

The example sketch discussed here is something of a “Hello, world.” of Internet Radio. It starts up, connects to a single hard-coded stream, and plays it forever. This makes it simple! Plug and listen. For this example, I’ll use the stream from www.c895.org, “Seattle’s Hottest Music”

Hardware

The easiest way to combine Arduino and ENC28J60-based Ethernet is the Nanode. Alternately, you could use an Arduino Uno with an inexpensive (non-official) EtherShield. I’ve also hooked this up with my own Custom Arduino board with a Custom ENC28J60-based Ethernet board. It’s all the same. The Nanode is the easiest, though.

For the player, I use the Breakout board for VS1053 MP3 and MIDI available from MDFly.com for $25. They are for sale elsewhere on the web too, so anything that breaks out the primary control lines will do the job.

Total off the shelf cost, $65. $40 for a Nanode, $25 for the player module.

Software

EtherBright Library, based on avr-uip

Get the EtherBright library, and put it in your sketchbook libraries. The key to making this project work was finding a small, memory-efficient TCP/IP stack in software that’s mature and well-tested. For the longest time, I thought such a thing did not exist. Then I found uIP, which is part of the Contiki OS. More importantly, I found the avr-uip port which extracts uIP out of Contiki, and pairs it with the ENC28J60 driver. Even with all of its restrictions and compromises, it was able to download files from the web at 180kbytes/sec with only a 500-byte packet buffer. That’s plenty fast enough to keep up with a 128kbits/sec Icecast stream with plenty of time left over for dealing with network hiccups.

Unfortunately, avr-uip is not packaged to work with the Arduino IDE, so I extracted a few key pieces, and repackaged it as the EtherBright library. From avr-uip, it contains:

• TCP/IP stack (‘uip’ directory)
• ENC28J60 drivers (‘drivers/enc28j60′ and ‘drivers/interfaces’)
• Webclient applet. Basic logic for making HTTP requests and parsing the response. Minor changes from the avr-uip project, to use PROGMEM for string storage and to support the ICY protocol.

VS1053 Library

Get the VS1053 library. For the player, I just followed the code in this thread on the VLSI forum, and cleaned it up a bit into a nice library.

IcyArduino Sketch

Get the IcyArduino sketch, and put it in your sketchbook.

Connections

Hooking up the hardware is easy, especially with Nanode. The VS1053 unit is attached to the secondary connector outside the digital pins. This table details the setup I’ve used here. It is straightforward to modify it for other EtherShield setups. Do be aware that the Nanode uses pin 8 for SPI chip select, so I’m using pin 10 for the VS1033 chip select. Other shields use pin 10 for the Ethernet, so you’d have to hook up the VS1053 to a different pin and change the software.

IcyArduino explained

Now let’s take a tour through IcyArduino.ino.

setup

First, we initialize serial and printf, then print out some information so we know that all is well sofar.

Second, we bring up the three layers of uIP, first the chip driver, then the uIP stack, then the webclient applet. Note that this sketch uses static IP addresses for simplicity.

Finally, once uIP is up, we can finish up by starting the player and connect to our stream.

loop

The loop() is a stock uIP main loop, which is looking for new packets and handing them off to uIP correctly. The one thing I added is some reconnection logic to the arp timer. This fires every 10 seconds, which I thought was a good time to reconnect if we’ve lost the connection. Also, commented out by default, is a troubleshooting mechanism to print uIP statistics. This is a good thing to turn on if things aren’t working right.

callbacks

This section contains the pre-defined callbacks which the webclient applet will use to signal changes.

The datahandler is called by the webclient applet when there is data to handle. This simply passes it off to the driver to be played, plus captures some statistics about the transfer.

The rest of the file simply deals with the start and stop conditions, setting the current status as appropriate and printing status messages.

Nanode For the Win

This project will work fine using a generic Arduino clone of any sort and nearly any ENC28J60-based Ethernet module or shield. But it’s best on Nanode for a few reasons:

• Nanode has a secondary pinout that is much more rational than Arduino. All of the VS1053 wires can plug in neatly and securely into a single 12-pin connector attached to the side of the board.
• Nanode has a its own MAC address. So rather than making up a MAC and hoping it doesn’t conflict with anyone else’s out there, we know we have a proper address.
• Nanode has a LED that doesn’t conflict with SCK, so we can actually use it on a project that relies on SPI. Can’t do that with the stock Arduino LED.

Last weekend, I got a Maple Native board from Leaf Labs. This is a somewhat-Arduino-compatible board running a STM Cortex-M3 processor with 512k flash and 1M of external RAM. I figure it will ease the wait for the Arduino Due.

So my first task is to port RF24, my Driver for nRF24L01(+) 2.4GHz Wireless Transceiver library. This library makes it easy to use dirt-cheap nRF24L01+ modules for radio communication.

It turns out the port was dead simple. So now Maple users can enjoy the benefits of $4 RF Radios.

The Hardware

In the picture above, I re-used the board introduced earlier in my Getting Started with nRF24L01+ on Arduino post. Happily, the pins are in the same order on the Arduino as the Maple, so the same board fits neatly onto the Maple Native, albeit oriented backwards. Then, wires are needed to connect VCC and GND over to the module. All of the other power (red & black) wires on the green board are extraneous on Maple.

The Example

Check out the specific example for Maple, pingpair_maple.

Put the same sketch on two units. On one of the boards, tie pin #10 to ground. On the other, leave it floating. This mechanism identifies one of the units as the sender, and the other as the receiver. Power them both up, and watch the debug spew tell the tale.

As I only have one Maple, I tested it using a Maple and one of my Wireless Sensor Nodes

The Changes

Mainly what was needed was to re-arrange the Arduino-specific header files into their own header, and add some compatibility glue.

rf24_config.h

SPI Configiration

Needed to avoid setting SPI parameters in the Arduino fashion. Fortunately, the defaults for Maple HardwareSPI were correct for this radio, so no SPI configuration was needed whatsoever.

pingpair_maple.pde

The example needed a little tuning:

Sooner or later, the Arduino starts to feel a little claustrophobic. Your sketches start running out of memory, so you need more RAM. You want to talk serial to another peripheral (like an RFID Module) AND watch the action in the Serial Monitor at the same time, so you need more UARTS. You want to use SPI and control a motor and read a few sensors, and pretty soon you’re out of pins, so you need more I/O pins. You’re logging data, and running out of 1k EEPROM fast, so a bit more EEPROM would sure be handy.

The obvious solution to this problem is an Arduino Mega 2560. Oh yeah, this thing is powerful! 54 pins! 4 UARTS! 8k RAM! You add it to your cart, and then realize it’s almost $50.

Now maybe you’re wondering, isn’t there anything in-between that might be a bit less cash? Indeed there is, it’s call the ATmega1284P and today I’m going to explore getting Arduino to run on it, on a breadboard.

Comparison

Here’s a quick breakdown of three chips… The 328P powers the Uno, the 2560P powers the Mega 2560, and the 1284P is the ‘Goldilocks’ chip, nestled right in the middle–EXCEPT for RAM. It has an abundance of RAM (16k!) which is important because RAM is typically the resource you run out of the quickest.

Background Reading

I’m going to build an Arduino ATmega1284P circuit on a breadboard, burn a bootloader, and upload sketches to it, all using the Arduino 1.0 IDE. This will all go better if you have done it once first with a regular ATmega328P. Doing these things on that chip is well-documented, and easy to get support on the forums if something goes wrong.

So first, read up and practice up on a 328P with help from these handy pages on the Arduino Wiki:

• Building Arduino on a Breadboard
• Arduino ISP Tutorial

Building the Circuit

There are three sections to the circuit show above. (Click on the image for a higher-resolution).

• Power/Timing. I’m using a 16MHz crystal and 22pF caps for timing and a 0.1uF cap for power.
• FTDI. I use a Sparkfun FTDI breakout to program everything, so I’ve set this breadboard up with a connector for that mechanism.
• Arduino ISP. To burn the bootloader using Arduino as ISP, six connections are needed from the Arduino. The from/to pins are indicated on the schematic.

For another view, check out this forum thread: Using the 1284p/664p (IDE, bread board and boot loaders)

Get the Software

The Arduino makes it easy to support a new ‘Hardware Platform’. The files you need are hosted on github, the Mighty 1284P Platform for Arduino.

WARNING this ONLY WORKS on Arduino 1.0. It would be possible to back-port to 0022, but seems unneeded now that 1.0 is nearing final release.

To install it…

1. Download the ZIP File
2. Unzip it a folder called ‘hardware’ off your sketches directory, e.g. /Users/maniacbug/Source/Arduino/hardware/mighty-1284p
3. Restart the IDE
4. Select Tools > Boards > Mighty 1284P

Burn a Bootloader

Once you have the Mighty 1284P platform set up, burning a bootloader is trivial. Follow the Arduino ISP instructions. You first burn the “Arduino ISP” sketch onto a regular Ardunio. Then change the “Boards” setting to the Mighty 1284P, hook up the ‘Arduino’ connections in the schematic above, choose “Tools > Programmer > Arduino as ISP” from the IDE, and then “Tools > Burn bootloader.”

To verify that it worked, move the LED to pin 1, and power cycle the breadboard. When the bootloader starts it flashes pin 1.

Upload a Sketch

Uploading a sketch is trivial now that the platform is set up and bootloader is in place. Try the ‘Blink’ example first, but change the LED pin to ’1′ in the sketch. (Of course, move the LED back to the right pin, which is pin 2 on the MCU).

Understanding Pin Mappings

When you refer to a “pin” in the Arduino environment, e.g. “digitalWrite(13,HIGH)”, the system maps that pin onto a MCU pin. There is definitely no standard pin mapping for 1284P, many people have published their own. I chose a mapping that makes sense for the breadboard, where the digital pins start at MCU pin 1, and simply go around the chip counter-clockwise.

Alternatives

There are a handful of folks who have built a fully-functional board with 1284P. These are all worth checking out to see if one meets your needs. Still, I think there is a gap to be filled for a cheap 1284P-based Arduino with minimal add-ons.

• Sanguino. The classic. Uses ATmega644 which is real close to the 1284, but the core is not maintained beyond Arduino 0017.
• Bobuino. Capable, fully-featured board, with SD, RTC, USB, and more. You pay $80 for all those features–which is great if you need it all, but it’s too expensive if you just need a bit more power for your projects.  In my view, you might as well get a Mega 2560.  My other complaint is the lack of coherent software distribution. The (hidden) directions expect users to cobble together a system from various places, and then includes a (hidden) package of files which is not under source control. And worse, no source for the bootloader.
• Brewtroller Sanguino1284P.zip. Looks like the most complete distribution. Not ported to 1.0 yet. Uses the backwards analog pin mappings from avr-developers. Designed for specialized use (brewing control).
• Calunium Photos on Github. Ported to 1.0. Uses a rather custom pin arrangement. No bootloader. Still, looks like the best bet overall.
• BahBots Controller. See Setting up support for the BahBots controller in Arduino. I couldn’t find the bootloader, it runs at 20MHz (I want 16MHz). Again, requires you to cobble together a core using the avr-developers core.

Nordic’s nRF24L01+ 2.4GHz RF radios are a great way to communicate wirelessly between Arduino’s. They’re cheap, and powerful. Unfortunately, they can be a little daunting to beginners to get started. Today, I want to make it easy for total beginners to get up and running on nRF24L01+ radios quickly and easily.

Stuff we need

First, we have to go shopping. A great place to start is the iTeadStudio store. Here’s what you need. Obviously, you’ll want to buy two of the radios and protoboards because what good is a radio that can only talk to itself?

• 2.4G Wireless nRF24L01+ Module $4.00
• 2.54mm 2x4Pin Female Header (5Pcs) $1.50
• 2.54mm 40Pin Male Header (5 Psc) $1.50
• Double Side ProtoBoard 5cm * 7cm $0.99
• Solder cable – 7cm (10pcs) $0.50 (Or get some wire at Home Depot and cut it yourself)

Reasonable substitutes for this stuff can also be found at Sparkfun if you like spending a lot more money. Also the radios are at MDfly.com.

Preparation

We only need one of the 2×4 pin female headers. Cut off two chunks of the male headers, lengths of 6 and 8 pins. Cut wires to about 2inches in length. If you use the 7cm wires from iTeadStudio, it’s OK, you’ll just have a little extra wire in the way.

Here’s what it looks like all ready to go. Click on the picture for a closer view. In this picture, I am using a pair of 4-pin female headers instead of a 2×4 female header. I also cut an extra green wire I decided not to use in this tutorial.

Solder it up

• The 8-pin male header goes in position C09-16.
• The 6-pin male header goes in position V13-18.
• The 2×4-pin male header goes in position K16-N15.
• The wires are connected as follows:

Here’s what it looks like with all the wires in place, up close and personal. Again, click through for even bigger images.

Software

Get the RF24 library from github. There is ample documentation at that link, as well as a pointer to the downloads page. Unzip the archive in to your ‘libraries’ folder under your sketch folder (mine is in /home/users/maniacbug/Source/Arduino/libraries), and restart the Arduino IDE.

From the File menu, select “Examples”, then “RF24″, and finally “GettingStarted”. This will load up the GettingStarted example. It looks something like this. Take a look at the GettingStarted example in the documentation for all the details.

Upload the sketch, start the serial monitor, set the speed to 57600, and you should see this:

Instead, if you see a lot of zeroes everywhere, something is wrong with your connections. Double check them all again! In the course of making this tutorial, I even switched two of the wires myself and had to re-solder them. If you hooked everything else up right, you will see numbers just like those above.

Make another one

Ok, do it all again, making another protoboard shield, on top of another Arduino, so our first unit has something to talk to.

Start the second unit up, just like above, and launch the serial monitor at 57600. Press the ‘T’ key once the debugging text has printed successfully. That will put this unit into Transmit mode, which sends a ping out to the other unit. Make sure the other unit is still running, so this one has something to talk to!

Soon you will see the happy chatter of the radios doing their thing:

From here…

The examples directory in the RF24 library has all sorts of different things you can try. If you’re feeling adventurous, you can even hook up the IRQ pin from pin 8 on the radio to pin 2 on the Arduino (that was what the extra green wire was for in my ‘parts’ picture).

Instead of the ghetto-style ProtoBoard setup, you could step it up a notch and use a Arduino ProtoShield Kit. See the more recent post, Getting Started with nRF24L01+ using a Protoshield

In a future post, I’ll put up a simple PCB you could use instead of all the soldering. It’ll be a little smaller, too.

My goal today is to create a sensor node which can be used in a wireless sensor network, to capture environmental information and send it back to the base. My main goals are for the nodes to: Be cheap, and last for a year.

How cheap and how low-power can we go? In the end, I got down under $12 for a very capable Arduino-compatible node with a 2.4GHz radio running ~2.6V that should last a year and a half on 2 AA’s, or 5 months on a coin cell.

Adventures in Low Power

Previously, I ran a small test network of these nodes using 3.3V regulated power. After doing that, I realized it’s possible to run on even less power and with an even cheaper BOM by ditching the regulator entirely. Two AA cells will range from 2.4 to 2.9V. An Atmega328P MCU and the nRF24L01+ radio will both operate just fine in that range.

To enable this, I needed to create a new ‘board’ in the Arduino IDE. This board has two changes from the stock Duemilanove:

• Set the correct fuses for the ‘Brown-Out Detector’ (BOD). The Arduino IDE as-shipped sets the BOD to 2.7V, so the chip won’t even power up with 2x AA’s.
• Run the chip at 8MHz clock rate. That is exactly the edge of the specified clock rate curve for 2.4V, the low end of my voltage range.

Here’s what my entry to the boards.txt file looks like exactly:

Power Experimentation

Now it’s time to measure and estimate power. Our usage pattern will be the MCU and radio powered down as low as they can go most of the time. Then they wake once every minute or two, transmit, and then go back to sleep.

These are the specific questions I needed to answer, so I ran experiments for each:

• How much power is consumed when sleeping?
• How much power is consumed when awake and transmitting?
• How long will it be sleeping each cycle?
• How long will it be awake each cycle?
• How much capacity is really available from the batteries?

Current Consumption

To measure current, we need a multimeter capable of doing so. I use a Extech EX330 Autoranging Mini Multimeter, but many cheaper meters have current-measuring features. Look for an “mA” setting. The methodology here is to insert the multimeter inline into the circuit at the point we want to know the current flow. That is, the current flows THROUGH the meter on its way from the battery to the load. To keep things simple, it’s a good idea to use the actual battery being tested as the current source, rather than some external bench power.

There are two current measurements needed here, one while sleeping and the other while operating. So I created simple test sketches that did each. One just puts everything to sleep (MCU and radio), the other transmits constantly to a working receiver. Simply measure the current from the meter during both tests.

Actually for the ‘transmitting’ test, I am using the “endless sending” test. This is consuming 13.57mA reliably.

For ‘sleeping’, I am getting strange results. With the radio removed, and the voltage measurement circuit removed, the meter still reports 395 uA. But on mA mode, it reports 0.14mA. Argh! Also, adding the radio in doesn’t seem to matter much. Adding back in the voltage measurement, I hover up at 410 uA.

Duration / Duty Cycle

How long between wake-ups is defined by the application. For now, I am waking once a minute, but that is likely much more frequently than needed to effectively measure temperature.

To measure how long it stays awake, I used the same “endless sending” test as for capacity. I have the system endlessly send readings without actually ever sleeping. Every 30 seconds, the receiver posts a reading to the database. By counting the number of readings elapsed between each saved reading, I can see how long it takes to measure and send a reading. In my tests, there were reliably 1128 readings every 30 seconds, for an awake duration of 27ms.

Capacity

The one true test for this is to take a fully-charged battery, and burn it to the ground. Because consumption varies with current draw, it’s important to run the test at the correct amount of draw. It seemed like the logical choice was to use the ‘constant transmitting’ sketch which I used above to measure draw, and leave it on as long as it takes. Two AA batteries lasted over a week! So 156 hours @ 13.57mA tells us these ’2300mAh’ batteries actually gave about 2110mAh.

Just for fun, I had the sender transmit its voltage level, so I could graph the progress.

In the end, I decided to go with a 3V coin cell battery, CR2450, rated at 540mAh. This is a big trade-off. With the coin cell, the units are much smaller and easier to place. They are also a few dollars cheaper. But I’ll only get 5 months, and the batteries are not rechargeable.

Power Calculations

Armed with these results, we can estimate how long the node will really last. I have a handy spreadsheet I use for these calculations. The results for this test are pasted below, but the same calculations can work for anything sleep/wake setup. we plug in the answers to the five questions above, and out comes the answer we want to know: How long will it operate?

This file is available on Box.net: Power Calculations.ods CC BY-NC-SA

Sensors

What shall we measure, and how?

Temperature

The “hello world” of wireless sensor networks is temperature. I figure it’s always interesting to know what the temperature is, so now I can find out what the temperature is in 25 unique points within the house My weapon of choice is a Microchip MCP9700. There are many options. This one seemed simple and cheap.

To drive it, I created a simple MCP9700 library. It supports both the ’00 and ’01 variants, maintains a calibrated error value, and handles the average of multiple readings. Soon to be available on github!

Battery Voltage

It’s useful to know the battery voltage, from which we can infer the remaining battery capacity. So the nodes collect and transmit their battery voltage with every sample.

These nodes use the internal 1.1V reference voltage, so the battery voltage has to be divided down before it can be sampled. For this, I use a simple voltage divider circuit with 1M and 470k resistors. The resistors are chosen to have very high impedance so they don’t draw a ton of current. As a consequence, a capacitor is needed. (Not sure why exactly, but it was suggested on the Arduino forum, and definitely solved the problem of poor readings.)

Here is a very simple schematic of the voltage divider at work:

Others to Come

To future-proof this node just a little, I included an expansion port. This exposes 4 unused pins (2 digital, 2 analog) and the SPI bus. It will allow me to add additional sensors in the future without having to re-spin the board. For details, see my post on the Arduino Box Header Platform; this is “Port B”.

Software

These nodes are running my RF24Network stack. Built on my RF24 radio driver, the network layer provides node addressing and routing to build a tree topology out of the nRF24L01+ radios.

The temperature reading & sending code on the client is really simple. It is also using my MCP9700 library for the temp sensor and my Sleep library for putting the node to sleep and waking at the right interval.

The receiving node and SQL storage infrastructure will be the topics of future blog posts.

Bill of Materials

Pricing for all of these parts is in quantity 25, which is about how many I want to have operating at once. All part ##’s are from Mouser.

The radio unit is from iTeadStudio, 2.4G Wireless nRF24L01+ Module for $4.00.

Cost breakdown:BOM $6.69, Radio $4, Board $1, Total $11.69

Schematic

Eagle file is on box.net: RF Duinode V3.sch CC BY-NC-SA

Circuit Board

Eagle file is on box.net: RF Duinode V3.brd CC BY-NC-SA

Parts

I picked these up with my last iTeadStudio order to experiment with:

• 125Khz RFID module RDM630 – UART $11.00
• EM4100 125khz RFID Key Tag $0.50

Connections

Connecting to the Arduino is brain-dead simple. Note that I am not connecting the module to the Arduino’s RX/TX pins, because I want to leave that open for the Serial Monitor.

Reading the ID

My approach in software is to use the SoftwareSerial library. The advantage is that the hardware serial (UART) is free for communication with the host PC. The disadvantage is that the software serial is a lot more finicky.

Fortunately, the module holds the LED pin low while sending data. So what I’ve done is connected that pin to Arduino pin #2, and then I wait for an falling edge on interrupt 0. Once I have that, I know to expect exactly 14 bytes at 9600 baud from the module’s TX pin.

For convenience, I also put this code up as a gist: rfid_simple.pde.

Processing the ID

The data from the tag needs to be processed a bit in order to be useful. Running the rfid_simple sketch above, and swiping the key I have, gives this result:

The key says “0010439008″ on it, hardly the same. What we have to do is convert the characters to bytes, and take only the middle 4 bytes. That will yield 0x009F4960, which is exactly 10439008. Yay. The first byte appears to be garbage, and the last byte is a checksum.

We can use the checksum to make sure everything came across the wire properly. We can simply XOR each of the 5 bytes together, and compare with the checksum byte, e.g. ( ( ( ( 0x3D ^ 0×00) ^ 0x9F) ^ 0×49) ^ 0×60) == 0x8B.

So the final version of the RFID reader will read in the garbage byte at the start, and read in the checksum, calculate a checksum, and compare the two. I needed to put the chars-to-byte conversion into its own function because it’s used in different places now.

Below are the changes from the above version. The code for this one is also up as a gist: rfid_decimal.pde