Software ack reponse too quick on nRF24
-
MySensors Version: 2.2.0
Hardware:- STM32 BluePill @72MHz (Serial) Gateway + any type of node
- nRF24 radios
What I'm doing: Bench marking different gateways (currently a STM32 Serial & Ehternet MQTT)
Problem Encountered: Sending loads of messages from the node to the gateway. Each message send from the node requests an ack'd from the gateway.
- When I Enable #define MY_DEBUG in the sketch everything works flawlessly and high message rates can be achieved without any loss of hardware (the automatic one from the nRF24 radio) or software acknowledge from the gateway.
- When I Remove #define MY_DEBUG in the sketch I suddenly have loads of messages which do not appear to receive a hardware or software acknowledge from the gateway.
Expected Cause:
- It appears that the automatic hardware ack from the gateway radio gets too little time to complete due to the requested software acknowledge to be transmitted. I.e. without the additional debug messages (=delay) present in the code a high clock speed microcontroller (like the STM32) is too fast in pushing a software ack to the radio before it can properly complete the hardware ack message.
According to the nRF24 datasheet (section 7.9) there must at least be 130us between the completion of the transmitted message and the hardware ack. response. On top of the 130us we also need some time to transmit the actual ack message. This total time must at < ARD (Auto Retransmit Delay), which is configures to be 1500us for MySensors.
So in MyTransport.cpp in transportProcessMessage just before the (void)transportSendRoute(_msgTmp) I added a delay of 1500uS and it all worked reliably again (successful hardware and software ack's and significant reduction of auto re-transmits of 16 times). This delay can actually be smaller than the 1500us as there is of course some time consumed by all the other tasks (still appeared to work properly with only 150us).
-
MySensors Version: 2.2.0
Hardware:- STM32 BluePill @72MHz (Serial) Gateway + any type of node
- nRF24 radios
What I'm doing: Bench marking different gateways (currently a STM32 Serial & Ehternet MQTT)
Problem Encountered: Sending loads of messages from the node to the gateway. Each message send from the node requests an ack'd from the gateway.
- When I Enable #define MY_DEBUG in the sketch everything works flawlessly and high message rates can be achieved without any loss of hardware (the automatic one from the nRF24 radio) or software acknowledge from the gateway.
- When I Remove #define MY_DEBUG in the sketch I suddenly have loads of messages which do not appear to receive a hardware or software acknowledge from the gateway.
Expected Cause:
- It appears that the automatic hardware ack from the gateway radio gets too little time to complete due to the requested software acknowledge to be transmitted. I.e. without the additional debug messages (=delay) present in the code a high clock speed microcontroller (like the STM32) is too fast in pushing a software ack to the radio before it can properly complete the hardware ack message.
According to the nRF24 datasheet (section 7.9) there must at least be 130us between the completion of the transmitted message and the hardware ack. response. On top of the 130us we also need some time to transmit the actual ack message. This total time must at < ARD (Auto Retransmit Delay), which is configures to be 1500us for MySensors.
So in MyTransport.cpp in transportProcessMessage just before the (void)transportSendRoute(_msgTmp) I added a delay of 1500uS and it all worked reliably again (successful hardware and software ack's and significant reduction of auto re-transmits of 16 times). This delay can actually be smaller than the 1500us as there is of course some time consumed by all the other tasks (still appeared to work properly with only 150us).
@technovation Good find en well described! :+1:
This seems serious enough to enter a bug report for it, so I did: https://github.com/mysensors/MySensors/issues/1134
