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

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

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 ?

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

anyone else here having the same problem please?

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.

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

thanks

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;

:warning: 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:

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?)

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

1 Like