Confirmed uplink ACK's are not reliable

[sslupsky]

I have some more information regarding the underlying cause of this issue.

I think there is a problem with the confirmed packet ACK's. From what I can see so far, the module AT_Slave firmware sends the "+ACK" string to the UART any time it receives something from a downlink. My expectation was that this message is only sent when the module receives a LoRaWAN ACK. Here is the code:

                    if( ( RadioEvents != NULL ) && ( RadioEvents->RxDone != NULL ) )
                    {
                        RadioEvents->RxDone( RxTxBuffer, SX1276.Settings.LoRaPacketHandler.Size, SX1276.Settings.LoRaPacketHandler.RssiValue, SX1276.Settings.LoRaPacketHandler.SnrValue );
                        PRINTF( "+ACK\r" );
                        //PRINTF("+RECV=");
                    }

I am not certain yet I understand fully all of the implications of this but I think this sheds some additional light on the #39, #54 issues reported here. Moreover, I think I understand now why sending another packet generates a +ACK since it is not really a LoRaWAN ACK that causes it. I have determined that waitResponse() receives the +ACK string from the module [b]even when the downlink packet's ACK bit is set to false[/b]. This mistakenly causes you to think that the packet was received by the server and confirmed when in fact that conclusion cannot be made.

I have not figured out why firmware sends a frame with an empty payload when the ACK is not received.

[sslupsky]

I looked further into this. Is the McpsConfirm() function the correct place to send the "+ACK" response to the application?

I've worked with the code a bit and I have not been able to observe the MKRWAN automatically retransmit a confirmed uplink if it does not receive an ACK. I think this is supposed to happen automatically. Was this functionality turned off in the AT_Slave firmware somehow?