Mesh addressing

[Zuputmer]

Hey,
I was wondering, supposing i have 100 nodes running the mesh sketch and one master in the middle. Supposing all 100 nodes are within the range of the master, how will the nodes be addressed then? Will the tree topology still be followed or will they directly talk to the master? What will their addresses look like?

Please forgive my question, i am new to this. Thanks in advance.

[TMRh20]

The tree topology and routing will still be followed just the same regardless of number of nodes or proximity to master.

…

On Thu, Dec 27, 2018 at 1:12 AM Zuputmer ***@***.***> wrote: Hey, I was wondering, supposing i have 100 nodes running the mesh sketch and one master in the middle. Supposing all 100 nodes are within the range of the master, how will the nodes be addressed then? Will the tree topology still be followed or will they directly talk to the master? What will their addresses look like? Please forgive my question, i am new to this. Thanks in advance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#157>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACfVHKbRlm2z8i7Z-yI6Bls2DWD96aDJks5u9HLsgaJpZM4Zia2a> .

[Zuputmer]

@TMRh20 Thank you for your reply. However, in my network all nodes will not be powered on at any given time. The nodes will be powered on one after the other and then powered off after they finish sending data to the master,, based on an interrupt from an RTC. If routing is still followed regardless of proximity to the master, then i cannot implement a mesh network using my individual battery powered nodes, am i right? I say this because the parent node of one particular node might not be powered while this node turns on. All i want to do is send data to the master and then turn off.

[TMRh20]

This would not really work unless you had a number of routing nodes that stayed online. However, with RF24Network, you could implement a system where the nodes are in range of the master and use a unicast write to send their data directly to the master. This bypasses the standard routing and addressing topology. This option allows nodes to write directly to any other node. The receiving node will either accept or forward on the payload as required. See https://tmrh20.github.io/RF24Network/classRF24Network.html bool write <https://tmrh20.github.io/RF24Network/classRF24Network.html#a3d99643014071fef706c0320c8011648> (RF24NetworkHeader <https://tmrh20.github.io/RF24Network/structRF24NetworkHeader.html> &header, const void *message, uint16_t len, uint16_t writeDirect) If you set 'writeDirect' to 0, and address the header to the master, any number of nodes in range can write data directly to the master. ie: RF24NetworkHeader header(0,'M'); //Send an M type message addressed to master node (0) network.write(header,&displayTimer,sizeof(displayTimer),0)) //Write using unicast to master node They will not use auto-retry, so each payload is sent only once. Hope this helps. TMRh20

…

On Thu, Dec 27, 2018 at 9:14 AM Zuputmer ***@***.***> wrote: @TMRh20 <https://github.com/TMRh20> Thank you for your reply. However, in my network all nodes will not be powered on at any given time. The nodes will be powered on one after the other and then powered off after they finish sending data to the master,, based on an interrupt from an RTC. If routing is still followed regardless of proximity to the master, then i cannot implement a mesh network using my individual battery powered nodes, am i right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACfVHJpfTZJE9htQ6wUQj4hqaLXdWmntks5u9OO_gaJpZM4Zia2a> .

[Zuputmer]

@TMRh20 Thank you so much for your reply. Once again, your help is greatly appreciated. I now have a clear idea of what i should do. However, i do have a couple of questions-
1)Since auto retry will not happen as you mentioned, i can use the returned bool variable from the write function to check if transmission has failed and then retry manually in the code, am i right?
2)When using unicast write, is it possible for the master to know the node ID of the node that sent the data to it? Or should i include the address in the payload being sent to the master?
3)If i use unicast write to send data to the master node, is it possible to use AckPayload to send some data back to the node from the master?

[TMRh20]

No problem. 1. When using unicast, there is no acknowledgement, so no way to know if a payload was successful. 2. The master node will have the network address of the node that sent the payload, which can be translated to node ID by the master if using RF24Mesh.

…

On Dec 27, 2018, at 22:57, Zuputmer ***@***.***> wrote: @TMRh20 Thank you so much for your reply. Once again, your help is greatly appreciated. I now have a clear idea of what i should do. However, i do have a couple of questions- 1)Since auto retry will not happen as you mentioned, i can use the returned bool variable from the write function to check if transmission has failed and then retry manually in the code, am i right? 2)When using unicast write, is it possible for the master to know the node ID of the node that sent the data to it? Or should i include the address in the payload being sent to the master? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.