LoRaWAN_End_Node : Incomplete error handling in SendTxData function

[asob]

The error handling code below does not cover all the error scenarios in case LmHandlerSend fails to emit payload.

LmHandlerSend

  if (LORAMAC_HANDLER_SUCCESS == LmHandlerSend(&AppData, LORAWAN_DEFAULT_CONFIRMED_MSG_STATE, &nextTxIn, false))
  {
    APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST\r\n");
  }
  else if (nextTxIn > 0)
  {
    APP_LOG(TS_ON, VLEVEL_L, "Next Tx in  : ~%d second(s)\r\n", (nextTxIn / 1000));
  }

The intention behind this piece of code is understandable, if LmHandlerSend fails to emit payload due to Duty Cycle restriction the user will be notified and can take appropriate action. I've tested exactly this scenario by forcing the device to operate under fixed DR and spamming the LmHandlerSend with data more rapidly than the duty cycle restriction, the code actually never hits the else if part.

This is actually visible from within the LmHandlerSend which may return an error quite immediately before event modifying the supplied nextTxIn pointer.

What actually happens is LmHandlerSend may return an error first with nextTxIn = 0 which is not caught by the code above, but on the next call will emit an nextTxIn with value above zero.

I believe that the code above should be modified to

  if (LORAMAC_HANDLER_SUCCESS == LmHandlerSend(&AppData, LORAWAN_DEFAULT_CONFIRMED_MSG_STATE, &nextTxIn, false))
  {
    APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST\r\n");
  }
  else
  {

    if ( nextTxIn == 0 )
      APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST FAILED\r\n");
    else
      APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST FAILED, next tx in : ~%d seconds\r\n",
        nextTxIn / 1000 );
  }

This will capture any possible error scenario from LmHandlerSend return code

[ASELSTM]

ST Internal Reference: 121455

[ALABSTM]

Hi @asob,

According to our development teams, the Semtech Stack introduced an updated API for the sending function in its version 4.5.2. The STM32CubeWL v1.2.0 is now aligned with this change.

With regards,