Hello together!
I’m using the LMIC library now for quite a long time but i have troubles handling confirmed downlinks.
I have used LMIC_setClockError() to stretch the RX timing window, this at least solved the issue for reliable receiving downliks in general. But the TTN console does not stop sending the confirmed downlink again and again - I can see the data comming to the node but obviously something is missing.
Can somebody give me some advice?
THX in advance & BR
" When receiving a confirmed data message, the receiver shall respond with a data frame that has the acknowledgment bit (ACK) set… If the sender is a gateway, the end-device transmits an acknowledgment at its own discretion."
In other words, if your node receives a downlink where the MTYPE field in the header is 101 = Confirmed Downlink, then the next uplink frame it sends needs to have the ACK bit set in the LoRaWAN header.
If you see that again, set it again on the following one. Likely you are never setting it, so the network keeps retrying the downlink.
Whose LMiC repo are your using, and how current a checkout?
OK, THX 4 this information…
I know how to set the ACK bit - this is the last parameter of LMIC_setTxData2()
But how to find out if i have to set it? I’n not sure how to extract MTYPE from LMIC.frame.
I am using MCCI LoRaWAN LMIC library 3.0.99
No, it isn’t. That’s how you transmit a confirmed uplink.
Acking the confirmed downlink is completely different.
I would have thought LMiC would take care of it at network level, they are doing spec compliance stuff on the MCCI repo.
Personally I would recommend using neither the LoRaWAN confirmed uplink nor confirmed downlink mechanisms, but rather doing your own confirmation scheme at application level (ie, in the application data portion of the packet). And of course beware that all types of downlinks are very expensive for the network and need to be kept to a minimum on TTN.
In general I’m wondering why this doesn’t work. If I use my own confirmation sheme or not - the LoRaWAN basics have to work 
Anybody else a glue what could be a potential reason for this issue?
I think the non working acking mechanism could be a side effect of not properly working downlinks with TTN and MCCI LMIC in general. I’m fighting downlink reception problems for a while now, and still did not discover the root cause. I am not using stretched clock, since i use interrupt triggered timestamping.
My recent analysis showed that in cases when downlinks have failed, there simply was no downlink from the network seen at my gateway.
Thus, i assume this is not a LMIC timing issue.