TxPower in ADR Backoff sequence

[sda3422]

Hi, this is related to ADR backoff sequence management in file LoRaMacAdr.c.
When it is time to set TxPower to default, direct PHY layer is used through RegionGetPhyParam and PHY_DEF_TX_POWER but it would be better to use MIB_CHANNELS_DEFAULT_TX_POWER information (Nvm.MacGroup2.ChannelsTxPowerDefault) in order to use the value that might have been configured in the device and stored in NVM.

In addition, for me there 2 missing cases in general ADR backoff management :

• At first backoff step, current TxPower value should be compared to default value and if current already equal to default we should immediately decrease Datarate in order not to loose one ADR_ACK_DELAY try for nothing
• Confirmed uplinks should not be managed in the same way... Backoff should be definitely faster in this case

What do you think about that ?
Thanks.

[mluis1]

The Nvm.MacGroup2.ChannelsTxPowerDefault reflects the value provided by querying the RegionGetPhyParam with PHY_DEF_TX_POWER` as parameter.

As you can observe by looking at LoRaMacMibSetRequestConfirm API

LoRaMac-node/src/mac/LoRaMac.c

Lines 4849 to 4862 in 2bf36bd

	case MIB_CHANNELS_DEFAULT_TX_POWER:
	{
	verify.TxPower = mibSet->Param.ChannelsDefaultTxPower;
	if( RegionVerify( Nvm.MacGroup2.Region, &verify, PHY_DEF_TX_POWER ) == true )
	{
	Nvm.MacGroup2.ChannelsTxPowerDefault = verify.TxPower;
	}
	else
	{
	status = LORAMAC_STATUS_PARAMETER_INVALID;
	}
	break;
	}

I think the ADR backoff is correct and is using the right value.

Concerning your additional 2 missing cases I think we cannot do much more as the implementation does what the LoRaWAN 1.0.4 specification says.
The below table summarizing what is said in text inside previous specification paragraphs.

If you don't mind I move this to the Discussions tab as for the moment I do not see an evidence of an issue.

[sda3422]

@mluis1 , thanks for answer.
I do not agree about default tx power. Yes the PHY is used to check that when a new value is requested it is fine but once it is validated, it becomes the "trusted" default value. If I decide to change on a device the default value specified in PHY it is probably because I cannot handle it (for some reason like power supply characteristic for example). Thanks to the NVM management this will be maintained and I will work with this default power even on each new join request. But then because of ADR backoff this default value will be exceeded and this is not clean. I still think that it should be modified but this is just my opinion.

For the 2 others remarks I agree that current implementation follows "strictly" specification and in fact this table is just an example so we are quite free to modify things a little bit on our side.

[danak6jq]

If you have specific device characteristics, such as power supply characteristics, that seems like something the board-specific radio code (ex. SX1276SetRfTxPower()) would handle.

[dbboyd17]

Can I ask a basic question. At the application layer, is there an API that can be called that will return the current ADRAckCnt, or something that the application can use to determine that the MAC layer has backed off as far as it can using ADR?

This is so that the end device can determine if it would be appropriate to attempt to rejoin the network in the event that the end device has been moved between applications at the network layer.

Or to put it another way, is there a means by which the end device application can determine that it is not getting data to the network?

[dbboyd17]

The supplementary question is at what point (if ever) should the end device attempt to reJOIN the network on the basis of the ADR state?