A user friendly mesh overlay for sensor networks using RF24Network and nRF24L01 radio modules
RF24Network addresses can be viewed as MAC addresses, and RF24Mesh nodeIDs viewed as static IP addresses. When joining or re-attaching to the network, nodes will request a RF24Network address, and are identified via nodeID.
Raspberry Pi/Linux: On Linux devices, the RF24Gateway will save address assignments to file (dhcplist.txt) so they will be restored, even if the gateway is restarted. To force network re-convergence, delete the dhcplist.txt file and restart the gateway. If nodes are configured to verify their connection at a set interval, the gateway should be left offline for at least that period of time.
Arduino/AVR: On all other devices, the address list is not saved. To force network re-convergence, restart the gateway. If nodes are configured to verify their connection at a set interval, the gateway should be left offline for at least that period of time.
If a node/nodeID is removed from the network permanently, the address should be released prior to removal. If it is not, the assigned RF24Network address should be written to 0 in the RF24Mesh address list.
RF24Mesh nodeIDs are unique identifiers, while RF24Network addresses change dynamically within a statically defined structure. Due to this structure, it is simple for any node to communicate with the master node, since the RF24Network address is always known (00). Conversely, the master node maintains a list of every node on the network, so address 'lookups' return immediately.
Communication from node-to-node requires address queries to be sent to the master node, since individual nodes may change RF24Network & radio address at any time. Due to the extra data transmissions, node-to-node communication is less efficient.
One thing to keep in mind is the dynamic nature of RF24Mesh, and the need to verify connectivity to the network. For nodes that are constantly transmitting, (every few seconds at most) it is suitable to check the connection, and/or renew the address when connectivity fails. Since data is not saved by the master node, if the master node goes down, all child nodes must renew their address. In this case, as long as the master node is down for a few seconds, the nodes will all begin requesting an address.
Nodes that are not actively transmitting, should be configured to test their connection at predefined intervals, to allow them to reconnect as necessary.
In the case of sleeping nodes, or nodes that will only be online temporarily, it is generally suitable to release the address prior to going offline, and requesting an address upon waking. Keep in mind, address requests can generally take anywhere from 10-15ms, up to few seconds in most cases.
One of the recently introduced features is the ability to transmit payloads without the network returning a network-ack response. If solely using this method of transmission, the node should also be configured to verify its connection via mesh.checkConnection(); periodically, to ensure connectivity.
Beyond requesting and releasing addresses, usage is outlined in the class documentation, and further information regarding RF24Network is available at http://tmrh20.github.io/RF24Network