RAK4630 Confirmation Packets

LPWAN Modules / EVBs
1

Device : RAK4630
RUI version : RUI_4.2.1_RAK4631

I find that using api.lorawan.send() to check for confirmation that packet is confirmed is not working for the FIRST packet that gets dropped.

void loop()
{
   static uint8_t loop_cntr = 0;
    uint8_t payload[] = "example";

   loop_cntr++;
   Serial.println(loop_cntr);
   
    if (api.lorawan.send(sizeof(payload), payload, 129, true, 1)) {
        Serial.println("Send Success");
    } else {
        Serial.println("Send fail");

    }

    delay(15000);
}

My debug output is :

image

I switched OFF the LORA Gateway just before message 7 was send out…yet at 22:55:26.436 I get “send success”…even the RUI stack printed +EVT:SEND_CONFIRMED_FAILED(4)…but api.lorawan.send() returned all good.
Subsequent messages shows “Send Fail”, which is correct. I find it that the very first message that is suppose to be lost shows as “Send Success”

What is the best practice to make sure I check for successful delivery?

2

Already reported to R&D
RUI3 V4.2.2 with fix is in testing and will be released soon.

3

Thanks, that is great to hear.

Question; how does the api.lorawan.send() get a result so quickly, yet the +EVT:SEND_CONFIRMED_OK is only printed 7 seconds later?

Is it possible that I can somehow check for the +EVT message instead of relying on the api.lorawan.send() function ?

4

The result of api.lorawan.send() is only showing that the uplink could be successfully enqueued. It does not mean that the packet is actually sent out.
The +EVT: messages are telling whether the uplink was transmitted.
Best is to use the callbacks that RUI3 provides for TX finished, RX data received, Join request result

5

Thanks, what do you suggest, something like :

  1. In TX callback, start oneshot timer ( say 10 seconds )
  2. If the RX callback hasnt fired, by the time the timer expired (runs), then assume no confirmation?
6

RX callback will only be called if there is data from the LNS, could be a downlink packet or just a MAC command (fPort == 0)

TX callback is always called after TX/RX cycle finished.
You get the TX result from the status of the callback void sendCallback(int32_t status)
Example:

void sendCallback(int32_t status)
{
	MYLOG("TX-CB", "TX status %d", status);
	// digitalWrite(LED_BLUE, LOW);
	tx_active = false;

	if (status != RAK_LORAMAC_STATUS_OK)
	{
		cfm_error += 1;
	}
	switch (status)
	{
	case RAK_LORAMAC_STATUS_OK:
		MYLOG("TX-CB", "Service performed successfully");
		break;
	case RAK_LORAMAC_STATUS_ERROR:
		MYLOG("TX-CB", "An error occurred during the execution of the service");
		break;
	case RAK_LORAMAC_STATUS_TX_TIMEOUT:
		MYLOG("TX-CB", "A Tx timeout occurred");
		break;
	case RAK_LORAMAC_STATUS_RX1_TIMEOUT:
		MYLOG("TX-CB", "An Rx timeout occurred on receive window 1");
		break;
	case RAK_LORAMAC_STATUS_RX2_TIMEOUT:
		MYLOG("TX-CB", "An Rx timeout occurred on receive window 2");
		break;
	case RAK_LORAMAC_STATUS_RX1_ERROR:
		MYLOG("TX-CB", "An Rx error occurred on receive window 1");
		break;
	case RAK_LORAMAC_STATUS_RX2_ERROR:
		MYLOG("TX-CB", "An Rx error occurred on receive window 2");
		break;
	case RAK_LORAMAC_STATUS_JOIN_FAIL:
		MYLOG("TX-CB", "An error occurred in the join procedure");
		break;
	case RAK_LORAMAC_STATUS_DOWNLINK_REPEATED:
		MYLOG("TX-CB", "A frame with an invalid downlink counter was received. The downlink counter of the frame was equal to the local copy of the downlink counter of the node.");
		break;
	case RAK_LORAMAC_STATUS_TX_DR_PAYLOAD_SIZE_ERROR:
		MYLOG("TX-CB", "The MAC could not retransmit a frame since the MAC decreased the datarate. The payload size is not applicable for the datarate.");
		break;
	case RAK_LORAMAC_STATUS_DOWNLINK_TOO_MANY_FRAMES_LOSS:
		MYLOG("TX-CB", "The node has lost MAX_FCNT_GAP or more frames.");
		break;
	case RAK_LORAMAC_STATUS_ADDRESS_FAIL:
		MYLOG("TX-CB", "An address error occurred");
		break;
	case RAK_LORAMAC_STATUS_MIC_FAIL:
		MYLOG("TX-CB", "Message integrity check failure");
		break;
	case RAK_LORAMAC_STATUS_MULTICAST_FAIL:
		MYLOG("TX-CB", "Multicast error occurred");
		break;
	case RAK_LORAMAC_STATUS_BEACON_LOCKED:
		MYLOG("TX-CB", "Beacon locked");
		break;
	case RAK_LORAMAC_STATUS_BEACON_LOST:
		MYLOG("TX-CB", "Beacon lost");
		break;
	case RAK_LORAMAC_STATUS_BEACON_NOT_FOUND:
		MYLOG("TX-CB", "Beacon not found");
		break;
	}
}
7

Yes that is how I understand it too.

Problem is the same, void sendCallback(int32_t status) is not reporting the FIRST packet that gets dropped, only from the 2nd packet onwards is it reporting correctly.

First dropped packet still has status = 0.

8

Did you switch back to RUI3 V4.1.1?

As I mentioned here RAK4630 Confirmation Packets - #2 by beegee RUI3 V4.2.1 has a bug with confirmed packets.

9

Im using 4.2.1, it wasnt clear from the post that it was a bug specifically in V4.2.1.

I’ll try to downgrade then while waiting for V4.2.2

Thanks!!