I’m implementing an end device with a RAK3172 (stand alone, not WisDuo Evaluation Board) in LoRaWAN mode AU915 (0-7 +64) band, using a ChirpStack V4 LNS. The device joins the network without any issues, transmits some packets correctly, but after a period of time that doesn’t depend on the amount of data or anything else I know, it stops sending. The monitor show the error message: +EVT:SEND_CONFIRMED_FAILED(4). The device remains joined to the network, as the downlink packets (queued from the LNS) arrive correctly.
This problem is reproduced in all the examples I was able to test with the RUI3 API.
A curious fact is that when the device works correctly, the monitor shows: [UPLINK] Send failed, however when it fails the message is: [UPLINK] Packet enqueued, size 4
I am currently using the RUI3-LowPower-Example example.
I would appreciate any guidance on how to resolve it.
I’m attaching the serial monitor output and LNS screenshots.
Context:
firmware RAK3172: AT+VER=RUI_4.2.1_RAK3172-E
IDE: VSC with arduino extension and RAKwireless RUI STM32 Boards by RAKwireless Version 4.2.1
BAND: AU915 (0-7 +64)
LNS: ChirpStack V4
10 seconds send interval (from your logs) is quite tough. The firmware might need some adjustments to deal with that.
If you need to send that often, the timer solution might not be the best. The MCU will not have much time to sleep anyway, so you can as well just use the loop, send, wait 10 seconds, check if last transmission is finished with a flag from the TX callback.
In general the RUI3 examples from the Best Practices are working well, I have some of them running since more than a month. But my send intervals are usually between 30 seconds and 10 minutes.
Thanks for your response, Bernd. It’s true, that time is very short, but it was only for testing purposes. I’m sorry I didn’t mention that earlier. I’ve tried times of 5, 10, and 30 minutes, and the system stops transmitting after a while. It seems that the time it remains transmitting is proportional to the transmission interval; that is, longer transmission interval, means longer the normal operation. I don’t have exact measurements but for a transmission period of 30 minutes the equipment normally transmitted for approximately 15 hours.
+EVT:SEND_CONFIRMED_FAILED(4) means you are using confirmed uplinks and the device didn’t receive the ACK.
The 10 seconds send interval, confirmed uplinks there could be a timing problem. If the first uplink does not receive an ACK, it will resend the packet. During that the timer might already try to send the next packet.
Are you switching between confirmed an unconfirmed packets?
I reported a problem to our R&D already that when switching between confirmed and unconfirmed packets, sending fails complete. Try to stay with confirmed or unconfirmed uplinks for now.
[UPLINK] Send failed could be related to above problem.
Bernd, thanks for your explanation.
I’m sending packets every 30 minutes with confirmed uplinks, and after approximately 10 hours, it stops transmitting (the device remains joined). I’m not switching between confirmed/unconfirmed uplinks.
On the other hand, when I send packets with unconfirmed uplinks (interval 30 sec or more), the device sends without problems (so far it’s been two days without interruption), however, the log continues reporting queuing fails ([UPLINK] Send failed) for all sends. In the server log, I can see that a few packets are lost from time to time, but the end device is still transmitting.
I need my system to work properly with confirmed uplinks. Since I’m using the example without changes, can you tell me if there is any special configuration that needs to be done in the LNS?
Thank a lot.
