RF24Network for Wireless Sensor Networking

RF24Network is a network layer for Nordic nRF24L01+ radios running on Arduino-compatible hardware. It’s goal is to have an alternative to Xbee radios for communication between Arduino units. It provides a host address space and message routing for up to 6,000 nodes. The layer forms the background of a capable and scalable Wireless Sensor Network system. At the same time, it makes communication between even two nodes very simple.

Today, I managed to get 17 nodes running on a single network. Now I need to build some more nodes, because the system worked great with 17, and could likely handle thousands of nodes.

Hardware

The fastest way to get RF24Network-compatible hardware is to build the Getting Started board, or the ProtoShield board as explained in other posts, attached to commercially-available Arduino. These are used for nodes 03 and 043 in the picture above.

Ultimately, I wanted something smaller, cheaper and more power-efficient, so I built a Low Power Wireless Sensor Node. That blog post covers the V3 version of that unit, which is used by nodes 04, 011, and 021. Nodes 01 and 02 use an earlier revision, and the rest use a later version. Building them, I was surprised how almost all of them were built slightly differently. It took a ton of experimentation to figure out physically how best to package these. In the end, Node 031 is the winner, so for the upcoming V5 iteration, I’ll build 10 nodes using the PCB-mounted 2AA battery holder.

Simple Transmit/Receive

The Hello World examples illustrate how simple it is to communicate between two nodes. The receive example goes on one node, and the transmit example on the other.

There are three simple sections:

Static Initialization

First, the static setup to prepare the radio, and set the addresses. In this case, we consider ourself “Node #1”, and will communicate with “Node #0”. Of course, it’s important to get the pins right. To use the boards from the Getting Started example, you’d use pins 9 & 10.

// nRF24L01(+) radio attached using Getting Started board
RF24 radio(9,10);
 
// Network uses that radio
RF24Network network(radio);
 
// Address of our node
const uint16_t this_node = 1;
 
// Address of the other node
const uint16_t other_node = 0;
 
// How often to send 'hello world to the other unit
const unsigned long interval = 2000; //ms
 
// When did we last send?
unsigned long last_sent;
 
// How many have we sent already
unsigned long packets_sent;
 
// Structure of our payload
struct payload_t
{
  unsigned long ms;
  unsigned long counter;
};


setup()

Second, the ‘setup()’ simply prints out a quick salutation, and initializes the radio layers.

void setup(void)
{
  Serial.begin(57600);
  Serial.println("RF24Network/examples/helloworld_tx/");
 
  SPI.begin();
  radio.begin();
  network.begin(/*channel*/ 90, /*node address*/ this_node);
}


Transmitter loop()

Finally, the ‘loop()’ regularly sends a message to the other unit. Note that RF24Network requires a regular call to “update()” to process packets from the radio. It’s best to avoid calling delay() anywhere in a sketch that uses this system.

void loop(void)
{
  // Pump the network regularly
  network.update();
 
  // If it's time to send a message, send it!
  unsigned long now = millis();
  if ( now - last_sent >= interval  )
  {
    last_sent = now;
 
    Serial.print("Sending...");
    payload_t payload = { millis(), packets_sent++ };
    RF24NetworkHeader header(/*to node*/ other_node);
    bool ok = network.write(header,&payload,sizeof(payload));
    if (ok)
      Serial.println("ok.");
    else
      Serial.println("failed.");
  }
}


Receiver loop()

Also, we can look at the receiver example, which is equivalent to the transmitter sketch, with the difference of the loop(). It keeps a look out for packets, pulls them off the radio, and prints them to the console.

void loop(void)
{
  // Pump the network regularly
  network.update();
 
  // Is there anything ready for us?
  while ( network.available() )
  {
    // If so, grab it and print it out
    RF24NetworkHeader header;
    payload_t payload;
    network.read(header,&payload,sizeof(payload));
    Serial.print("Received packet #");
    Serial.print(payload.counter);
    Serial.print(" at ");
    Serial.println(payload.ms);
  }
}


Addressing in Detail

RF24Network works great with a few nodes, but it was designed for a house-full of nodes. Nodes are automatically configured in a tree topology, according to their node address. Nodes can only directly communicate with their parent and their children. The network will automatically send messages to the right place.

Node 00 is the ‘base’ node. Nodes 01-05 directly communicate with Node 00, but not with each other. So for Node 01 to send a message to Node 02, it will travel through Node 00. Nodes 011, 021, 031 and so on are children of Node 01. So for Node 011 to send to 02, it will send to 01, then to 00, then to 02. Therefore, if you put a Node 011 on your network, be sure that there is a Node 01 on the network, and it’s powered up, and it’s in range!

In practice, I’ve gotten in the habit of designating a ‘router’ node numbered 01-05 on each floor, using a high-power antenna, and connected to wall power. Then all the nodes on that floor communicate with the ‘floor parent’. The picture above is a standard V3 node with a special ‘power pack’ added on to let it plug into the wall, and a radio unit with an amplified antenna.

Building a Wireless Sensor Network

The ‘sensornet’ example is the place to start from when building out a network of sensors. This example demonstrates how to send a pair of sensor readings back to the base from any number of nodes. The readings are a temperature sensor connected to Analog input 2, and a voltage sensor connected to Analog input 3. Every node will send a ping to the base every 4 seconds, which is a good interval for testing, while in practice you’ll want a much longer interval. Leaf nodes will sleep in between transmissions to conserve battery life.

The base simply dumps the ping to the console, and tracks the packet loss. This way we can monitor the health of the network while testing it. In a real application, you’d want to store or transmit those values somewhere, for example up to Pachube.

Payload Details

RF24Network sends two pieces of information out on the wire in each frame, a header and a message. The header is defined by the library, and used to route frames to the correct place, and provide standard information. This is defined in RF24Network.h.

/**
* Header which is sent with each message
*
* The frame put over the air consists of this header and a message
*/
struct RF24NetworkHeader
{
  uint16_t from_node; /**< Logical address where the message was generated */
  uint16_t to_node; /**< Logical address where the message is going */
  uint16_t id; /**< Sequential message ID, incremented every message */
  unsigned char type; /**< Type of the packet.  0-127 are user-defined types, 128-255 are reserved for system */
  unsigned char reserved; /**< Reserved for future use */
 
...


The message is application-defined, and the header keeps track of the TYPE of message using a single character. So your application can have different types of messages to transmit different kinds of information. For the sensornet example, we’ll use only a type ‘S’ message, meaning “Sensor Data”.

This message is defined in the example, in S_message.h:

/**
* Sensor message (type 'S')
*/
 
struct S_message
{
  uint16_t temp_reading;
  uint16_t voltage_reading;
  S_message(void): temp_reading(0), voltage_reading(0), counter(next_counter++) {}
  char* toString(void);
};


This simply contains a temperature and voltage reading. These values are 8.8-bit “fixed point” values, which is to say that the high byte is the decimal part and the low byte is the fractional part. For example, 3.5V is represented as 0x380. Also included is a method to convert it to a string for easy printing.

Voltage Sensor

I like to monitor the battery level of each node, so I can see when it’s time to track one down and replace its batteries. To do so, I connect the VIN from my power source, to the ‘voltage sensor’ input, via a voltage divider:

I use a 1M/470k divider circuit, which will reduce 3.44V down to 1.1V, and then use the 1.1V internal voltage reference. This is perfect for my uses because I don’t use voltages over 3.44V. Of course, if you do, you’ll want a larger divider. In my case, when analogRead(A3) returns 1024, I have 3.44V. In the sensornet example it works like this:

// What voltage is a reading of 1023?
const unsigned voltage_reference = 5 * 256; // 5.0V
// How many measurements to take.  64*1024 = 65536, so 64 is the max we can fit in a uint16_t.
const int num_measurements = 64;
...
    // Take the voltage reading
    i = num_measurements;
    reading = 0;
    while(i--)
      reading += analogRead(voltage_pin);
 
    // Convert the voltage reading to volts*256
    message.voltage_reading = ( reading * voltage_reference ) >> 16;


First, I take 64 readings, to get a good sample size. The other advantage to 64 readings is that it uses the full 16-bits of a uint16_t, so a value of 0x8000 is half of the max 1.1V. Next, I multiply it by the voltage reference. That reference considers the voltage divider I have in place, telling me what voltage I ‘really‘ have on the battery if I get an 0xFFFF reading. In the case of the example, it’s 0x500, or 5V. Finally, I shift it down so the decimal point is in the correct place for an 8.8 fixed point value.

Temperature Sensor

The sensornet example uses the MCP9700 temperature sensor, which is my sensor of choice. You could change it to anything you like, just be sure to modify the calculations accordingly. The way the MCP9700 works is it emits 0.5V at 0 Celsius and increases 0.01V every 1 Celsius above that. Perfect for the 1.1V internal analog reference. Here’s how its used in the example:

    // Take the temp reading
    i = num_measurements;
    uint32_t reading = 0;
    while(i--)
      reading += analogRead(temp_pin);
 
    // Convert the voltage reading to celsius*256
    // This is the formula for MCP9700.
    // V = reading * 1.1
    // C = ( V - 1/2 ) * 100
     message.temp_reading = ( ( ( reading * 0x120 ) - 0x800000 ) * 0x64 ) >> 16;


Same as above, I first take 64 samples to get a reading in the range of 0x0000-0xFFFF. Then convert it using these steps:

• Multiply by 0x120, which is 1.1 in 8.8-fixed point. This converts the reading into volts, and increases the decimal place by 8 bits.
• Subtract 0x800000, which is 0.5, because the decimal point is way out at 24 bits.
• Multiply by 0x64 which is 100
• Shift right 16, which reduces the decimal point from 24 bits to 8 bits which is where we need it.

All of this is done in a 32-bit integer so there are plenty of bits to do this calculation.

Deploying

Put the sketch on every node. Start it first while connected to the serial port, so you can give it an address:

RF24network/examples/sensornet/
PLATFORM: Getting Started Board
VERSION: 013b4d3
*** No valid address found. Send node address via serial of the form 011<cr>


Once you get a bunch of them going, you’ll see the whole spew:

1733003: APP Received #16 24.23C / 3.21V from 053
1733709: APP Received #37 23.82C / 2.70V from 043
1734297: APP Received #109 24.46C / 3.06V from 013
1735108: APP Received #55 25.16C / 3.06V from 033
1735224: APP Received #134 22.66C / 2.71V from 031
1735286: APP Received #287 25.10C / 3.24V from 01
1735565: APP Received #299 24.79C / 3.36V from 03
1736871: APP Received #71 25.78C / 3.07V from 023
1737094: APP Received #137 22.89C / 3.01V from 041
1737119: APP Received #120 23.69C / 2.98V from 011
1737247: APP Received #17 24.23C / 3.21V from 053
1738025: APP Received #38 23.82C / 2.70V from 043
1738361: APP Received #110 24.45C / 3.06V from 013
1739286: APP Received #288 25.11C / 3.24V from 01
1739404: APP Received #56 25.16C / 3.06V from 033
1739565: APP Received #300 24.78C / 3.36V from 03
1739574: APP Received #135 22.68C / 2.71V from 031
1741043: APP Received #72 25.77C / 3.07V from 023
1741213: APP Received #138 22.87C / 3.01V from 041
1741490: APP Received #121 23.68C / 2.98V from 011
1741492: APP Received #18 24.21C / 3.21V from 053


Setting the sleep interval

Once it’s up and running, you can change the sleep interval to something more rational. For production networks, I shoot for one reading from each node every minute, which is probably overkill but it gives me some flexibility because sometimes nodes have trouble reaching the base for several minutes at a time. These are the values to adjust:

// Sleep constants.  In this example, the watchdog timer wakes up
// every 4s, and every single wakeup we power up the radio and send
// a reading.  In real use, these numbers which be much higher.
// Try wdt_8s and 7 cycles for one reading per minute.> 1
const wdt_prescalar_e wdt_prescalar = wdt_4s;
const int sleep_cycles_per_transmission = 1;


Next Steps

The sensornet example can get a large number of sensor nodes up and running. But then what do you do with the data? Probably, you want to transmit or store them somewhere. That will be the topic of a future post.

• ‘Posting to Pachube‘. Combined with NanodeUIP, we can post sensor readings to Pachube from all thousand-some nodes connected. (Or at least 17 for starters :))
• ‘PC application to monitor the network‘. The serial port is quite a cacophony of node information. I am also working on a C# WPF application to give an overall view of how the network is doing. It’s quite nice, so when it’s done I’ll put that up too.
• ‘My Personal Pachube Lite‘. Pachube is awesome, but there are times I may want to just capture the readings on my own database. It will do less than Pachube, but I can do whatever I want with the data. I’ve written my own solution using PHP and MySQL, but it’s not exactly easy for someone else to replicate. My latest idea is to build a server using Ruby on Rails which looks ideally suited for the purpose.