port RF24Mesh

[2bndy5]

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.

[2bndy5]

@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 😆 ).

[TMRh20]

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.

[2bndy5]

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).

[2bndy5]

@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).

[TMRh20]

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.