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
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.
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.
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.
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.
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.