It’s now time to physically build the sensor devices part of the nRF24 sensor network we are planning to build, so move to your electronics bench and pick some breadboards!
From an electronics point of view each sensor node consists of:
- 1 Arduino (any low-end model will do, I will be using two nano and one pro micro as this is what I have at hand)
- 1 push button
- 1 nRF24L01P module
- 1 1-100uF capacitor rated for 5V or more (usually, but not necessarily, electrolytic – any value in the range will do)
- 1 voltage source for 3.3V capable to deliver at least 20mA; viable options include:
3V3pin of your Arduino board (available only on my two nano)
- a voltage divider made by two resistors (I will use 100Ω and 220Ω allowing 50mA to pass through)
WARNING While the module I/O pins are 5V tolerant (which makes this module compatible with practically every microcontroller), the module requires a 3.3V power source.
For absolutely no reason you should power the nRF24L01 module from a 5V source, unless you want to permanently damage your radio transceiver!
Please note I’m compromising here to keep things simple as the 3.3V source is definitely non optimal if you want to save on power consumption: for battery powered sensors you should be using 3.3V Arduinos, like the 8MHz pro mini, or an efficient voltage regulator like the AMS1117-3.3.
To keep the bill of materials at it’s bare minimum I’ll use the Arduino internal pull-up feature: this eliminates one resistor, but implies that pin
3 (the one attached to the button along with
GND) will be
HIGH when not pressed and turns
LOW when pressed, just keep this in mind when we’ll start developing the sensors’ firmware.
NOTE These modules are quite sensitive to power line fluctuations and it should not be surprising considering they are radio transceivers operating in the 2.4GHz frequency: when transmitting data they require short but intense energy bursts to generate the electromagnetic field carrying the data. The capacitor we are adding should be as close as possible to the module in order to provide a local source of energy and avoid power fluctuations: it’s not an optional component!
I will build 3 of those using, more or less, the following wiring:
If you wonder where I found the nRF24L01 Fritzing part, the answer is I made one myself (you can get it here).
Believe it or not, this is how these drawings turned into reality on my desk:
Now, the important thing to remember when wiring the modules, is they use a Serial Peripheral Interface, also known as
SPI. What that means? Well, whatever board you are using to communicate to your modules, you need to identify the pins associated with the
SCK functions. Luckily for us their location is pretty well documented for Arduino and Arduino-like boards.
The modules use two additional I/O pins, called
CSN, but they are configurable so you can pick your own: I went for pins
10 respectively. Bear in mind though, if you’ll ever decide to change those pins, you will have to change the software accordingly.
NOTE Most microcontrollers have one single
SPIinterface, this doesn’t mean you can have only one
SPIdevice attached though! Most
SPIdevices, including nRF24, have a
CSN(Chip Select Not) pin which instructs the device to temporarily ignore
SPIcommunication, thus allowing for communicating with other
Now that you have your sensor boards ready, let’s move onto the software part.
You might want to use the Arduino IDE or, as I will, a more advanced solution like the Eclipse Arduino Plugin, an open source project I’m proud to contribute whenever I get the opportunity to. In case you decide to go for the Eclipse based solution, please follow the website instructions as not every configuration is supported.
I will use a few open source libraries trying to reduce the code to the real interesting parts:
- the RF24 from TMRh20 library is a fork of the original library from Maniacbug, who is no longer active
- my MicroDebug library, which I’ll use to provide some development feedback on serial console
Before getting your hands dirty though, it’s preferable to check your wiring with a known working firmware.
Among the many examples available in the RF24 library, the one I will use is
RF24/examples/pingpair_ack.ino: this Arduino sketch is pretty simple and provides enough info to verify your setup.
There are just a couple of changes I’m going to make, to adapt to the above wiring, and I’ve marked them with comments in this Gist:
- the pins used as
10, so line 24 has been changed from
RF24 radio(9,10)in order to reflect that
- there’s no need to run the serial connection at
57600bps, so I slowed it down to
9600bpsin line 41
- one of my boards uses the
ATmega 32u4chip (Leonardo and Micro use it), which means a board reset does not reset the serial connection; I need to wait for serial connection in the
setup()function to be able to check the module config, this required the addition of line 43
Once the changes are in place, upload the sketch onto the first sensor board and connect using the serial terminal. Don’t worry if you don’t see anything printed out, the addition of line 43 requires you to send something to unlock the setup phase.
As soon as you send a character, you should see the following appear onto your screen:
As you can see the
radio.printDetails() function call at line 59 provides tons of information: most will be blank (
0xff) in case your module has not been setup correctly (99.9% as a consequence of bad wiring or false connections). If everything is setup correctly, you should see the addresses used at line 27 printed in the serial console.
Once you have verified the first module, leave it powered and move on to another one, but this time we will go a step further verifying the two modules are actually talking each other: if the second module reports a correct configuration send the character
T on the serial and watch the two talking each other.
IMPORTANT When moving to verify the next board you must ensure to remove power to one of the other two, because this sketch uses and forces a linear network topology of two elements only: if you try to power up another one you will be unable to distinguish who is replying to whom.
In the next article we will look at the sensors’ firmware and how we can wireless notify the hub about the sensor’s button state change.