You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have run into some issues with ABP using the latest v5.0.0-branch code, and thought I'd run this by the community.
TL;DR: At what time is the mlme-confirm notification, associated with a successful mlme request for an ABP join, to be expected ?
For OTAA, the mlme confirm notification is received after successfully receiving the join reply; or after timing out.
For ABP, I would assume the mlme-confirm notification to be received likewise, ie, after successfully submitting the mlme request.
This behavior has changed for me recently, hence the question. Initially, I was using a v5.0.0-branch snapshot from around april 2022. I have just updated to the latest contents as of today and am getting some strange behavior.
With the original snapshot, I would call LoRaMacMlmeRequest(MLME_JOIN, ABP) and get a success status back. A bit later I'd call LoRaMacMcpsRequest() to actually transmit some data, and only at that stage I'd get both the mcps confirm and the mlme confirm notifications. The MAC is then ready to send more uplinks.
With the latest snapshot, I get neither mcps nor mlme confirm, and the MAC remains busy. Looking at a nearby analyzer, I can see uplinks being transmitted repetitively.
Is anybody else seeing the same (it might be specific to my port(*)) ?
Any guidance on when the mlme confirm notification should be delivered ?
(*) I am not excluding that this is specific to my port, as to avoid calling LoRaMacProcess() repetitively from the application code I am initiating it directly from the MacProcessNotify callback (duly decoupled from interrupts).
I have been troubleshooting this and have come up with a few leads.
On a first glance, the new behavior appears to be related to the change in LoRaMacHandleMlmeRequest() which somehow initiates a delayed transmission; reinstating the previous contents of that function gets back the original behavior.
Digging a bit further the (perceived) issue seems to originate in LoRaMacMlmeRequest(), at the time the request is submitted. There, for ABP activation, a call to OnMacProcessNotify() is made before the request is actually added to the LoRaMacConfirmQueue.
Moving that call to after the queue insertion, and only if (queueElement.ReadyToHandle == true), results in the desired mlme confirm notification, however the notification callback then occurs before the mlme request returns success status. which does not seem right.
Adding a mac timer (and maintaining the mac busy until the timer fired) results in the mlme-confirm notification to be delivered after the successful return from the mlme request.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
I have run into some issues with ABP using the latest v5.0.0-branch code, and thought I'd run this by the community.
TL;DR: At what time is the mlme-confirm notification, associated with a successful mlme request for an ABP join, to be expected ?
For OTAA, the mlme confirm notification is received after successfully receiving the join reply; or after timing out.
For ABP, I would assume the mlme-confirm notification to be received likewise, ie, after successfully submitting the mlme request.
This behavior has changed for me recently, hence the question. Initially, I was using a v5.0.0-branch snapshot from around april 2022. I have just updated to the latest contents as of today and am getting some strange behavior.
With the original snapshot, I would call
LoRaMacMlmeRequest(MLME_JOIN, ABP)
and get a success status back. A bit later I'd callLoRaMacMcpsRequest()
to actually transmit some data, and only at that stage I'd get both the mcps confirm and the mlme confirm notifications. The MAC is then ready to send more uplinks.With the latest snapshot, I get neither mcps nor mlme confirm, and the MAC remains busy. Looking at a nearby analyzer, I can see uplinks being transmitted repetitively.
Is anybody else seeing the same (it might be specific to my port(*)) ?
Any guidance on when the mlme confirm notification should be delivered ?
(*) I am not excluding that this is specific to my port, as to avoid calling
LoRaMacProcess()
repetitively from the application code I am initiating it directly from theMacProcessNotify
callback (duly decoupled from interrupts).I have been troubleshooting this and have come up with a few leads.
On a first glance, the new behavior appears to be related to the change in
LoRaMacHandleMlmeRequest()
which somehow initiates a delayed transmission; reinstating the previous contents of that function gets back the original behavior.Digging a bit further the (perceived) issue seems to originate in
LoRaMacMlmeRequest()
, at the time the request is submitted. There, for ABP activation, a call toOnMacProcessNotify()
is made before the request is actually added to theLoRaMacConfirmQueue
.Moving that call to after the queue insertion, and only if
(queueElement.ReadyToHandle == true)
, results in the desired mlme confirm notification, however the notification callback then occurs before the mlme request returns success status. which does not seem right.Adding a mac timer (and maintaining the mac busy until the timer fired) results in the mlme-confirm notification to be delivered after the successful return from the mlme request.
Beta Was this translation helpful? Give feedback.
All reactions