Class A confirmed message flow

I’ve got a Class A node that is sending a CONFIRMED message. LoRa app and network are version 2.6.0.
I observe the following message flow:

  1. End node sends ConfirmedDataUp
  2. The network server sends UnconfirmedDataDown
  3. End node doesn’t not receive the UnconfirmedDataDown immediately and then retries to send the ConfirmedDataUp
  4. Upon sending the second ConfirmedDataUp it receives the confirmation

Unfortunately the End Node will send two copies of its data when using confirmed message.

Is that normal?
Why the End node is not receiving the confirmation in the first rx window of first uplink transmission?
The “immediately” flag set to false in the UnconfirmedDataDown has something to do with the fact that confirmation is only recevied upon second uplink transmission of the End node?

See the log here:

“immediately” being false means that the packet will be sent on the indicated count of the gateway’s rolling microsecond counter in the “timestamp” field, rather than as soon as it reaches the SX1301 chip if immediately is true. This is typically how all traffic in time-coordinated receive windows is sent, at least unless GPS-based timing is used.

What’s a little odder is why two uplink packets with the same fcnt are being accepted and processed; normally the 2nd would be rejected. Do you have uplink rollback protection off?

That still leaves unanswered why the first downlink is being missed, this might have to do with node firmware behavior. Can you add a serial debug log to the node firmware so you can tell when it operates the radio in receive mode, and with what settings?

Yes, I have checked: “Disable frame-counter validation”.

I checked what happens in the two windows Rx1 and Rx2 and this is the log:

HW Send frame 18 bytes
rxTimeOut on Window 1
rxTimeOut on Window 2

HW Send frame 18 bytes (retry)
Confirmation got on Window 1

It is very strange that I receive the confirmation always on second attempt, it seems like the gateway is getting the Confirmation message to send (from NS) too late.

That is a possibility, yes, especially if your network has some latency. Does your gateway’s concentrator card have a transmit LED or signal (often related to the operation of the T/R switch)? It can be interesting to modify node firmware to toggle a GPIO when it enters and exits receive mode, and watch the gateway’s transmit signal in relation to this.

I’d also be tempted to make the node firmware log the frequency and spreading factor in use when it enters receive mode for comparison to the packet logs, and to make it distinctly indicate radio reception vs. only successful packet decoding, so you see anything that is rejected due to corruption, frame counter, etc.