Can app level determine join failure and retry

WisBlock
#1

New to RAK WisBlock, using basic starter kit with quick start guide sample app.
I’m trying to better understand the join process. As part of this I am “purposely” causing a join failure.
If I define 5 join retries via
#define JOINREQ_NBTRIALS 5

Then as expected I do see the 5 tries. At that point the runtime gives up trying, which it should, but how is the device app level to know it needs to restart the join process.

The app level is waiting for a joined handler callback, which will not come, the runtime level is not going to keep trying as it’s exhausted the retry count.

The app level could interrogate lmh_join_status_get() to find out the “current” join status, but it has no way to tell if the runtime has exhausted the retry count or just taking a long time.

Other than using an arbitrary time limit, giving up on the join, and re-initializing everything, is that a way I’m not seeing for the app level to “know” the join has failed??
Any sort of best practice?

I’m sure it’s more of a question for the LoRaWAN library implementation than for the WisBlock per-say.
thanks

#2

I agree that there should be a callback when the number of join trials is exhausted. Will have a look into the lib next weekend. Hope it is easy to implement without breaking anything.

#3

Latest version of SX126x-Arduino library (V1.3.1) has a callback when OTAA join fails.
I updated one example to show the usage: LoRaWan

It might take one or two days before the update is available in ArduinoIDE and PlatformIO.

#4

Thanks for the work. I’ll let the rest of my community know.

#5

I’ve taken some time to verify the join call back, the callback seems to work fine.

However, I did notice a possible implementation concern, the mlmeConfirm->Status is not being set to reflect a join fail as one might expect.

On a successful join the mlmeConfirm->Status is set to 0,
LORAMAC_EVENT_INFO_STATUS_OK

On a fail the mlmeConfirm->Status is not set, rather left at 3
LORAMAC_EVENT_INFO_STATUS_RX1_TIMEOUT

One would expect 7, LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL

That said, I don’t know that it “really” matters. I don’t know :

  • if mlmeConfirm is intended to be interrogated at the device app level
  • if there is any status other than fail that could possibly be of interest/derived at the device app level in this case. Perhaps just the call back denoting the failure is all that we can get, no other status is of interest.

Just an FYI.

#6

@leroyle
Thank you for reporting this. I will ask our SW team to look into it.

#7

The LORAMAC_EVENT_INFO_STATUS_RX1_TIMEOUT is not a problem. The OnRadioRxTimeout function will be used by JOIN and Send Data, RX status cannot simply assign to LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL.

1 Like
#8

I was thinking it could be done at:
LoRaMac.cpp LIne ~ 1322

static void OnMacStateCheckTimerEvent(void)
{
...
      if (JoinRequestTrials >= MaxJoinRequestTrials)
     {       
         // set fail status here
        MlmeConfirm.Status = LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL;
        LoRaMacState &= ~LORAMAC_TX_RUNNING;
     }       
    else    
   {
       ...
    }

But, I do not pretend to know the ins and outs of the code, so I am fine with the current implementation as we do now have a fail callback.
Thank you for the quick turn around.

#9

Yes, add MlmeConfirm.Status = LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL in OnMacStateCheckTimerEvent works fine. if join not ok, it means failed, the reason is rx timeout or join failed.

#10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.