NRF24 Radio Recouperation feature
-
I have found that in order to keep my radios happy, it's best to give them a little time to catch their breath between transmissions.
Recently, while trying to get the RF-Nano to work, I also discovered something that many others had before me: some hardware will work with MySensors 2.0, but not with the latest version.
One explanation is that newer versions of MySensors communicates back and forth more at boot. This can overwhelm some NRF24 radios.
My proposal is to add a new feature that simply always adds a small recuperation delay between each use of the radio. I don't mind the communication being slower if it makes the hardware work.
I hope that in some cases this may alleviate the need to solder on extra capacitors.
-
I have found that in order to keep my radios happy, it's best to give them a little time to catch their breath between transmissions.
Recently, while trying to get the RF-Nano to work, I also discovered something that many others had before me: some hardware will work with MySensors 2.0, but not with the latest version.
One explanation is that newer versions of MySensors communicates back and forth more at boot. This can overwhelm some NRF24 radios.
My proposal is to add a new feature that simply always adds a small recuperation delay between each use of the radio. I don't mind the communication being slower if it makes the hardware work.
I hope that in some cases this may alleviate the need to solder on extra capacitors.
-
@alowhum https://github.com/mysensors/MySensors/issues/892 might be relevant
@mfalkvidd Yes it does sound relevant. I noticed a 2.4 label. Is this being worked on?
-
@mfalkvidd Yes it does sound relevant. I noticed a 2.4 label. Is this being worked on?
-
@mfalkvidd thanks.
Would you perhaps have any suggestion as to how the radio could be alleviated a little bit, outside of setting a fixed node ID?
-
@mfalkvidd thanks.
Would you perhaps have any suggestion as to how the radio could be alleviated a little bit, outside of setting a fixed node ID?
@alowhum a debug log should show most of the communication (except nrf24's automatic/hardware repeat), so by looking at such a log it should be possible to understand what is happening, and, depending on the use case, it might be possible to change the sketch (or the library) to optimize for that use case.
-
I tried to get some debug log data, and behold, the node started working in verbose debugging was on.
https://forum.mysensors.org/topic/10327/rf-nano-nano-nrf24-for-just-3-50-on-aliexpress/27
Perhaps the debugging to serial slows things down enough to give the radio some breathing room?
-
I tried to get some debug log data, and behold, the node started working in verbose debugging was on.
https://forum.mysensors.org/topic/10327/rf-nano-nano-nrf24-for-just-3-50-on-aliexpress/27
Perhaps the debugging to serial slows things down enough to give the radio some breathing room?
@alowhum MY_DEBUG is sufficient to see which messages are sent.
And yes, the slowdown caused by printing to the serial console can slow down the node sufficiently. There have been some reports in this forum and on github. One example: https://github.com/mysensors/MySensors/issues/614
-
@alowhum MY_DEBUG is sufficient to see which messages are sent.
And yes, the slowdown caused by printing to the serial console can slow down the node sufficiently. There have been some reports in this forum and on github. One example: https://github.com/mysensors/MySensors/issues/614
@mfalkvidd said in NRF24 Radio Recouperation feature:
And yes, the slowdown caused by printing to the serial console can slow down the node sufficiently
This would play into the idea of creating a feature to purposefully slow things down. Shall I make a feature request on Github?
-
@mfalkvidd said in NRF24 Radio Recouperation feature:
And yes, the slowdown caused by printing to the serial console can slow down the node sufficiently
This would play into the idea of creating a feature to purposefully slow things down. Shall I make a feature request on Github?
