sequence of callback calls

[nestorayuso]

I am using release v4.4.0 Class-A REGION_EU868 unconfirmed uplink
I want to know when the LoRaMac stack is idle after a TX and both RX windows to reconfigure the radio for use with another radio protocol.

In Release v.4.3.2 I used the MCPS-Confirm callback because it got fired after the RX2 window. But in v4.4.0 it is fired just after TX.
I am trying to fix it using a combination of MCPS-Indication callback if there was downlink data and (McpsConfirm->Status == LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT) if there was not downlink. But LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT is only fired if using Confirmed TX.

Is there any documentation on when is fired each Indication or Confirm event and in what order?

[djaeckle]

Hi nestorayuso,

thanks for your report and sorry for the late response. Actually, both versions should be working similar. The MAC follows the Request-Confirm and Indication-Response principle. If you are performing an MCPS-Request (e.g. an uplink) you will first receive aMCPS-Confirm primitive. It provides the status of the operation. It might also happen, that you receive a frame. If so, the MAC will generate an indication which your upper layer may process. There is a small chapter in the doxygen documentation about this procedure.

Regarding your issue: I was able to reproduce it once. We need some more time to identify the reason for it.

[djaeckle]

Hi nestorayuso,

sorry for the delay. I think I was able to reproduce the issue. I could identify the following cases, where it could happen:

1. When there is an RX timeout in window 1 and the time to open up window 2 has already been elapsed. In this case, we missed to stop the second window timer which may lead to issues.
2. In class C mode when the node performs unconfirmed uplinks and received a valid downlink from the network server. In this case we didn't stopped the AckTimeoutTimer which may lead to the same issue.

We have already a fix in our local repository and its under test currently. We will provide the fixes as soon as it has passed all our tests.

[djaeckle]

Hi nestorayuso,

we have provided a fix for it. Does it resolve your issue?

[nestorayuso]

I am testing it, but my case is in class-a, not class-c

[mluis1]

Can we close this issue?

[nestorayuso]

yes, can close, but i would apreciate some kind of documentation on when it is fired every callback and the order or sequence of them.

[djaeckle]

Hi nestorayuso,

thanks for your feedback. We will take your proposition into account.