What happens exactly after NRF24 gives up retrying and goes to sleep 2.3.x?

[mfalkvidd]

I'd say they are still valid. There haven't been much changes to MySensors during this time, especially not regarding resend.

By default, a nrf24 node will retry sending a single message 15 times yes. Source: https://github.com/mysensors/MySensors/blob/dd91aeb9c30dbd658bd02c34445669a7cd996c0f/hal/transport/RF24/driver/RF24registers.h#L47

The whole transport state machine is a whole lot more complex than that though; way beyond my knowledge. Hopefully someone with more insight can explain.

[Yveaux]

@mfalkvidd the transport statemachine is not involved in retrying, as this is purely done by the nrf24 radio. The ARC and ARD values determine the amount of retries before giving up and the time in between retries.
I did some experiments in the past and saw maximum retries of 2..3 times, or giving up after 15. This means retrying for more than 3 times nearly always fails, and doesn't make much sense.

[grumpazoid]

Thanks for the replies and info.

@Yveaux are you saying if the node did not achieve success after 2 or 3 attempts it would carry on and reach its limit of 15 attempts - then give up. i.e. it would never achieve a successful transmit at say attempt 10 or 11?

I may have do do some testing and experiments myself with a node connected to a laptop in debug mode.

[mfalkvidd]

@Yveaux sorry for being unclear. I know that the state machine is not involved in retrying sending a single message. But grumpazoid is asking "At what point after wake up will the node try and establish communication again" which does involve the state machine.

[Yveaux]

@grumpazoid said in What happens exactly after NRF24 gives up retrying and goes to sleep 2.3.x?:

it would never achieve a successful transmit at say attempt 10 or 11?

No, I mean in practice I've seen that if it fails after 3 attempts it will keep failing until giving up.

[grumpazoid]

@Yveaux Thanks. Yes behaviour is strange.
PIR messages that wake via interrupt seem to kick a node back into life somehow. Maybe because they are keeping it awake for communication to establish again?

[grumpazoid]

I have cobbled together a simple test sketch that sends alternating values to the gateway every x seconds - Attached below (feel free to correct bad coding).

Are we saying that when I get a NACK response in the serial monitor such as :

37315 !TSF:MSG:SEND,9-9-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=NACK:20

That the sending radio has attempted to send its message AND listened for, but not heard, a response from the gateway 15 times?

I say this because what I observe is the code moving on to send the next message in the sequence.

// Enable debug prints
#define MY_DEBUG
#define MY_PARENT_NODE_ID 0
#define   MY_PARENT_NODE_IS_STATIC // dont allow search for repeater
// Enable and select radio type attached
#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95
#include <MySensors.h>
#include <SPI.h>

#define SENSOR_INFO "Test sensor"
//#define NODE_ID 200
#define CHILD_ID 1
int STATE = 10;

 
// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);
 
void setup() 
{ 
  //begin(NULL, NODE_ID, false);
  sendSketchInfo(SENSOR_INFO, "1.1");
  present(CHILD_ID, S_DOOR); 
}
 
void loop()
{
  
   if (isTransportReady())
    {
        //  uplink OK
         Serial.println ("Tranport Ready");  
    }
         
   send(msg.set(STATE)); 
   
  #ifdef MY_DEBUG
  Serial.println(STATE);
#endif;

// Change state ready for next time
    if (STATE==10) { 
     (STATE=20); 
      }
    else if (STATE==20){
    (STATE=10) ;
    } 

 
   
    //pause
     delay(5000); // Wait 5 seconds
   
}

[mfalkvidd]

@grumpazoid if you by ”response” mean the nrf24 hardware acknowledgement, then yes. Your description is correct.

I’m asking because response could mean many things. For example, the gateway could have code in its receive() that sends a new MySensors message in response.

[grumpazoid]

@mfalkvidd Thanks. Yes that is indeed what I mean. I just wanted to make sure my understanding was correct before going any further. I am over obsessing really but it is now a bit of a challenge. I went about 24hrs without a a single missed message then just a couple of hours ago started getting lots. I am of course guessing as some local interference being the most likely. Will try another channel number when I can. I have however found a couple of errors in my sketches that need changing - I have been using delay instead of wait and also I have been pointlessly sending some serial prints.

[grumpazoid]

On my test node I have enabled Echo and am using if (message.isEcho())
It is working.

I have searched and searched and looked at the API docs but am still unclear :

If the node sends a value, should it be able to read that same value back in the echoed message.

I know I can use message.sender , message.type etc, but how would I print the whole echoed message and/or the echoed value.