Tx confirmed messages hanges, while receiving Class C Multicast

[DaniKoller]

When sending confirmed messages (from several nodes) at same time the nodes will go back in to Idle State (LoRaMacState is MAC_IDLE) after a while (when all the retransmission is done). But when the concentrator sends concurrently unconfirmed messages to a multicast address (to all nodes), the nodes state machine will hange on some nodes -> LoRaMacState is MAC_TX_RUNNING and the timer TxTimeout is no more running. I tried with 10 nodes (V4.0.0 Stack) and one concentrator.

[djaeckle]

Hi DaniKoller,

thanks for the report. Could you provide more details please?

1. What do you mean by concurrently?
2. Does the node receive the multicast successfully?
3. Does the node send the frame successfully, before it stays in state MAC_TX_RUNNING?

Thanks in advance.

[DaniKoller]

Hi,

1. I use the IMST ExpLoRa-Studio and send ClassC unconfirmed messages (by Button) during the confirming (concentrator) and retransmission (slave) communication.
2. Mostly all Nodes will receive the multicast, but sometimes not all (but that is ok i will send multicast 3 times in a short Interval 2..5s and in a long interval). When a node is in hanging state, the multicast is still working (indicating 1s before the other nodes).
3. The Concentrator side show also the confirm was ok, but the node never make a ConfirmCallback.

This attachment is done by only 1 node :

best regards
Daniel

[djaeckle]

Hi Daniel,

first of all, thanks for the feedback and the log. I'm not familiar with the IMST ExpLoRa-Studio, but what I understood from the log is the following ( please correct me, if I'm wrong ):

1. Node sends a frame
2. Server answers with an Ack frame
3. Sever sends multicast frames

I guess the issue occurs when the node receives frame number 407. I noticed that the timestamps of 406 and 407 are equal. So I assume, that the server sends 407 immediatly after frame 406.

I think this issue occurs, when the node receives frame 406 and frame 407 in sequence, without handling frame 406 in the event handler in between. In this case, frame 407 overwrites the internal state and the "Ack received" status of the previous frame status is lost.

However, to be 100% sure, it would be nice, if you could validate, if the following patch resolves the issue. Please add the function call

OnMacStateCheckTimerEvent( );

at the end of the function OnRadioRxDone. Please note, that this patch might not be the final solution to solve the issue - its for testing purposes only and might change in the next release.

[DaniKoller]

Hi Daniel,

thanks a lot, it seems to work with the patch ..

INFO : I guess the ExpLoRaStudio TimeStamps are not the real sending time on the concentrator

kind regards
Daniel