RF24Network
RF24Network copied to clipboard
nRF24
ESP32 & Network Library
Hi, I have an ESP32 acting as Node 0, connecting succesfully to other Arduino/Nano's on a variety of nodes (1-5), very reliably, no problems until I try and set a slave node such as 013 etc. Regardless what I do, the message is not received and get a 'send fail' through through the NRF debug function. As soon as the node numbers revert to 1-5, everything works fine, so the hardware is ok. Any idea's on what to try ?, does the Network library have some issue that needs tweaked. Before I get other suggestions, I want to stay with the NRF24L01, ESP32 & Arduinos. I have already tested it over significant distance (300-400ft) with external aerial systems and for my application, its the right solution, just except the sub-node numbering....
The main thing is to make sure you have the master and slave nodes numbered correctly. Ie. for node 013 you need node 03 up and running. Also make sure to use the leading 0 when specifying nodes so it uses the octal format. A couple things to verify…
On May 26, 2021, at 4:49 PM, BryanInglis @.***> wrote:
Hi, I have an ESP32 acting as Node 0, connecting succesfully to other Arduino/Nano's on a variety of nodes (1-5), very reliably, no problems until I try and set a slave node such as 013 etc. Regardless what I do, the message is not received and get a 'send fail' through through the NRF debug function. As soon as the node numbers revert to 1-5, everything works fine, so the hardware is ok. Any idea's on what to try ?, does the Network library have some issue that needs tweaked. Before I get other suggestions, I want to stay with the NRF24L01, ESP32 & Arduinos. I have already tested it over significant distance (300-400ft) with external aerial systems and for my application, its the right solution, just except the sub-node numbering....
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Thanks for the prompt reply Yes, I am using the correct Oct numbering and ensure that '03' is up so that I can use '013'. If I use 02 and 03, everything works fine. I'm pretty sure it's the ESP32 that's having a flaky with the sub numbering. For my application, I use about every feature and speed of the ESP32, so changing micro is not possible. Is there any other debug function that I can use to examine the addressing or is there anything in the debug message that I should be looking for?
Is there any other debug function that I can use to examine the addressing or is there anything in the debug message that I should be looking for?
I'm curious what function you are referring to. The RF24::printDetails() function will tell you the addresses assigned to the pipes, but these addresses are the "physical addresses" and not the "logical addresses"; "logical address" is the octal number you assign the network node, and "physical address" is the logical address translated into a OTA friendly 5-byte number. You could compare the physical addresses of each node to make sure that a connection between them is properly configured...
If I use 02 and 03, everything works fine.
- Are you trying to say without node 02 up & running, node 03 doesn't pass the message to node 013?
- What is the proximity of these nodes? Node 02 should not have any affect on the behavior of node 03, assuming you are sending a normal message type.
Brendan,
I've seen the printdetails function and use it already, thx.
In my example I have: Node 00: ESP32 acting as master Node 03: Arduino Mega, running a sensor sketch and responding to Node 00 asking for data Node 013: Arduino Nano, running sensor sketch and responding to Node 00 asking for data
In fact I have several other Arduino Mega nodes, running sensor sketches and as long as the all have node numbers 01-05, everything works fine, but as soon as anyone becomes a child, 012/013/014 etc, the child stops working, regardless of being either the mega or Nano having either role. If I try different childs, the parent node is working fine.....very confused!
I have the network.update() running at the beginning of each program loop, most loops have cycle times of 400-800ms although the ESp32 is running much faster, however the master works in an asynchronous style, only sends out new commands when the slave has responded and the data has been processed, so there is not a mass of messages flying about from all angles.
Distance wise, this is all sitting on my bench just now using the aeriel version of the module and the pcb version. That also doesn't seem to have any effect. Previously I had a small, non slave, network running with only aerials and an external aerial on the master (running on a mega) over 200-300ft outside, very successfully, but I now need the speed and extra functions of the ESP32 for additional capability. In total, in the short term, I need to expand the slaves to about at least 15 units, including the master node, so the child node issue is a real problem....
Best regards,
Bryan
Get Outlook for Android https://aka.ms/ghei36
From: Brendan @.> Sent: Thursday, May 27, 2021 1:57:08 AM To: nRF24/RF24Network @.> Cc: BryanInglis @.>; Author < @.> Subject: Re: [nRF24/RF24Network] ESP32 & Network Library (#173)
Is there any other debug function that I can use to examine the addressing or is there anything in the debug message that I should be looking for?
I'm curious what function you are referring to. The RF24::printDetails() function will tell you the addresses assigned to the pipes, but these addresses are the "physical addresses" and not the "logical addresses"; "logical address" is the octal number you assign the network node, and "physical address" is the logical address translated into a OTA friendly 5-byte number. You could compare the physical addresses of each node to make sure that a connection between them is properly configured...
If I use 02 and 03, everything works fine.
- Are you try to say, without node 02 up & running, node 03 doesn't pass the message to node 013?
- What is the proximity of these nodes? Node 02 should not have any affect on the behavior of node 03, assuming you are sending a normal message type.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24Network/issues/173#issuecomment-849225912, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHMSOSJAB5LPGXIUVETAK3TPWKGJANCNFSM45TATDZA .
I’m not sure what to suggest here, you can enable debug routing on the parent node to see what’s happening, but that’s all I can think of.
On May 27, 2021, at 1:12 PM, BryanInglis @.***> wrote:
Brendan,
I've seen the printdetails function and use it already, thx.
In my example I have: Node 00: ESP32 acting as master Node 03: Arduino Mega, running a sensor sketch and responding to Node 00 asking for data Node 013: Arduino Nano, running sensor sketch and responding to Node 00 asking for data
In fact I have several other Arduino Mega nodes, running sensor sketches and as long as the all have node numbers 01-05, everything works fine, but as soon as anyone becomes a child, 012/013/014 etc, the child stops working, regardless of being either the mega or Nano having either role. If I try different childs, the parent node is working fine.....very confused!
I have the network.update() running at the beginning of each program loop, most loops have cycle times of 400-800ms although the ESp32 is running much faster, however the master works in an asynchronous style, only sends out new commands when the slave has responded and the data has been processed, so there is not a mass of messages flying about from all angles.
Distance wise, this is all sitting on my bench just now using the aeriel version of the module and the pcb version. That also doesn't seem to have any effect. Previously I had a small, non slave, network running with only aerials and an external aerial on the master (running on a mega) over 200-300ft outside, very successfully, but I now need the speed and extra functions of the ESP32 for additional capability. In total, in the short term, I need to expand the slaves to about at least 15 units, including the master node, so the child node issue is a real problem....
Best regards,
Bryan
Get Outlook for Android https://aka.ms/ghei36
From: Brendan @.> Sent: Thursday, May 27, 2021 1:57:08 AM To: nRF24/RF24Network @.> Cc: BryanInglis @.>; Author < @.> Subject: Re: [nRF24/RF24Network] ESP32 & Network Library (#173)
Is there any other debug function that I can use to examine the addressing or is there anything in the debug message that I should be looking for?
I'm curious what function you are referring to. The RF24::printDetails() function will tell you the addresses assigned to the pipes, but these addresses are the "physical addresses" and not the "logical addresses"; "logical address" is the octal number you assign the network node, and "physical address" is the logical address translated into a OTA friendly 5-byte number. You could compare the physical addresses of each node to make sure that a connection between them is properly configured...
If I use 02 and 03, everything works fine.
- Are you try to say, without node 02 up & running, node 03 doesn't pass the message to node 013?
- What is the proximity of these nodes? Node 02 should not have any affect on the behavior of node 03, assuming you are sending a normal message type.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24Network/issues/173#issuecomment-849225912, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHMSOSJAB5LPGXIUVETAK3TPWKGJANCNFSM45TATDZA . — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Invoked SerialDebug and got this on Node 0:
Sent Hex Data: 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15147: NET Enqueue @0 write_register(00,0e) write_register(02,3f) 27181: NET Sending id 1 from 00 to 012 type 148 27186: NET message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 27194: MAC Sending to 012 via 02 on pipe 5 write_register(01,01) 27200: NET Pipe 5 on node 02 has address cccccc33e3 [Writing 32 bytes 0 blanks] write_register(01,00) write_register(00,0f) write_register(07,70) [Reading 32 bytes 0 blanks] write_register(07,40) 27218: MAC Received id 0 from 00 to 00 type 0 27222: NET message 0000 27224: NET Enqueue @24 27289: MAC Network ACK fail from 012 via 02 on pipe 5 write_register(00,0f) write_register(07,70) 27290: NET Sending id 1 from 00 to 012 type 148 27293: NET message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 27301: MAC Sending to 012 via 02 on pipe 5 write_register(00,0e) write_register(02,3f) write_register(01,01) 27311: NET Pipe 5 on node 02 has address cccccc33e3 [Writing 32 bytes 0 blanks] write_register(01,00) write_register(00,0f) write_register(07,70) 27401: MAC Network ACK fail from 012 via 02 on pipe 5 write_register(00,0f) write_register(07,70) 27402: NET Sending id 1 from 00 to 012 type 148 27403: NET message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 27411: MAC Sending to 012 via 02 on pipe 5 write_register(00,0e) write_register(02,3f) write_register(01,01) 27421: NET Pipe 5 on node 02 has address cccccc33e3 [Writing 32 bytes 0 blanks] write_register(01,00) write_register(00,0f) write_register(07,70) 27511: MAC Network ACK fail from 012 via 02 on pipe 5 write_register(00,0f) write_register(07,70) id 1 from 00 to 012 type 0 Send Cmd - FAILED
I think this tells me what I already know that Node 0 has failed to get an acknowledgement from node 012 ?
This is from node 02:
Update: [Reading 32 bytes 0 blanks] write_register(07,40) 11741293: MAC Received id 12 from 00 to 012 type 148 11741297: NET message 0007 11741300: MAC Sending to 012 via 012 on pipe 5 write_register(00,0e) write_register(02,3f) write_register(01,3f) 11741309: NET Pipe 5 on node 012 has address cccc3c33e3 [Writing 32 bytes 0 blanks] write_register(01,3e) write_register(00,0e) write_register(02,3f) write_register(01,3f) 11741325: NET Pipe 2 on node 00 has address cccccccc33 [Writing 8 bytes 0 blanks] write_register(07,10) write_register(07,10) write_register(e1) write_register(01,3e) write_register(00,0f) write_register(07,70) [Reading 32 bytes 0 blanks] write_register(07,40) 11741379: MAC Received id 4 from 00 to 012 type 132 11741383: NET message 0007 11741386: MAC Sending to 012 via 012 on pipe 5 write_register(00,0e) write_register(02,3f) write_register(01,3f) 11741395: NET Pipe 5 on node 012 has address cccc3c33e3 [Writing 32 bytes 0 blanks] write_register(01,3e) write_register(00,0e) write_register(02,3f) write_register(01,3f) 11741411: NET Pipe 2 on node 00 has address cccccccc33 [Writing 8 bytes 0 blanks] write_register(07,10) write_register(07,10) write_register(e1) write_register(01,3e) write_register(00,0f) write_register(07,70) [Reading 32 bytes 0 blanks] write_register(07,40) 11741465: MAC Received id 12 from 00 to 010 type 148 11741470: NET message 0003 11741472: MAC Sending to 010 via 00 on pipe 2 write_register(00,0e) write_register(02,3f) write_register(01,3f) 11741483: NET Pipe 2 on node 00 has address cccccccc33 [Writing 32 bytes 0 blanks] write_register(07,10) write_register(07,10) write_register(e1) write_register(01,3e) write_register(00,0f) write_register(07,70) 0 ** NRF Network Updated **
A later msg I know, but fundamentally the same content everytime.
On node 012, this time, it started with:
Update: [Reading 32 bytes 0 blanks] write_register(07,40) 2851978: MAC Received id 3 from 00 to 012 type 132 2851982: NET message 0002 2851985: NET Enqueue @0 [Reading 32 bytes 0 blanks] write_register(07,40) 2851991: MAC Received id 1 from 00 to 012 type 132 2851995: NET message 0002 2851997: NET Enqueue @22 [Reading 32 bytes 0 blanks] write_register(07,40) 2852004: MAC Received id 1 from 00 to 012 type 148 2852008: NET message 0002 2852011: NET Enqueue @44 148 ** NRF Network Updated **
But then surprisingly went further with:
write_register(00,0e) write_register(02,3f) 2852176: NET Sending id 39 from 012 to 00 type 148 2852180: NET message 00 00 00 00 00 00 41 ab ae 14 00 00 00 00 41 48 a3 d7 00 00 00 00 00 02 2852189: MAC Sending to 00 via 02 on pipe 1 write_register(01,3f) 2852195: NET Pipe 1 on node 02 has address cccccc333c [Writing 32 bytes 0 blanks] write_register(01,3e) write_register(00,0f) write_register(07,70) write_register(00,0f) write_register(07,70) 2852287: NET Sending id 39 from 012 to 00 type 148 2852287: NET message 00 00 00 00 00 00 41 ab ae 14 00 00 00 00 41 48 a3 d7 00 00 00 00 00 02 2852294: MAC Sending to 00 via 02 on pipe 1 write_register(00,0e) write_register(02,3f) write_register(01,3f) 2852304: NET Pipe 1 on node 02 has address cccccc333c [Writing 32 bytes 0 blanks] write_register(01,3e) write_register(00,0f) write_register(07,70) write_register(00,0f) write_register(07,70) 2852397: NET Sending id 39 from 012 to 00 type 148 2852397: NET message 00 00 00 00 00 00 41 ab ae 14 00 00 00 00 41 48 a3 d7 00 00 00 00 00 02 2852404: MAC Sending to 00 via 02 on pipe 1 write_register(00,0e) write_register(02,3f) write_register(01,3f) 2852414: NET Pipe 1 on node 02 has address cccccc333c [Writing 32 bytes 0 blanks] write_register(01,3e) write_register(00,0f) write_register(07,70) write_register(00,0f) write_register(07,70) id 39 from 012 to 00 type 0 Send Cmd - FAILED
This time the child node actually received the correct transmitted data and my code sent back an answer, but as you can see, the NRF code still thinks it failed to 'Send'....
Are you able to test with the included helloworld_tx and helloworld_rx examples?
You would need to configure as follows: Radio 1:
const uint16_t this_node = 00; // Address of our node in Octal format (04, 031, etc)
const uint16_t other_node = 013; // Address of the other node in Octal format
Radio 2:
const uint16_t this_node = 03; // Address of our node in Octal format (04, 031, etc)
const uint16_t other_node = 00; // Address of the other node in Octal format
Radio 3:
const uint16_t this_node = 013; // Address of our node in Octal format (04, 031, etc)
const uint16_t other_node = 00; // Address of the other node in Octal format
It would help a lot to test with the included examples as it will rule out any coding issues on your part.
Ok, so after a lot of faffing about, I've got the Tx/Rx demo working as it should, setup for 00/04/014, and it seems to work fine, although I noticed that if I switch off 014, I still get an OK for the transmission, so I assume the OK, is reported because the 00>04 hop was successful and further child hops are not checked? because that seems to be the case. So whats been learned?, both RX units hardware and software seem to work fine. Tx hardware works fine, software using the Tx demo works fine except as mentioned above. I even setup a 00>04>014>0114>01114 and it still worked ok (node 00 is an ESP32, other nodes are mostly Arduino mega's using amplified version of nrf module, all using the 5v/3v daughter board)
However, still cant get the child nodes to run on my software...., still can't see whats the difference in my code dealing with sending/receiving code.... Wondering if response time has something to do, since just one hop (i.e. 00>04 ) works just fine, typical Rx code is running a cycletime of ~500milliseconds between network 'update'. Is there any setting that can increase the window for a positive response?
Apart from PALevel & datarate (min/1mpbs just now), should I configure any other settings?
On Sat, 29 May 2021 at 04:47, TMRh20 @.***> wrote:
Are you able to test with the included helloworld_tx and helloworld_rx examples?
You would need to configure as follows: Radio 1:
const uint16_t this_node = 00; // Address of our node in Octal format (04, 031, etc) const uint16_t other_node = 013; // Address of the other node in Octal format
Radio 2:
const uint16_t this_node = 03; // Address of our node in Octal format (04, 031, etc) const uint16_t other_node = 00; // Address of the other node in Octal format
Radio 3:
const uint16_t this_node = 013; // Address of our node in Octal format (04, 031, etc) const uint16_t other_node = 00; // Address of the other node in Octal format
It would help a lot to test with the included examples as it will rule out any coding issues on your part.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24Network/issues/173#issuecomment-850763067, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHMSOTADPY5HBFJ7MWQPKTTQBPTRANCNFSM45TATDZA .
typical Rx code is running a cycletime of ~500milliseconds between network
update.
You could call update() again during whatever code that takes ~500 ms to perform. But that would only help reduce the network latency.
Apart from PALevel & datarate (min/1mpbs just now), should I configure any other settings?
maybe increase the RF24Network::txTimeout or RF24Network::routeTimeout ??
Thanks, I'll give it a go.
Still noticed that even using the Tx/Rx demo, even with a child node switched physically off, I still get a Tx 'Ok' message that the packet was received ok. Surely this can't be right, since it negates the usefulness of the function??
Regards,
Bryan
On Mon, 21 Jun 2021 at 23:27, Brendan @.***> wrote:
typical Rx code is running a cycletime of ~500milliseconds between network update.
You could call update() again during whatever code that takes ~500 ms to perform. But that would only help reduce the network latency.
Apart from PALevel & datarate (min/1mpbs just now), should I configure any other settings?
maybe increase the RF24Network::txTimeout https://nrf24.github.io/RF24Network/classRF24Network.html#a8838b42717e7c9da37213b020db1f88c or RF24Network::routeTimeout https://nrf24.github.io/RF24Network/classRF24Network.html#a657fd03730b6c9084cc440b4fe0177c3 ??
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nRF24/RF24Network/issues/173#issuecomment-865385516, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHMSOVWBYSIR2FMFHRTET3TT64FFANCNFSM45TATDZA .
Hmm, this issue has gone unanswered for a while. Sorry about that.
Something is wrong if getting an OK message with a child node switched off, but beware : User message types 1 through 64 will NOT be acknowledged by the network, while message types 65 through 127 will receive a network ACK.