Modify devices MinSupportedTXPowerIndex

lilok · July 8, 2020, 2:56pm

Hello,

playing with the installation_margin network server parameter i’m trying to set the maximum tx power value to a group of devices. Unfortunatly they don’t support TXPowerIndex 0 (i receive nack for it).

After the nack Chirpstack set MinSupportedTXPowerIndex to 1 but i’ve to wait a long time for the new adr request.

So, is it possibile to specify MinSupportedTXPowerIndex = 1 for these devices to have the ack at their first new adr request?

Thanks, regards

Gianluca

brocaar · July 8, 2020, 3:36pm

No, this is not possible. I believe this is actually more a “bug” at the device side. The (latest) Regional Parameter specification defines the TXPower table as values relative to the max. TX power supported by the device. Therefore 0 should always be a valid value.

lilok · July 8, 2020, 3:39pm

Hello Brocaar,

ok, thank you very much for your answer.

Regards

lilok · July 8, 2020, 4:05pm

Excuse me Brocaar, is it right saying that at the next adr request the network server will send TXPowerIndex 1 instead 0 if in the device session MinSupportedTXPowerIndex is now 1 after the Nack?

Thanks, regards

lilok · July 8, 2020, 8:52pm

Hello,

i would notify a strange situation. For a device (the same type of i told before) i can see this request:

lug 08 21:34:30 ***** chirpstack-network-server[13283]: time=“2020-07-08T21:34:30+02:00” level=info msg=“adr request added to mac-command queue” ctx_id=86227652-f14f-4c6f-ac53-1a12af730cf4 dev_eui=**** dr=0 nb_trans=1 req_dr=0 req_nb_trans=2 req_tx_power_idx=0 tx_power=0

This is the device session dumped after the previous adr request:

"TXPowerIndex": 0,
"DR": 0,
"ADR": true,
"MinSupportedTXPowerIndex": 0,
"MaxSupportedTXPowerIndex": 0,

After i received:

lug 08 22:38:24 *** chirpstack-network-server[13283]: time=“2020-07-08T22:38:24+02:00” level=warning msg=“link_adr request not acknowledged” channel_mask_ack=true ctx_id=e821e9cf-e013-4678-8c74-3dd9ed561f20 data_rate_ack=true dev_eui=***** power_ack=false

The new session dump shows:

"TXPowerIndex": 1,
"DR": 0,
"ADR": true,
"MinSupportedTXPowerIndex": 1,
"MaxSupportedTXPowerIndex": 0,

I’m worried of a stalled situation of tx_power requests?

Is it possibile to modify the wrong *SupportedTXPowerIndex values changing the session info from Redis?

(Note: ok you told me that txpower 0 is compliant with Lora defs, unfortunatly i’m not the developer of the sensor and i’ve no info about its implementation but i’ve to make it works :).

Thanks, regards

brocaar · July 9, 2020, 9:48am

An ADR request does not change the state of the device-session, an ADR answer (ACK or nACK) does. In your case, the device sent a TX power nACK on 0, in which case ChirpStack assumes that value 0 is not supported, increasing the MinSupportedTXPowerIndex to 1.

This looks valid to me The next ADR req. will use a TX Power value of >= 1.

Is it possibile to modify the wrong *SupportedTXPowerIndex values changing the session info from Redis?

There is no API for this and I would avoid making manual modifications. In this case I would recommend to wait until the device “stabilizes”. The MinSupportedTXPowerIndex is exactly implemented for this reason (as is the MaxSupportedTXPowerIndex).

lilok · July 9, 2020, 10:12am

Hello Brocaar,

thanks for your answer. My fear is that these values (that are obviously) wrong:

Reversed:

"MinSupportedTXPowerIndex": 1,
"MaxSupportedTXPowerIndex": 0,

Just one SupportedTXPowerIndex that is not really supported:

"MinSupportedTXPowerIndex": 0,
"MaxSupportedTXPowerIndex": 0,

May invalidate the network server algorithm to calculate the next correct TxPowerIndex to transmit to the devices. Isn’t it?

Indeed for devices with these kind of values i cannot see any new adr request.

Another question: technically if there is an adr variation calculated by the network server this should be sent at the first available downlink window? Or are there some timers that delay adr requests to a specific device to avoid too frequent changes?

Thanks, regards

brocaar · July 9, 2020, 10:55am

You will find the logic which (re)sets these values here:

github.com

brocaar/chirpstack-network-server/blob/ae1f791f65/internal/maccommand/link_adr.go#L76


		log.WithFields(log.Fields{
			"dev_eui":          ds.DevEUI,
			"tx_power_idx":     ds.TXPowerIndex,
			"dr":               adrReq.DataRate,
			"nb_trans":         adrReq.Redundancy.NbRep,
			"enabled_channels": chans,
			"ctx_id":           ctx.Value(logging.ContextIDKey),
		}).Info("link_adr request acknowledged")

	} else {
		// TODO: remove workaround once all RN2483 nodes have the issue below
		// fixed.
		//
		// This is a workaround for the RN2483 firmware (1.0.3) which sends
		// a nACK on TXPower 0 (this is incorrect behaviour, following the
		// specs). It should ACK and operate at its maximum possible power
		// when TXPower 0 is not supported. See also section 5.2 in the
		// LoRaWAN specs.
		if !powerACK && adrReq.TXPower == 0 {
			ds.TXPowerIndex = 1
			ds.MinSupportedTXPowerIndex = 1

lilok · July 9, 2020, 8:35pm

Hello Brocaar,

many thanks for your help. It has been really usefull!

I would like to ask another question.

Adr request contains:

dr=0
nb_trans=1
tx_power=5
req_dr=0
req_nb_trans=2
req_tx_power_idx=0

adr nack (msg=“link_adr request not acknowledged”) instead only contains:

data_rate_ack=true
channel_mask_ack=true
power_ack=false

i would like to know why nb_ack is not present? It doesn’t exist?

Thanks, regards

lilok · July 9, 2020, 8:58pm

Hello Brocaar,

sorry for my huge number of questions. This is always related to adr request problem.

A device (always of the bugged model) had adr flag = true (as the others) in device session, after a nack for the request of TxPowerIndex = 0 the ADR flag became “false”.

Is it chirpstack network server that in some way has flagged it as not adr capable due to the nack?

And in that case, i could i reactivate the adr flag of the device?

Thanks, regards