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?
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.
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…