Sixth node does not receive an address

[QBGROUP]

I am using the "mesh_example_master" and "mesh_example" examples. When I start the first node with a its unique id it gets a network address 05, the second 04, the third 03 until the fifth gets 01, the sixth gets no address.
Am I doing something wrong? the code is exactly as in the examples

[2bndy5]

RF24Mesh does not allow for 6 child nodes; it only allows up to 5. This is because RF24Netowk uses pipe 0 to listen for messages from the parent node.

I understand that the master node cannot have a parent node, but adding the logic to let only the master node have up to 6 child nodes would be very difficult to implement (would require extensive modifications to RF24Network and RF24Mesh).
EDIT: The master node also uses pipe 0 to listen for multicasted messages.

[2bndy5]

Reviewing the pyrf24 topology document should be enlightening. (It uses the same C++ code under the hood).

[TMRh20]

If you’ve given them all unique ids with RF24Mesh the 6th node should attach through one of the other 5. I think Brendan might be misunderstanding the question.Are you sure the 6th node is working? Have you powered them up in separate orders?On Feb 15, 2023, at 11:06 AM, Brendan ***@***.***> wrote: Closed #218 as not planned. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[QBGROUP]

Thank you, I did not know about this https://pyrf24.readthedocs.io/en/latest/topology.html, very interesting article.
I'll do more testing to understand what happens.
Let's imagine that the first five clients turn on and get a top-level address, but then they are all turned off, if I turn on the sixth one from the way the system works no address is assigned. I need to implement a keep alive system and delete the clients that are no longer active.
I have not found a way to go and delete an item from the mesh.addrList array and update mesh.addrListTop accordingly. I don't think I can directly edit the array.
I've read many threads here about having to manage a ping/pong system to verify that clients are active, but I haven't found anything about how to keep the list of clients updated.
Thank you very much!

[2bndy5]

I have not found a way to go and delete an item from the mesh.addrList array and update mesh.addrListTop accordingly.

Use RF24Mesh::releaseAddress() before any node will "turn off" (or go to sleep). That function will adjust the addrList array on master for you.

Ultimately, RF24Mesh doesn't use timed leases for addresses that are assigned to nodes. So, a keep-alive message can be useful (via NETWORK_POLL message type) for the master to determine when to adjust it's addrList array.

---

I am grateful that you're taking the time to read docs. ❤️

[2bndy5]

@TMRh20 Would it make sense for the master node to have an overloaded releaseAddress(uint8_t node_id) to foolproof managing the addrList array?

[TMRh20]

I’m not sure of how that would work. I think I’d need more info on how it would work. Users can set also manually set the network address to 0 when a node goes inactive.On Feb 15, 2023, at 3:03 PM, Brendan ***@***.***> wrote: @TMRh20 Would it make sense for the master node to have an overloaded releaseAddress(uint8_t node_id) to foolproof managing the addrList array? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[2bndy5]

The way I'm thinking is basically an abstraction of the following code into a function.

RF24Mesh/RF24Mesh.cpp

Lines 91 to 98 in 780fa08

	else if (type == MESH_ADDR_RELEASE) {
	uint16_t* fromAddr = (uint16_t*)network.frame_buffer;
	for (uint8_t i = 0; i < addrListTop; i++) {
	if (addrList[i].address == *fromAddr) {
	addrList[i].address = 0;
	}
	}
	}

And gaurd it with #ifndef MESH_NO_MASTER.

[2bndy5]

The pseudo code for implementing a keep-alive message would look like:

// on the master node only

if (node_n has not polled master in 10 seconds)
    mesh.releaseAddress(node_n.address);

This way we don't offload bounds checking to users (requiring knowledge of addrListTop), and we ensure that the assigned id is properly set to 0.

[TMRh20]

@2bndy5 Oh, I see what you mean. Yeah, I think that could work.

@QBGROUP Yeah RF24Mesh doesn't have any built in functionality to remove non-active nodes. You would have to implement something yourself depending on how you want it to work. With what Brendan is suggesting, it would be a bit easier, but for now you can edit the address list manually, and set the inactive nodes RF24Network address to 0 when they go inactive or time-out.

[Avamander]

Implementing good expiricy that works generally is hard, adding it to the library would probably be too much effort. The first thing being that nodes probably need different expiricies...

It's relatively easy to add that pseudocode, but it's way harder if you need to fine-tune it (and eventually you will). Then it's a mix of your own and the library's keep-alive/expiricy code - not very pretty.

[2bndy5]

RF24Network address

aka "logical address" -- not to be confused with a mesh node's ID number (set with or mesh.setNodeID())

[2bndy5]

Also if a level 1 child is "expired", then all children of that node will become expired as well.

[QBGROUP]

The pseudo code for implementing a keep-alive message would look like:

// on the master node only

if (node_n has not polled master in 10 seconds)
    mesh.releaseAddress(node_n.address);

This way we don't offload bounds checking to users (requiring knowledge of addrListTop), and we ensure that the assigned id is properly set to 0.

Are you sure you can use mesh.releaseAddress(node_n.address);?

From docs
bool RF24Mesh::releaseAddress ( )

releaseAddress does not take any argument.
But if with this

addrList[i].address = 0;

I free the address and can be used again it should do what I need.
I'll test it asap
Thank you

[2bndy5]

Are you sure you can use mesh.releaseAddress(node_n.address);?

It is an idea that hasn't been implemented in code yet.

[QBGROUP]

@2bndy5 Oh, I see what you mean. Yeah, I think that could work.

@QBGROUP Yeah RF24Mesh doesn't have any built in functionality to remove non-active nodes. You would have to implement something yourself depending on how you want it to work. With what Brendan is suggesting, it would be a bit easier, but for now you can edit the address list manually, and set the inactive nodes RF24Network address to 0 when they go inactive or time-out.

I tried this way and works.
Thank you all.

This question is off topic, but related to network management.
Do you think RF24 and this mesh library is the right choice for network nodes (esp32 battery powered) that moves a lot? Every person in a meeting has one, but they will move so the mesh network will periodically change.
I'd like to use these modules because of power management, but if this is not the best use I could use ESP-WIFI-MESH but it uses much more battery power!

thank you all!!!

[2bndy5]

Do you think RF24 and this mesh library is the right choice for network nodes (esp32 battery powered) that moves a lot? Every person in a meeting has one, but they will move so the mesh network will periodically change.

If the meetings are really long, then yes a power efficient solution is best. I wouldn't worry about the frequency of movement, but the speed of movement may be a detriment. You should be fine as long as the nodes aren't attached to race cars or something that can traverse a great distance in a fraction of a second.

I only took interest in this radio because the latency of WiFi and Bluetooth is too high for remotely-controlled robotics. Unfortunately, ESP chips don't expose the low level machinery required to make them OTA compatible with this radio.