mesh.checkConnection via parent not master

[TMRh20]

These changes tend to allow more nodes on a network, especially helping distant nodes (far from master node) with verifying connectivity as they only have to verify a connection with their parent node, instead of the master node. Tends to help with keeping the mesh together as nodes closer to the master node change their postition and/or address as the mesh changes physically or logically.

• Adjust mesh.checkConnection function to verify connectivity with parent only. Leave old functionality in place with a #define
• Suggestions in place per @2bndy5
• closes Potential mesh.checkConnection() improvement #249

Since this fundamentally changes behaviour of the mesh, I've tested the changes pretty well, and its looking good for these changes. I'm seeing greater connectivity, less packet loss, and a mesh that behaves a bit better.

Its not 5-9s, but its probably about as good as it gets after 1 day of testing with most nodes upgraded to this new functionality:

outdated suggestion

[github-actions]

Memory usage change @ 8c494ae

Board	flash	%	RAM for global variables	%
arduino:avr:nano	❔ -152 - +70	-0.49 - +0.23	0 - 0	0.0 - 0.0
arduino:samd:mkrzero	🔺 0 - +44	0.0 - +0.02	0 - 0	0.0 - 0.0

Click for full report table

Board	examples/RF24Mesh_Example flash	%	examples/RF24Mesh_Example RAM for global variables	%	examples/RF24Mesh_Example_Master_Statics flash	%	examples/RF24Mesh_Example_Master_Statics RAM for global variables	%	examples/RF24Mesh_Example_Master_To_Nodes flash	%	examples/RF24Mesh_Example_Master_To_Nodes RAM for global variables	%	examples/RF24Mesh_Example_Node2Node flash	%	examples/RF24Mesh_Example_Node2Node RAM for global variables	%	examples/RF24Mesh_Example_Node2NodeExtra flash	%	examples/RF24Mesh_Example_Node2NodeExtra RAM for global variables	%	examples/RF24Mesh_SerialConfig flash	%	examples/RF24Mesh_SerialConfig RAM for global variables	%	examples/RF24Mesh_Example_Master flash	%	examples/RF24Mesh_Example_Master RAM for global variables	%
arduino:avr:nano	-152	-0.49	0	0.0	0	0.0	0	0.0	0	0.0	0	0.0	64	0.21	0	0.0	70	0.23	0	0.0	0	0.0	0	0.0	0	0.0	0	0.0
arduino:samd:mkrzero	40	0.02	0	0.0	0	0.0	0	0.0	0	0.0	0	0.0	40	0.02	0	0.0	44	0.02	0	0.0	0	0.0	0	0.0	0	0.0	0	0.0

Click for full report CSV

Board,examples/RF24Mesh_Example<br>flash,%,examples/RF24Mesh_Example<br>RAM for global variables,%,examples/RF24Mesh_Example_Master_Statics<br>flash,%,examples/RF24Mesh_Example_Master_Statics<br>RAM for global variables,%,examples/RF24Mesh_Example_Master_To_Nodes<br>flash,%,examples/RF24Mesh_Example_Master_To_Nodes<br>RAM for global variables,%,examples/RF24Mesh_Example_Node2Node<br>flash,%,examples/RF24Mesh_Example_Node2Node<br>RAM for global variables,%,examples/RF24Mesh_Example_Node2NodeExtra<br>flash,%,examples/RF24Mesh_Example_Node2NodeExtra<br>RAM for global variables,%,examples/RF24Mesh_SerialConfig<br>flash,%,examples/RF24Mesh_SerialConfig<br>RAM for global variables,%,examples/RF24Mesh_Example_Master<br>flash,%,examples/RF24Mesh_Example_Master<br>RAM for global variables,%
arduino:avr:nano,-152,-0.49,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0,64,0.21,0,0.0,70,0.23,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0
arduino:samd:mkrzero,40,0.02,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0,40,0.02,0,0.0,44,0.02,0,0.0,0,0.0,0,0.0,0,0.0,0,0.0

[2bndy5]

Compiling for Arduino Nano

The generic non-master node example shows a significant decrease in flash memory (-152 bytes). For some reason the Node2Node examples both show a slight increase in flash memory (+64 and +70 bytes). It isn't apparent why the flash memory increased for the Node2Node examples, but I think the generic non-master node example is a more relevant result.

Compiling for cortex-based MCU

The ATSAMD21 showed negligible increase in flash memory (+40 to +44 bytes) on generic non-master node and Node2Node examples, but that family of processors is well equipped for any changes in compile size.

[2bndy5]

I also added the ability to use the old behavior in CMake builds:

RF24Mesh/CMakeLists.txt

Lines 146 to 149 in 458e964

	if(DEFINED RF24MESH_CONN_CHECK_TYPE)
	message(STATUS "RF24MESH_CONN_CHECK_TYPE set to ${RF24MESH_CONN_CHECK_TYPE}")
	target_compile_definitions(${LibTargetName} PUBLIC RF24MESH_CONN_CHECK_TYPE=${RF24MESH_CONN_CHECK_TYPE})
	endif()

cd RF24Mesh/build
cmake .. -DRF24MESH_CONN_CHECK_TYPE=RF24MESH_CONN_CHECK_MASTER
make

I haven't actually tested this yet. It might be more effective to add the CMake option to examples_RPi/CMakeLists.txt (instead of root/lib CMakeLists.txt).

[2bndy5]

It might be more effective to add the CMake option to examples_RPi/CMakeLists.txt (instead of root/lib CMakeLists.txt).

I think this would apply to any macro wrapped with #ifndef guards. This idea would be better suited to a different PR. For now, I'll leave it as is until I get around to investigating further. Currently, the Linux builds are working fine.

[2bndy5]

Would it make sense to return true if checkConnection() is called on a master node?

As long as the master node's radio is idling in RX, I think this would be interpreted as "connected to the mesh." Otherwise, user code written for both master and child nodes might end up calling renewAddress() on master node if their code doesn't understand that it is running the master node. I see no considerations in renewAddress() (& its helper requestAddress()) when the node ID is set to 0.

[TMRh20]

Damn, you've been busy @2bndy5

Would it make sense to return true if checkConnection() is called on a master node?

I was thinking the same thing.

Will have to look at your other comments tomorrow probably, but at a glance they all add up.

[TMRh20]

Thanks for making the necessary changes!

Been testing extensively and there are some drawbacks:

• Nodes tend to stay connected at one mesh location for longer. This can be good, but if nodes with somewhat spotty connections attach as direct child nodes of the master, they may hold their position for longer.
• Distant nodes with a spotty connection to master may also hold their position longer, even though they are having connectivity issues.
• These drawbacks can be somewhat mitigated by additional connection checking/renewal of addresses if connections are failing. For example, when using RF24Mesh directly, I just use a timer to verify connectivity every 10-30 seconds. It may also be beneficial to verify if writes/connections are failing and renew the address upon multiple failures. With RF24Ethernet, I've added a line to many of my nodes to always renew the address if unable to connect to MQTT.
• Nodes can get 'lost'. If an address is set to 0 or the mesh is quickly restarted, nodes may be able to verify their connectivity with their parent node, but have no bi-directional communication with the master node. Again it may be suitable to verify connectivity with the master node periodically, or leave the master node off for long enough so all nodes are in a state of renewal to work around this issue.