Server: Chirpstack v4.15.0
Gateway: Chirpstack Gateway OS v4.9.0, Seeed WM1302 Attached to Raspberry Pi 5
RAK3172 is operating in Class B (Class B S:2)
When I schedule “Confirmed Downlink” from the Chirpstack server, it gets queued, I get a TX_ACK response (which confirms gateway accepted the packet and put it into the JIT), Then I receive the message I sent in RAK3172 Terminal. However, the RAK3172 never sends the ACK message back to the server, so the packet remains in the chirpstack queue forever.
Now, there are 2 different behaviours that I find confusing:
As soon as I send an uplink, the previously queued downlink message in the chirpstack gets confirmed. I believe that’s because RAK3172 sets the ACK bit within the next uplink message I send.
As soon as I queue another confirmed downlink, I receive the ACK back from the RAK3172, for the previous message that was waiting in queue for forever. And then the new message remains in the queue without ACK. If I send unconfirmed downlink however, I get the ACK back for the previous packet again, and the unconfirmed packet get cleared off the queue without issue as it only needs the TX_ACK from the gateway and nothing else.
I couldn’t find any documentation regarding this kind of behaviour. Am I supposed to handle the ACK within the application layer?
Notice how the ack packets arrived right the moment new txack was received (when a new downlink queued and sent to the gateway from chirpstack). If I don’t follow a confirmed downlink with any kind of uplink or downlink, that one message remains unconfirmed indefinitely
Your behavior is expected for LoRaWAN when it comes to confirmed downlinks. When device sends an uplinks, it opens up the RX windows to receive the downlink (standard Class A). After that, if there is no pending uplink, the ACK will be floating until you send another uplink.
I haven’t tried this on Class B but the device must send an uplink (even empty) once it received the confirmed downlink. Else, the LNS will assume that the confirmed downlink fails.
Hey Carl, thank you for your response!
So the acknowledgement is handled purely by the userspace instead of the LoRaWAN stack embedded in RAK3172?
How come another downlink (whether confirmed or not) causes LNS to receive an ACK for the previous confirmed downlink? I don’t observe any Uplink within the “Events” or “LoRaWAN Frames” tabs in Chirpstack
However, on Class B, it can be that the downlink operation is having conflict specially if you are still establishing Class B connection - B:S1. Can you confirm if we use the same RAK3172 RUI3 FW version? Also if you have a duplicatable setup on the issue you encounter, I can try it on my setup. I am using ChirpStack Gateway OS 4.8.3 Full with Chirpstack v4.14.1.
Hey @carlrowan
Thank you for pointing out the RUI3 version, I figured the problem was the old firmware within the RAK3172. We had the firmware 1.0.4. After flashing the latest firmware with STMCubeProgrammer, the Class-B behaviour became more sensible. I also realized the ACK events I saw in Chirpstack were generated by the Chirpstack LNS itself locally, as a flag of not acknowledged confirmed downlink and not related to any kind of RF communication, so that makes sense.
I however would like to ask about the communication performance on your Class B setup. So far I have measured about ~10% downlink loss (2 confirmed downlinks of 20 never made it to the node). Is this rate acceptable for Class B communication? Have you observed similar statistics?
For your Class B, do you achieve a locked? Are the downlinks received on the pingslots? I have no experience on Class B. But if you compare class A and class C and see same behavior losses percentage, the issue might not be exclusive to class B.
Good approach, I have tested with Class C just now. 150 of 150 packets delivered successfully. No loss. I guess it has something to do with Class B (and timing). Maybe it’s about quality of the GPS module my gateway is using (Seeed WM1302 EU868-USB)
