Mesh config parameters

[Zuputmer]

Hi, i came across these parameters in RF24Mesh_config.h and i have a few doubts. I would appreciate it if anybody could explain them to me-

(#define MESH_MAX_CHILDREN 4) - Is 4 the maximum or can i set it to 5? Will that affect the working of the mesh in any way?

(#define MESH_MIN_SAVE_TIME 30000) - the comment after this parameter says "minimum time required before changing nodeID". I am afraid i do not understand. Node id is unique to each node, right?

(#define MESH_ADDRESS_HOLD_TIME 30000) - if a mesh address was released by a slave after communication with the master, and if i wanted the master to immediately reassign that address to some other slave, what should i set this parameter to?

Thanks in advance.

[TMRh20]

4 is the maximum. Setting it lower will make the nodes branch out more, since less address space will be available. The other two options are not used. They were added during development but not used. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

…

On Tue, Feb 19, 2019 at 1:33 AM Zuputmer ***@***.***> wrote: Hi, i came across these parameters in RF24Mesh_config.h and i have a few doubts. I would appreciate it if anybody could explain them to me- (#define MESH_MAX_CHILDREN 4) - Is 4 the maximum or can i set it to 5? Will that affect the working of the mesh in any way? (#define MESH_MIN_SAVE_TIME 30000) - the comment after this parameter says "minimum time required before changing nodeID". I am afraid i do not understand. Node id is unique to each node, right? (#define MESH_ADDRESS_HOLD_TIME 30000) - if a mesh address was released by a slave after communication with the master, and if i wanted the master to immediately reassign that address to some other slave, what should i set this parameter to? Thanks in advance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#161>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACfVHBM5zGwGhD_Bpmw3KGvooe3oJHnCks5vO6jYgaJpZM4bCWB9> .

[Zuputmer]

@TMRh20 thank you very much for your reply. I have a few other doubts too and it would be very helpful if you could explain them to me-

1. If i wanted to transfer a payload from the master to all the slaves at the same instant of time (RF24Mesh), could i use multicast? Could you please explain to me how i could do that? Would this transmission be instantaneous? if not, which nodes would receive them first?

2. Instead of using multicast as mentioned above, could i "sync" one particular variable that is shared between all the slaves in the mesh, and then set that variable from the master?

3. If mesh.write fails to send in the first attempt, how many times will it retry, at what intervals and for how long?

Thank you once again. Your help is invaluable.

[TMRh20]

1. I think so. You should be able to enable multicast relay, without anything wonky going on. Multicasting works in levels as shown here https://tmrh20.github.io/RF24Network/Tuning.html Nodes at level 1 will receive data first. They would then relay it to level 2. Level to relays to level 3 and so on. BTW multicast relay needs to be enabled at the network level. https://tmrh20.github.io/RF24Network/classRF24Network.html#add7408ca2b2f9ab15331ba77a747f7bb 2. Yes. 3. Writes use delays configured here https://github.com/nRF24/RF24Network/blob/master/RF24Network.cpp#L106 The setting is 5 radio retries with a staggered delay, and it will also wait longer for nodes that are further away. Usually a max of about 85 ms on a failed write across the network. This can be modified as required. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

…

On Tue, Feb 19, 2019 at 10:32 PM Zuputmer ***@***.***> wrote: Reopened #161 <#161>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#161 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACfVHDNwRVu0sqN0uMf0Ph3ov0IjYGpnks5vPM_OgaJpZM4bCWB9> .

[Zuputmer]

@TMRh20 Thank you for your reply.

Nodes at level 1 will receive data first. They would then relay it to level 2. Level to relays to level 3 and so on. BTW multicast relay needs to be enabled at the network level.

In this scenario, if i have configured all of my slaves to turn off as soon as they receive a particular payload from the master, will the slaves in level 1 relay the message to level 2 and then turn off or will they turn off without relaying the message?

2. Yes.

if you don't mind, could you please explain how i could do this? And would this be 'quicker' than using the multicast mentioned above?

thanks in advance

[TMRh20]

1. Nodes will relay multicast payloads before receiving them, so this will work. 2. You would have to figure something out on your own... and probably not. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

…

On Thu, Feb 21, 2019 at 3:45 AM Zuputmer ***@***.***> wrote: @TMRh20 <https://github.com/TMRh20> Thank you for your reply. Nodes at level 1 will receive data first. They would then relay it to level 2. Level to relays to level 3 and so on. BTW multicast relay needs to be enabled at the network level. In this scenario, if i have configured all of my slaves to turn off as soon as they receive a particular payload from the master, will the slaves in level 1 relay the message to level 2 and then turn off or will they turn off without relaying the message? 1. Yes. if you don't mind, could you please explain how i could do this? And would this be 'quicker' than using the multicast mentioned above? thanks in advance — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#161 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACfVHOh_z_-x-bTP23PDgdBrcRfHAdc5ks5vPmqggaJpZM4bCWB9> .

[Zuputmer]

@TMRh20 thank you very much.