Band TimeOff computed even if DutyCycle disabled

[clmklk]

Hello,

I am currently using the version 4.4.0 of the stack. My issue is that in certain case transmissions are delayed even if the Dutycycle is disabled.

I dug up and it seems that the Band TimeOff is computed in the function RegionCommonCalcBackOff when Join Requests are sent successively, once again even if the DutyCycle is disabled.

I don't understand this condition into the function:

       // Reset the timeoff if the last frame was not a join request and when the duty cycle is not enabled
        if( ( calcBackOffParams->DutyCycleEnabled == false ) && ( calcBackOffParams->LastTxIsJoinRequest == false ) )
        {
            // This is the case when the duty cycle is off and the last uplink frame was not a join.
            // This could happen in case of a rejoin, e.g. in compliance test mode.
            // In this special case we have to set the time off to 0, since the join duty cycle shall only
            // be applied after the first join request.
            calcBackOffParams->Bands[bandIdx].TimeOff = 0;
        }
        else
        {
            // Apply band time-off.
            calcBackOffParams->Bands[bandIdx].TimeOff = calcBackOffParams->TxTimeOnAir * dutyCycle - calcBackOffParams->TxTimeOnAir;
        }

The Band TimeOff shouldn't be reset if the DutyCycle is disabled ?

If this is a real issue, I can provide a patch.

Regards

[bhtalexis]

Hi clmklk,

This is the expected working !

You are in a special case named "Back-off" with the JoinRequest command. The aim is to avoid overload situation of the network by devices sending JoinRequest in loop. Please see § 7 Retransmissions back-off of the LoRaWAN 1.0.2 specification

Best regards

[clmklk]

Hello bhtalexis,

Thank you for your answer. Indeed I missed this part of the spec. I close the ticket.

Regards