nRF24 walk through – Introduction

The Nordic nRF24 is a family of silicon integrated radio transceivers operating in the 2.4GHz band, the most popular one being the nRF24L01. This is the core element of some extremely cheap module boards available in online stores like eBay, Aliexpress and Banggood.

These boards do not provide WiFi (801.11) or Bluetooth connectivity (both in the 2.5GHz band), but they can be used to establish custom wireless networks between small electronic devices, including Arduino, RaspberryPi and Particle (formerly known as Spark).

Whenever we talk about networks you must take in account a few key aspects of networking, one of the most important being the network topology.

NetworkTopologies.svg

During this series we will aim to establish a star network between a series of Arduino based peripheral nodes and a central hub node, being either a RaspberryPi or a Particle Core/Photon: this represents a basic but invaluable configuration allowing for complex elaborations on remotely collected information, either on premise (RPi) or in the cloud (Particle).

If this series gets enough attention I might invest some more time and extend it to cover more complex topologies like tree and mesh, with the latter being my favorite and, IMHO, most valuable for inexpensive IoT projects.

The project

To keep things simple our peripheral nodes will be only collecting button presses, communicating to the central hub whenever a button gets pressed: the central hub will periodically (once every 30 seconds) print out the amount of button clicks it has received with a breakdown for each node; something like:

Received 14 clicks in the past 1 minute(s)
* 5 click(s) from node A
* 2 click(s) from node B
* 7 click(s) from node F

This will obviously represent just an example of what you will be able to do from the hub node; nothing prevents you, as an example, from pushing data into a database and generating graphs. You could aggregate the data differently or, more likely, collect other types of data from your sensor nodes: I’m not here to place constraints to your imagination!

Keep in mind though, the little radio transceivers we are using have a few limitations that are commonly misunderstood, which will be analyzed when we get there during the project.

The steps

This walk through will be split into the following posts:

14 thoughts on “nRF24 walk through – Introduction

    1. I’m doing this as a tutorial so I’m using nRF24 on purpose. Would I use an ESP8266 for a project like that? Probably, but only if I don’t need to interface with an SPI/I2C sensor, which considerably limits the applications field.

      Like

  1. The nRF24L01+ is much simpler and easier to use than the ESP8266. And the ESP8266 needs a lot of power (up to 300 mA!) while the nRF uses less than 20mA when sending. The ESP8266 is good for a web server (see http://mcuoneclipse.com/2014/11/30/tutorial-web-server-with-the-esp8266-wifi-module/), but not the right thing to send/receive some sensor data (which you do not need to send to the cloud). I’m using the nRF in many low power applications (e.g. http://mcuoneclipse.com/2013/10/28/first-set-of-nrf24l01-wireless-sensor-nodes-with-frdm-kl25z/).

    Like

    1. There a good scenarios for ESP8266 and other for nRF24, that’s for sure. When 802.11 modules were priced at 20$ the main reason for nRF24 was their price. Now the ESP8266 has leveled that: should we really compare the two? I believe they cover two very different areas of the very wide “wireless communication” topic… A comparison probably deserves a proper post than just some comments.

      Like

      1. Yes, there are definitely different use cases for both. The good thing about the nRF24L01+ is that the issues are know, and I consider it as ‘known and stable’. The ESP8266 right now still has a lot of firmware flux. But otherwise the ESP8266 is a great platform for sure!

        Like

      2. I agree!

        From another point of view someone can argue the ESP8622 is an MCU, the nRF24 is not, which is how I interpreted the question in the original comment.

        A lot can be said on those devices 😉

        Like

  2. One thing about the network topologies: the nRF24L01+ pretty much only supports a special star network structure. The problem I have faced with the nRF that there is no broadcast capability: you cannot build up a network without special tricks as you would do with other transceivers.

    Like

    1. The network topology you can implement is not really limited if you are willing to write some networking code. One of the biggest misunderstanding about the nRF24 is the reading pipes address: they represent the addresses you are going to *listen to*.
      If you set an address as broadcast and bind it to a reading pipe on all nodes, whenever you write a packet for that address all nodes in range will receive it.
      So, I don’t exactly agree on what you said…

      Like

      1. Yes, I tried that approach too, but it was very unreliable: that works if you have say only 2-3 nodes in a room. But if you have many more, many of your nodes will not receive the packets as ‘consumed’ be some other nodes. At least this was the case with the nRF24L01+ hardware we used for this. Bottom line was that a reliable discovery was not possible.

        Like

      2. I currently have about 25 nodes using the broadcast system I described, which I would consider reliable enough…
        Since radio packets are just _flushed into the air_ they cannot be really consumed by one or the other receivers, so I believe what you were looking at in your experiment was some of the nodes not being in listening mode while the transmitter was broadcasting.
        The be able to reliably receive packets (broadcast or not) you actually need to use hardware interrupts and the IRQ pin on nRF24 modules. If you rely on MCU _loop()_ cycles anything can prevent you receive a message.
        This might be worth an additional _advanced usage_ post at the end of the series illustrating how to do broadcasting and IRQ signalling, but would be definitely too much to take for starters IMHO.

        Like

Leave a comment