Hi,Is this behavior normal? Shouldn’t the RAK4630 transmit the TxParamSetupAns only once?
This image is from the LNS, which is a MAC commands log and shows the TxParamSetupReq:
This other image is from the most recent transmissions and shows that the RAK4630 has transmitted a TxParamSetupAns in every transmission.
Some extra information:
After some investigation, it seems to be normal to avoid the situation described in here:
opened 10:36PM - 11 Dec 18 UTC
closed 04:03PM - 02 Apr 19 UTC
enhancement
discussion
**Problem:** An end-device can be sending and listening using `SF11` or `SF12`, … while the *Network Server* only sends downlinks using `SF10`, causing none of the downlinks to be received. This can be caused when an uplink containing a `TxParamSetupAns` MAC command is lost, followed by the end-device changing from `SF10` to `SF11` or `SF12`. This results in the NS assuming that the dwell-time limit is still active (because it has not received the `TxParamSetupAns`), whereas the end-device assumes that there is no dwell-time limit.
**Description:** When a device joins our AS923 network (using `SF10`), the first post-join downlink contains a `TxParamSetupReq` MAC command, and this command notifies the device that there is no dwell time limit active for this network. Once the mote sends a corresponding `TxParamSetupAns` response, its state is updated to reflect that no dwell time limit is active.
But if the uplink is lost that contains the `TxParamSetupAns` MAC command, then the NS and end-device will disagree on whether the dwell-time limit is active -- the NS has not seen a `TxParamSetupAns` so the default dwell time limit must be enforced, but the end-device has responded to the NS's `TxParamSetupReq` command, so it sends uplinks as if there is no dwell time limit active.
Therefore, if the end-device changes to `SF11` or `SF12` for uplinks, then it will never hear any responses from the NS, because even though the downlink will use the correct channel, the modulation will be incorrect -- `SF10` for the downlink as the NS has not seen the `TxParamSetupAns` response. And because the end-device will not be listening on `SF10`, it cannot receive any future `TxParamSetupReq` MAC commands (until, eventually, the end-device attempts to rejoin, or performs a soft-reset).
**Fix:** Add the `TxParamSetupAns` command to the list of *"sticky"* MAC commands, so that it will be repeated until the end-device next receives a response from the Network Server (NS). This involves changing just two lines of code, of `LoRaMacCommands.c` of the current `en.i-cube_lrwan.zip` distribution. First, at line 38:
```C
const uint8_t CIDsStickyAnsCmds[] = { MOTE_MAC_DL_CHANNEL_ANS, \
MOTE_MAC_RX_PARAM_SETUP_ANS, MOTE_MAC_RX_TIMING_SETUP_ANS, \
MOTE_MAC_TX_PARAM_SETUP_ANS /* <- NEW */ };
```
which adds `MOTE_MAC_TX_PARAM_SETUP_ANS` to the list of sticky answers, and then add another `case` to the `IsSticky(..)` function, which starts from line 286:
```C
static bool IsSticky( uint8_t cid )
{
switch( cid )
{
case MOTE_MAC_DL_CHANNEL_ANS:
case MOTE_MAC_RX_PARAM_SETUP_ANS:
case MOTE_MAC_RX_TIMING_SETUP_ANS:
case MOTE_MAC_TX_PARAM_SETUP_ANS: // <- NEW
return true;
default:
return false;
}
}
```
carlrowan
February 9, 2024, 12:39am
3
Hi @nicolasech ,
Does this mean that TxParamSetupAns was lost so it was repeated continuously (like the sticky implementation)?
When you restart the module, is there any improvement?
