Closed 2bndy5 closed 2 years ago
@TMRh20 I'm having trouble getting this lib's mesh node receiving the address response message (type 128) from your lib's mesh master. I believe its because Circuitpython is so much slower than your C++ lib; I suspect the radio (with CirPy) isn't switching from TX to RX mode fast enough (& the message type 128 doesn't take advantage of the radio's auto-retries).
I noticed you recently commented out a pre-existing delay(2)
in this commit. I was wondering if you'd be open to adding it back in conditionally with a macro like SLOW_ADDRESS_RESPONSE
(or maybe PATIENCE_FOR_RETARD_CHILD_NODES
😆 ).
Yeah, if it tests ok with the delay that should be ok to add.
On Jul 10, 2021, at 3:05 AM, Brendan @.***> wrote:
 @TMRh20 I'm having trouble getting this lib's mesh node receiving the address response message (type 128) from your lib's mesh master. I believe its because Circuitpython is so much slower than your C++ lib; I suspect the radio (with CirPy) isn't switching from TX to RX mode fast enough (& the message type 128 doesn't take advantage of the radio's auto-retries).
I noticed you recently commented out a pre-existing delay(2) in this commit. I was wondering if you'd be open to adding it back in conditionally with a macro like SLOW_ADDRESS_RESPONSE (or maybe PATIENCE_FOR_RETARD_CHILD_NODES 😆 ).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I just confirmed the RF24Mesh master node's code works (no saving/loading DHCP dict
to/from NVM as yet).
I have been able to get RF24Mesh child nodes (running on RP2040 MCU) to connect to C++ RF24Mesh master node (running on RPi), but it seems unreliable... I think printing all the debug stuff to stdout significantly slows everything down (and CirPy is already the slowest). RF24Mesh on RPi (using this lib not the C++ lib) works much better as a child node when most debug output is removed, but that's using SpiDev
python C-extension for faster SPI transactions (which is also faster than CirPy on my RP2040 board).
@TMRh20 I added a commit that introduces the new macro SLOW_ADDR_POLL_RESPONSE
in RF24Network (& subsequently used in RF24Mesh). It seems to help when the macro is set to add a 12 millisecond delay on responses to ADDR_REQUEST and NETWORK_POLL to MULTICAST_ADDR scenarios. By default, this macro doesn't affect normal builds; it needs to be defined by the user in _RF24Networkconfig.h:
#define SLOW_ADDR_POLL_RESPONSE 12
I am still looking for ways to improve the speed of my lib here, but I'm running out of ideas. I even use the mandatory 130 us delay time to write RX pipe0 address when entering RX mode (CE pin is set HIGH).
Ok, thanks for the heads up
On Jul 27, 2021, at 4:31 PM, Brendan @.***> wrote:
 @TMRh20 I added a commit that introduces the new macro SLOW_ADDR_POLL_RESPONSE in RF24Network (& subsequently used in RF24Mesh). It seems to help when the macro is set to add a 12 millisecond delay on responses to ADDR_REQUEST and NETWORK_POLL to MULTICAST_ADDR scenarios. By default, this macro doesn't affect normal builds; it needs to be defined by the user in RF24Network_config.h:
define SLOW_ADDR_POLL_RESPONSE 12
I am still looking for ways to improve the speed of my lib here, but I'm running out of ideas. I even use the mandatory 130 us delay time to write RX pipe0 address when entering RX mode (CE pin is set HIGH).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Work is being done on the rf24-network branch to port the Arduino/Linux library RF24Mesh for CircuitPython. testing this module will also satisfy some of the testing objectives set fourth in #28
I do plan on using CircuitPython's
nvm
module to store the addresses assigned by the master node... This is because write-access to the CircuitPython filesystem is prohibited by default.