Node on second level always connection fail

[SupotSaeEa]

On zero level, modules can connected to node 01, 02, 03 or 04 perfectly.
When adding the fifth module, it randomly connect to one of zero level node.
Even it successfully connect to zero level node, sometimes the connection lost with the result -1, -2 when do mesh.write.

Anyone face this the same problem an what can I do ?

[Avamander]

This is a hardware limitation, 4 nodes per node.

[SupotSaeEa]

Yes, I clearly known that. The issue occured when the fifth module try connect to level 1.
It can connect with some address such as 014. But after a minute it disconnect and connect with other address.

This is not occured on level zero such as node 01, 02, 03 or 04.

The fifth or other module are no moving (no location changed).

[Avamander]

Mesh networks work that way. It will constantly remap itself to minimize any issues with lost nodes or bad connection. As NodeID won't change it is no issue to still communicate with the node as you should use the NodeID instead of RF24Network address when you send messages.

[SupotSaeEa]

I send message by refer to NodeID. The issue is why level 0 node have no problem on lost or bad connection. It happens on level 1 and may on other level. Frankly speaking I not clear on how DHCP working. When I use DEBUG, It show me DHCP do something like to finding the new address from level 4 down to level 0. Note that whenever new node get into the network, the master get struck until the new node address is assigned or timeout.

Do you have a flow chart of DHCP? I will more clear on how it does during assign the new address.

[TMRh20]

Sending message by nodeID is less reliable because nodes will contact the master node to perform an address lookup. It needs some work.

I don't have a flow chart of DHCP, its kind of complicated. In a basic sense, nodes use multicast to find other active nodes, then request an address through them, from the master. Intermediary nodes relay traffic as required. I'm not sure why the master would get 'stuck' or 'struck' or what exactly you mean by that.

One thing to keep in mind, if you are changing nodes around or want to 'refresh' the mesh, you can:

1. Delete the dhcplist.txt file on the RPi
2. Wait 2 mins
3. Restart the application, and it will re-assign all addresses.

[SupotSaeEa]

OK I will do more to find out what exactly problem.
I will come back again with more problem details or How to solve this problem.
I still open this issue for someone who need to share for solution.

[SupotSaeEa]

It look significantly better on "MESH_MIN_SAVE_TIME" in RF24Mesh_config.h reduce from 30000 to 1000.
I don't know why and how this parameter effect to mesh address assignment.
But it show better result.
I can't find usage of this parameter in related library file.

[SupotSaeEa]

Last time I mention about parameter "MESH_MIN_SAVE_TIME" that is not the cause of problem.
I would like to repeat a problem again for clear.
I found the problem on the node that not a child of master node, level 2 and upper.
It is not stable when write data to master node. It can successfully write continuously 3-4 times then fail. And can write again after renew address.

I have back to use 30000 for MESH_MIN_SAVE_TIME and change another one of parameter that may the cause of problem.
Now level 2 node can send data to master node perfectly .
However I will recheck by long running again and again for sure.
And then the name of parameter will be informed.