CalculateBackOff is called twice for delayed transmissions?

[jamesl-dm]

In the development branch, ScheduleTx calls CalculateBackOff each time a transmission is scheduled:

static LoRaMacStatus_t ScheduleTx( void )
{
    ...
    // Update Backoff
    CalculateBackOff( LastTxChannel );
    ...
    // Schedule transmission of frame
    if( dutyCycleTimeOff == 0 )
    {
        // Try to send now
        return SendFrameOnChannel( Channel );
    }
    else
    {
        // Send later - prepare timer
        LoRaMacState |= LORAMAC_TX_DELAYED;
        TimerSetValue( &TxDelayedTimer, dutyCycleTimeOff );
        TimerStart( &TxDelayedTimer );

        return LORAMAC_STATUS_OK;
    }
}

It looks like if there is no available channel and the transmission is delayed, ScheduleTx will be called a second time. CalculateBackoff would then be called a second time, resulting in AggregatedTimeOff being incremented twice instead of once?

[jamesl-dm]

After further examination of the MAC, it looks to me like ScheduleTx is designed to be called more than once per actual transmission, and the real issue is that some of the functions it calls aren't designed this way.

• The update of AggregatedTimeOff in CalculateBackoff should probably be an assignment rather than an increment.
• Calling RegionNextChannel shouldn't result in the RemainingChannelMask variables in the AU915 and US915(-hybrid) regions being modified to mark the channel as used. They can be modified in their TxConfig functions instead, once the stack is certain that it means to use the channel immediately.

[djaeckle]

Hi jamesl-dm,

we will analyze your issue and will come back to you.

[djaeckle]

Hi jamesl-dm,

The update of AggregatedTimeOff in CalculateBackoff should probably be an assignment rather than an increment.

I think this is an issue. We will provide as soon as possible.

[djaeckle]

Hi jamesl-dm,

this issue is on the roadmap for the next release:

https://github.com/Lora-net/LoRaMac-node/wiki/LoRaMAC-node-Roadmap

[djaeckle]

Hi jamesl-dm,

Calling RegionNextChannel shouldn't result in the RemainingChannelMask variables in the AU915 and US915(-hybrid) regions being modified to mark the channel as used. They can be modified in their TxConfig functions instead, once the stack is certain that it means to use the channel immediately.

I think we set them as used. We do only mark a channel as used, if we have found a valid channel. If we have found a valid channel, the MAC will transmit a frame directly afterwards.

[jamesl-dm]

Ok - I must have misread it. Thanks.