Wednesday

RF24Mesh - Dynamic Mesh Networking for NRF24L01+ Radio Modules
An Overview of Progress so Far


Overview:

RF24Mesh is a C++/Arduino/Linux/Raspberry Pi library allowing many devices to simultaneously connect wirelessly and remain connected in a mesh style network using nrf24l01+ radio modules. Nodes can communicate with any other node on the network, including a master node that acts as a gateway for the mesh, providing addressing and lookups.

Once assigned a unique ID, everything is automated, and nodes can move around and rejoin the mesh at any point where another node is in range. RF24Mesh supports some of the smallest and most power efficient devices available.

The RF24 Communication Stack is based on the OSI model, and RF24Mesh makes use of the features of the lower layers (RF24 (Layer 2) , RF24Network (Layer 3), and the overall capabilities can be extended via RF24Ethernet (Layers 4&5 TCP/IP)

Setting it Up:

The main thing when setting up a mesh network is to configure and test your devices accordingly, to make sure they are in a fully operational state. Most if not all of the available radio chips being sold are clones, so I've found it necessary to modify the radio devices slightly in some cases. In many cases, a capacitor (10-100uF) is added directly to the VCC/GND of the module itself to help with common power supply issues.

In the case of these modules, I've found that scraping down the last bit of the antenna, and soldering on a small 3-4" piece of wire greatly improves their performance:
In the case of the high powered PA + LNA modules, I've found it necessary to add shielding as in the post found here. Placing them close to a ground plane seems to help as well. Operating them at a lower power level may be required if the power supply is not adequate.


The modules that are low powered with an antenna generally work out of the box.

I generally recommend using an adapter, to provide a stable power source, even for the low powered modules. I've been using them with many of my modules.

From there it is a matter of installing the Arduino libraries etc. which is covered in the documentation and in earlier blog posts and the official documentation below.

How it works:

RF24Mesh leverages the features provided in the supporting libraries, RF24 and RF24Network to provide connectivity between many devices, even if they are far away from the central node or moving around. Each node is assigned a unique identifier (1-255) and uses that high level-address to request a dynamic address at the network layer, according to the structure of the mesh and proximity to other devices in the mesh. Nodes typically communicate using the RF24Network API, with RF24Mesh working at a higher layer to provide address lookups, dynamic addressing and connectivity.

Nodes arrange themselves using a tree topology around the master node, which provides address lookups etc. for the mesh. At any given time, each node has a path of communication through the network, and can re-establish and verify a new link if the current path fails. In each network there is the master node (the base node), children of the master node (relay nodes) with children nodes themselves, and leaf nodes, (children of the master or its children) with no child nodes attached.

The protocol is fairly simple for each node. On power up or reset, nodes attempt to find a connection by using multicast. Multicasting is arranged into 5 levels, so the master node is contacted first, then its direct children, then their direct children and so on, making the way nodes attach themselves to the network tend towards close proximity to the master node in a tree-like structure. Once contact is made the node requests an address from the master node, either directly or through other nodes. Once an address has been assigned and verified, the node is considered connected to the mesh and can then communicate with all other nodes in the mesh, and beyond to other systems etc.

Nodes have the option of managing their connection however desired, and quite often, a simple timer is suitable to verify connectivity after a set period of time. Transmitting nodes can also detect when communication is failing and re-establish their connectivity to the mesh as required. That is, at any given time, nodes will have a single path to communicate over the network, but if that link fails, they can re-establish their communication path through the network.

The communication layers are interoperable, meaning a network can combine devices running RF24Network and RF24Mesh libraries together, with static nodes running RF24Network, and dynamic nodes running RF24Mesh. Devices running RF24Ethernet (TCP/IP) can also communicate using the other layers of the libraries, interacting directly with RF24Mesh and/or RF24Network nodes. This allows an array of devices to operate on the same wireless mesh network, from ATTiny all the way to the more powerful devices like ESP32 and Raspberry Pi, using the RF24Network, RF24Mesh APIs and/or standard networking tools and protocols. (ICMP/TCP/UDP, etc.)

Current status, testing etc. 

RF24Mesh is now past the development/beta testing stage and considered (by me) to be stable and well tested. The mesh can handle a large number of nodes, theoretically up to 255, but in practice, more like 15-25 nodes sending or receiving data every few seconds is a reasonable bet. It generally depends on the type of traffic and frequency with which it is generated, as a much larger number of nodes reporting data every minute presents only a small load for the network.

The progress made with RF24Mesh is very encouraging, supporting simple communication scenarios, small household sensor networks, home automation systems, and larger expanded networks stretching over relatively long distances with the more powerful RF24 modules.

The RF24 communication stack is generally complete, with bug reports and issues dropping off quite nicely, but development is still ongoing. As always, please report any potential bugs or issues using the GitHub link below. 


Sunday

Comparative Performance Analysis between nRF24L01+ and XBEE ZB Module Based Wireless Ad-hoc Networks

Comparative Performance Analysis between nRF24L01+ and XBEE ZB Module Based Wireless Ad-hoc Networks


A paper was written comparing Zigbee vs nRF24L01+ based networks. For those of you who are interested, here is the paper:



Abstract—Among the common wireless communication modules like Bluetooth and Wi-Fi, XBee modules are embedded solutions providing wireless communication standard with self-healing mesh networks, which has longer range than Bluetooth and lower power consumption than Wi-Fi. 

An alternative to the XBee radio modules is nRF24L01+ radio modules which are cheap and powerful, highly integrated, ultra-low power (ULP) 2Mbps RF transceiver ICs for the 2.4GHz ISM (Industrial, Scientific, and Medical) band. In this paper, performances of nRF24L01+ modules have been analyzed and compared with that of XBee ZB modules in wireless ad-hoc networks. The performance metrics for the analytical study are - 

1) Throughput measurement, 
2) Mesh routing recovery time and 
3) Power consumption. 

This work has revolved around an open source library released by the developer, tmrh20 which builds a complete TCP/IP suite on top of the nRF24L01+ modules.

ConclusionIn this study, we have analyzed all the parameters mentioned in the introduction, focusing on the stark differences in the performance of nRF24L01+ against XBee. nRF24L01+ could provide a better throughput compared to XBee in almost all scenarios especially in point-to-point communication where it outshines XBee by a country mile. For multihop networks as well, the rate of transmission remains considerably higher...

...The radio, as well as well its supporting libraries have been under focus for quite some time now, however, in terms of development, it is still in its nascent phase. Nevertheless, its impact in the field has been nothing short of revolutionary because of the raw range and bandwidth it provides on paper at affordable prices. However, it remains to be seen whether with improvements in the sleep cycle implementation in the RF24 library or with a better alternative to the RF24 family, the nRF may be indeed considered a cheap viable replacement for XBee in wireless ad-hoc networks

TMRh20 Opinion: 

The study seems fair, but it is clear that the radios were not fully operational due to the hardware configuration, with power supply issues. ( Although an official Arduino Uno should be capable of driving the radios at 3.3v with no major issues ) It doesn't really make a lot of sense to conduct a range of testing using a known faulty hardware configuration, as this limited the range to 1m between nodes, throughput suffered as well as performance of the mesh.

As far as power consumption and implementation, the devices typically use approx. 15mA in active RX and slightly less during transmission. As active RF24Mesh nodes are always listening, they can choose to use interrupts to sleep the MCU during periods of inactivity (wake on RX), or remove themselves from the network and sleep completely. There are really not many options for managing the power usage/sleep cycles of these devices.


Saturday

Automation/IoT with NRF24L01+ and MQTT

Automation/IoT with Arduino, RPi, NRF24L01+ and MQTT
Control and monitor Arduino remotely with mobile devices


Overview:

Please see Arduino Project Hub for an up to date version of this tutorial
Or see the following for a video based description:




This is a quick tutorial on how to wirelessly control or monitor Arduino devices using nothing more than NRF24L01+ radio modules, a Raspberry Pi and a mobile device. I have found MQTT to be one of the best methods of controlling these devices wirelessly, in the case of simple input/output scenarios like monitoring sensor values or sending RGB values to wireless lighting systems.

This assumes users are familiar with the core RF24 library as well as installing libraries from the Arduino IDE, and building and running programs on the RPi.

Requirements:

Raspberry Pi with NRF24l01+ device attached
One or more Arduino devices with NRF24L01+ device attached
The RPi should be connected to the same network as your mobile device

Pre-configuration:

Ensure all devices are functional with RF24 core examples before attempting. 

  Install RF24 libraries on RPi from your home directory:
  2. chmod +x install.sh
  3. ./install.sh
  4. Follow the command prompts and install the RF24, RF24Network, RF24Mesh, and RF24Gateway libraries

  Install RF24 libraries on Arduino:
  1. From Arduino IDE select  Sketch > Include Libraries > Library Manager
  2. Install the RF24, RF24Network, RF24Mesh and RF24Ethernet libraries

RPi Setup:




Now that the correct libraries are installed, we need to install an MQTT broker on the Raspberry Pi. Setup is as easy as running the following command:

sudo apt-get install mosquitto

Note: As of mosquitto 2.0 you need to add  listener 1883 and  allow_anonymous true in mosquitto.conf.

Then we need to start the Gateway on the RPi, so it will pass traffic from the connected sensor nodes etc, to the MQTT server.

The RF24Gateway library is installed in ~/rf24libs/RF24Gateway/

In this example, we will use the ncurses example, located at ~/rf24libs/RF24Gateway/examples/ncurses

Edit the file RF24Gateway_ncurses.cpp and modify the radio constructor to suit your pin connections: RF24 radio(22,0); is the default, then type 'make -B' to build the example.

To run the example, type ' sudo ./RF24Gateway_ncurses ', and it should pop up asking for an IP and subnet mask to use. This is mainly arbitrary, and any suitable private IP/Mask can be selected.

Once the gateway is running, we can switch our attention to the Arduino.

Arduino Setup:

1. Open the MQTT example: File > Examples > RF24Ethernet > MQTT > mqtt_basic
2. Edit the radio constructor to suit your chosen CE/CS pins: RF24 radio(7,8); is default.
3. Edit the IP address of the device to match the range chosen when configuring the RPi.
4. Edit the IP of the gateway to match exactly the IP of the RPi
5. Edit the IP of the server to match exactly the IP of the RPI 
6. Upload the sketch to the Arduino.

Note: If using an external MQTT server, the RPI must be configured to forward packets and perform NAT, see the forwarding and routing section here.

You should see serial output like the following:
Attempting MQTT connection...connected

If not, something has gone wrong. Ensure your device is connecting to the mesh and showing up in the address list. If not, troubleshoot using examples from RF24 or RF24Mesh to diagnose the connectivity issues.

Nodes running the MQTT example will publish their NodeID every second to the MQTT server, at outTopic and will receive all messages published to the inTopic.

Setup on iPhone etc:

On my iPhone, I chose to use the program MQTTTerminal (MQTTool is also good with no ads). Setup is easy, just input the external IP address of the MQTT server (the ip of your RPi) and the port (1883). Then set the Publish Topic to inTopic and the Subscribe Topic to outTopic.

You should see messages incoming from the device(s) and can send data to the devices from the app.

From here it is a simple matter of customizing the topics and messages to suit your needs, whether controlling a simple LED on the Arduino, or reporting temperature and humidity from sensors.

This can be expanded using programs like Node Red to create an open-source home automation system. See my more recent blog post.

If problems are encountered etc, feel free to open an issue at https://github.com/nRF24/RF24Ethernet/issues 



AutoAnalogAudio Library - nRF52 Now supports Successive Approximation Analog-to-Digital Converter for Audio Input

 AutoAnalogAudio Library - nRF52 Now supports SAADC Support for Successive Approximation Analog-to-Digital Converter for Audio Input I'v...