Simple RF24Mesh user guide?

[TMRh20]

I just wrote a post for my blog that is a simple overview/user guide for RF24Mesh, and realized it might be useful here. Can you take a look @2bndy5 and let me know if you think its best left there, or placed here as well. Its still a work in progress, but should be complete over the next day or so.

https://tmrh20.blogspot.com/2026/08/the-rf24mesh-users-guide.html

[2bndy5]

Sure, I'm all for additional docs/tutorials. Not sure how you want to organize that info into the existing doc files; it seems some of the stuff is related to setup-and-config, while other stuff was related to general-usage.

[TMRh20]

I'll have to think about that a little. It's an attempt to cover all the main bases of operation, so anybody who reads it would be able to understand how to run a basic RF24Mesh network with a few nodes on either Arduino or Linux. Any and all suggestions are welcome too.

[2bndy5]

How about a tutorial like what was submitted to RF24Ethernet (or Gateway, I get the 2 confused)?

[TMRh20]

You mean https://nrf24.github.io/RF24Ethernet/md_docs_2gateway-linux.html ?

Hmm, my initial thoughts were against that since RF24Mesh is so simple, but that might be a good idea. I forget that things need to be explained lol. Since that was done with AI, I figured this can be too, so attempted to combine the info from the User Guide into info from the official docs. This is what it came up with:

RF24Mesh Installation & Usage Guide (2026)

This tutorial provides a practical, documentation-aligned guide for RF24Mesh installation and usage, combining official RF24Mesh docs with the 2026 user-guide notes.

Repository: nRF24/RF24Mesh
Docs: https://nrf24.github.io/RF24Mesh/

---

Table of Contents

• Overview
• What RF24Mesh Automates
• NodeID vs RF24Network Address
• Topology and Routing Model
• Installation
  • Arduino
  • Linux (manual build)
• Basic Runtime Patterns
  • Master Node
  • Non-master Nodes
• Using RF24Mesh with RF24Ethernet / RF24Gateway
• Configuration Tips (from User Guide)
• Linux vs Arduino: Key Differences
• Bring-up Checklist
• Common Pitfalls
• References

---

Overview

RF24Mesh is the Layer 7 automation layer in the RF24 communication stack:

1. RF24: Radio driver
2. RF24Network: Routing/network layer
3. RF24Mesh: Automated addressing and lookup services

RF24Mesh is useful directly, and is also foundational for higher-level libraries like RF24Ethernet and RF24Gateway.

---

What RF24Mesh Automates

RF24Mesh is designed to reduce manual networking maintenance by automating:

• Dynamic RF24Network address assignment/reassignment
• Node lookup (similar in concept to DNS mapping)
• Ongoing address and connectivity maintenance
• Communication support for networks where nodes can move or reconnect over time

A central Master node tracks network identity mappings and serves lookup/assignment duties.

---

NodeID vs RF24Network Address

Understanding this distinction is essential.

• NodeID (static, assigned by you)
  • Logical identity of a node
  • Unique per node
• RF24Network address (dynamic)
  • Physical/routing position in the mesh
  • Can change as topology changes

In practice:

• You identify devices by NodeID
• The mesh routes using RF24Network addresses

---

Topology and Routing Model

• One Master node manages the mesh map and assignment logic.
• The Master should remain online for stable operation.
• Nodes do not need direct range to Master:
  • They only need a route through other connected nodes.
• Typical layer model:
  • Layer 0 = Master
  • Layers 1–4 = routed nodes
• Typical max path depth is ~4 hops from Master.

---

Installation

Arduino

Install the following from Arduino Library Manager:

• RF24
• RF24Network
• RF24Mesh

Then assign a unique NodeID in each node sketch.

NodeID planning notes

Common convention from user-guide guidance:

• Usable NodeIDs: 2–253
• 0 and 1 are typically reserved for master-related roles/conventions

---

Linux (manual build)

Build dependencies in this exact order:

1. RF24
2. RF24Network
3. RF24Mesh

Example sequence:

git clone https://github.com/nRF24/RF24.git
git clone https://github.com/nRF24/RF24Network.git
git clone https://github.com/nRF24/RF24Mesh.git

Build RF24

cd RF24
cmake -B build -S .
cmake --build build
sudo cmake --install build
cd ..

Build RF24Network

cd RF24Network
cmake -B build -S .
cmake --build build
sudo cmake --install build
cd ..

Build RF24Mesh

cd RF24Mesh
cmake -B build -S .
cmake --build build
sudo cmake --install build

Build RF24Mesh Linux examples

cmake -B examples_RPi/build examples_RPi
cmake --build examples_RPi/build

---

Basic Runtime Patterns

Master Node

The master loop should continuously:

• mesh.update()
• DHCP/address maintenance (as shown in examples, typically mesh.DHCP())
• Receive and process incoming network payloads

The Master is your address authority, so uptime matters.

Non-master Nodes

Each node should continuously:

• mesh.update()
• Check connectivity
• Renew address when disconnected or stale

This is especially important for mobile/intermittent nodes.

---

Using RF24Mesh with RF24Ethernet / RF24Gateway

RF24Mesh behavior remains fundamentally the same while enabling higher-level networking:

• TCP/IP
• UDP
• Protocols like MQTT, HTTP, SSH, etc.

You can run tiny RF24 mesh messages and larger network packets in the same deployment.

Security note

• RF52-based radio setups may support integrated lower-layer encryption workflows.
• With RF24Ethernet/RF24Gateway, transport/application security is typically done above mesh (TLS/SSL/SSH, etc.).

---

Configuration Tips (from User Guide)

These are practical tuning options in RF24Mesh_config.h:

1) Pre-allocate master node table memory

Default example:

#define MESH_MEM_ALLOC_SIZE 10

Increase this for bigger networks, especially on constrained non-Linux masters, to reduce runtime alloc/realloc churn.

2) Connectivity check strategy

Option available to verify against Master (instead of only parent-node checks):

• RF24MESH_CONN_CHECK_MASTER (comment state/config depends on current file version)

Tradeoff:

• Better direct validation/hardening
• Increased network traffic

3) Mixing static RF24Network nodes with RF24Mesh

You can run static-address RF24Network nodes on the same transport:

• Define static addresses on Master
• Keep those static nodes physically stable/connected
• Use mesh for dynamic participants

---

Linux vs Arduino: Key Differences

Address map persistence on reboot

• Linux Master:
  • Persists NodeID/address map to dhcplist.txt
  • Can resume with prior assignments after reboot
• Arduino Master:
  • No default persistence
  • Nodes rejoin/renew after master restart

If you want a fresh Linux startup state, remove dhcplist.txt before launch.

Fragment handling behavior

• Linux: Better suited to multi-node concurrent fragment handling
• Arduino: More constrained fragment buffering behavior

For heavy traffic or large payloads across many nodes, Linux is typically preferred for the Master role.

---

Bring-up Checklist

1. Verify RF24 radio link (point-to-point)
2. Verify RF24Network routing
3. Enable RF24Mesh dynamic behavior
4. Start with 1 Master + 1 node
5. Add one node at a time
6. Observe rejoin behavior after power cycles and link interruptions
7. Tune memory/connection-check options as needed

---

Common Pitfalls

• Wrong build/install order (must be RF24 → RF24Network → RF24Mesh)
• Duplicate NodeIDs
• Master not kept online reliably
• Infrequent connectivity checks on clients
• Underpowered/noisy 3.3V radio supply
• Not accounting for reboot persistence differences (Linux vs Arduino)

---

References

• RF24Mesh repository: https://github.com/nRF24/RF24Mesh
• RF24Mesh docs: https://nrf24.github.io/RF24Mesh/
• RF24Mesh setup/config page: https://nrf24.github.io/RF24Mesh/md_docs_2setup__config.html
• RF24Mesh User Guide (blog, Aug 2026): https://tmrh20.blogspot.com/2026/

[2bndy5]

The first 3 sections (everything up to "installing") reads a lot like the network topology doc I wrote for pyRF24, without graphs and some extra OSI descriptions added.

The "bring-up checklist" (whatever the hell that means) can probably be dropped by instructing the user, during install instructions, to test our basic examples in each layer.

The "common pitfalls" section could probably get is own doc and use references to RF24 COMMON_ISSUES doc.

[TMRh20]

So, in other words, you don't like it? lol

I will need some time to make edits, but will come back to this. Got tied up with other things.