How to limit the number of tries for LMiC confirmed uplinks? (ACK)

yoopee · July 25, 2016, 9:43am

Hello,
I am sending the ACK messages, which works fine with Matthijs library. I have the TXCONF_ATTEMPTS set to 8 (which is the default library setting), but my node (when not in reach of GW) tries to communicate all the time (after 8’s attempt).

Is there another parameter which should be set to proper work, please?

Thank you,

Peter

Oliv · July 26, 2016, 7:59am

I’ll take a closer look but I do not remember modifying something and have 8 attempts then the LMIC library stops trying. Do you modified the library ?

yoopee · July 28, 2016, 8:33am

I didnt change anything in the library, I am using LMic as-is…

anyone else here having the same problem please?

Oliv · July 29, 2016, 8:22am

I checked and did not change code related to that, and it works.
Did you tried to print LMIC.txCnt in order to see if it is incremented ? You can do it here. Also, you can debug if the code reaches L1821. A print of TXCONF_ATTEMPTS to check if it is really 8 might be a good thing too.

yoopee · August 9, 2016, 11:57am

it works, the problem was short tx interval, so the node was repeating tx all the time

thanks

arjanvanb · March 18, 2018, 10:59am

Some testing by @sp1 as mentioned on Slack confirms that the following disables the retries altogether:

LMIC_setTxData2(..., ..., ..., 1);
// Disable automatic retries when confirmed uplink is not acknowledged.
// ONLY DO THIS WHEN INDEED USING A CONFIRMED UPLINK.
LMIC.txCnt = TXCONF_ATTEMPTS;

Beware that erroneously doing this for unconfirmed uplinks, will make LMIC ignore regular downlinks. This is actually by design and even validated during LoRaWAN compliance testing:

github.com

mcci-catena/arduino-lmic/blob/v3.2.0/src/lmic/lmic.c#L2260-L2275


// downlink frame was accepted. This means that we're done. Except
// there's one bizarre corner case. If we sent a confirmed message
// and got a downlink that didn't have an ACK, we have to retry.
// It is not clear why the network is permitted to do this; the
// fact that they scheduled a downlink for us during one of the RX
// windows is clear confirmation that the uplink made it to the
// network and was valid. However, compliance checks this, so
// we have to handle it and retransmit.
else if (LMIC.txCnt != 0 && (LMIC.txrxFlags & TXRX_NACK) != 0)
    {
    // grr.  we're confirmed but the network downlink did not
    // set the ACK bit. We know txCnt is non-zero, so this
    // will immediately fall into the retransmit path. We don't
    // want to do this unless it's a confirmed uplink.
    return processDnData_norx();
    }

So, as a result of messing with LMIC.txCnt, for unconfirmed uplinks LMIC.dataLen will always be zero in EV_TXCOMPLETE. (Tested with MCCI LMIC 3.2.0. For confirmed uplinks, both a bare ACK and a downlink that holds an ACK along with an application downlink, work fine with the above.)

Setting it to some lower value might limit it to, say, 2 retries yielding a total of 3 attempts:

// Limit to 2 retries, yielding a total of 3 attempts.
// ONLY DO THIS WHEN INDEED USING A CONFIRMED UPLINK.
LMIC.txCnt = TXCONF_ATTEMPTS - 2;

Peeking into the code suggests that this also works when LMiC delays the actual transmission due to duty cycle limitations. However, for OTAA the above needs that the node has already joined; if not joined yet then LMIC will invoke LMIC.txCnt = 0 after the successful join, before the actual packet is going to be transmitted, hence resetting the remaining attempts to 8. One might be able to circumvent that by explicitly starting the OTAA Join in the setup, by calling LMIC_startJoining() before invoking any LMIC_setTxData or LMIC_setTxData2. (See “Backgound” in Can LMIC 1.6 be set up to use a single channel and SF?)

Of course, all above implies you’re now relying on the internals of LMIC to never change…