Again - thank you to all for your kindly comments and info
I want to transmit a confirmed uplink every 24 hours to confirn that the server is in fact receiving the uplinks. (As recommended by RAK forum users)
Once the RAK811 is set in confirmed mode , does the RAK811 just pass on the ack received from the Lora server to the application via the serial port ?
Does the RAK811 or the application have to anything once the ACK is received ?
I see there is an AT Command for repeating uplinks automatically . Again is this handled solely by the RAK811 or does the application program have to perform some actions ?
at+recv=1,-33,14,0 – Acknowledge from LoRaWan Server
OK
at+recv=1,-33,13,0 – Acknowledge from LoRaWan Server (1 second later)
OK
at+recv=1,-33,14,0 – Acknowledge from LoRaWan Server (1 second later)
OK
at+recv=1,-33,14,0 – Acknowledge from LoRaWan Server (1 second later)
OK
QUESTION:
Should the ACK from the Lorawan Server have the confirmed bit set.
I believe that the ACK from the Lorawan server has the confirmed bit set and therefore the RAK acknowledges this downlink ACK (with the confirmed bit set).
Hence - A continuous loop of the Lorawan Server and RAK acknowledging each other
Here is the Status of the RAK811 / RAK4270
at+version (RAK4270)
OK V3.3.0.14
at+get_config=lora:status
OK Work Mode: LoRaWAN
Region: EU868
MulticastEnable: false
DutycycleEnable: false
Send_repeat_cnt: 0
Join_mode: OTAA
DevEui: xxxxxxxxxxxxxxxx
AppEui: xxxxxxxxxxxxxxxx
AppKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Class: A
Joined Network:true
IsConfirm: confirm
AdrEnable: true
I’d go with a risk analysis before you start having devices doing confirmed uplinks on such a regular basis - it’s quite normal for there to be ~10% uplink loss and generally something radical has to change that the device can’t do anything about if it finds out it’s not getting a confirmation back - gateway off, stolen, damaged, backhaul off, stolen or very slow.
So in the first instance, monitor your gateway, listen for your devices & check the expected gateway is hearing your device as the only reason a device wouldn’t get a confirmation is because a gateway isn’t hearing it.
If the data is that critical, double up on gateways. If it doesn’t get it’s confirmation, you need a scheme for recovery:
Should it try again in X minutes?
Should it start decreasing the DR?
Should it try a rejoin?
But mostly, consider if you have a load of these devices what the impact will be if your algorithm ends up with a pile of downlink confirmations that block confirmed uplinks that cause a massive cluster of retries.
As for the second question, the exact interpretation of the LoRaWAN spec can keep people arguing for hours. And we are a very long way before 1.1 will be prevalent, as evidenced by the LoRa Alliance linking to the 1.0.4 specification bundle in the first instance and its current 1.1 spec document being dated 2017 so almost of no value at all at present, particularly as some of the features of 1.1 have been pulled forward in to 1.0.4.
That said, yes, bit daft having a confirmed bit set on an uplink confirmation message as you end up in a loop. Which LoRaWAN server is doing this?