Packet Forwarder: Who sets "powe" in JSON downstream txpk packet?

dermatthias · February 17, 2020, 2:06pm

I think the subject is already the complete question:

Who sets the powe value in a packet forwarder JSON downstream data packet?
See here:

Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L358




That object contain a RF packet to be emitted and associated metadata with the following fields: 


 Name |  Type  | Function
:----:|:------:|--------------------------------------------------------------
 imme | bool   | Send packet immediately (will ignore tmst & time)
 tmst | number | Send packet on a certain timestamp value (will ignore time)
 tmms | number | Send packet at a certain GPS time (GPS synchronization required)
 freq | number | TX central frequency in MHz (unsigned float, Hz precision)
 rfch | number | Concentrator "RF chain" used for TX (unsigned integer)
 powe | number | TX output power in dBm (unsigned integer, dBm precision)
 modu | string | Modulation identifier "LORA" or "FSK"
 datr | string | LoRa datarate identifier (eg. SF12BW500)
 datr | number | FSK datarate (unsigned, in bits per second)
 codr | string | LoRa ECC coding rate identifier
 fdev | number | FSK frequency deviation (unsigned integer, in Hz) 
 ipol | bool   | Lora modulation polarization inversion
 prea | number | RF preamble size (unsigned integer)
 size | number | RF packet payload size in bytes (unsigned integer)
 data | string | Base64 encoded RF packet payload, padding optional
 ncrc | bool   | If true, disable the CRC of the physical layer (optional)

Is it the node or the gateway that received the join request or the TTN backend?

In my case it’s probably the response to a join request which sets a value not supported by the gateway (Packet REJECTED, unsupported RF power for TX - 24), and therefore the node never joins.

hobo · February 17, 2020, 5:37pm

The packet forwarder config files contain the list of the supported tx power values. There should be a sequence of the records like this one:
“tx_lut_13”: {
/* TX gain table, index 13 */
“pa_gain”: 3,
“mix_gain”: 11,
“rf_power”: 25,
“dig_gain”: 0
},

So you can either edit these records or change the value of antenna gain field.

kersing · February 17, 2020, 5:46pm

The back-end

Some packet forwarders require an exact match for power (keep in mind the real power also uses antenna gain in a calculation). Others will match to the nearest lower value configured.

Which packet forwarder are you running?

dermatthias · February 18, 2020, 9:30am

We are running the packet forwarder that is included by default on the Lorix One gateway (don’t know which one that is, sorry).

How does the backend determine which power value to set?

TonySmith · February 22, 2020, 8:33pm

I have spent the last week tracking down why a packet forwarder was dropping packets, leading to unreliable operation and just came across this discussion

I was using code that expected a match and believe this is unintended

The Packet Forwarder performs the first level of error checking and drops a packet if the requested power does not match one of the Tx_lut entries in global_conf.json
if it passes that test the packet is sent to the Lora_HAL code to transmit the packet using the SX1301 chip. Now this code works another way, it steps down the Tx_lut table until it finds a power setting =< the requested power.

So in the resultant compiled code we have two different sets of logic.

I came across this as the TTN server was requesting powe = +24dBm and this value is not in the table, there is an entry for +23dBm and the next for +25dBm but nothing at +24dBm.
(@dermatthias - this is exactly the problem you reported and why its dropping the packet)

Also found problem can be made worse depending on the Antenna Gain set in the config file

JSON down: {"txpk":{"imme":false,"tmst":2125896860,
    "freq":869.525,"rfch":0,"powe":24,"modu":"LORA","datr":"SF9BW125","codr":"4/5","ipol":true,
    "size":12,"ncrc":true,"data":"YNklASYgLwCdWI81"}}

Also thought it a bit strange the TTN server was requesting power at this level. It does it occasionally not every time.

kersing · February 22, 2020, 9:05pm

Take a look at the sources for MP forwarder and you will see it addresses the issue by finding the closest match with lower power to avoid exceeding the requested power. The same (or equivalent) code might be in the semtech reference implementation these days, I haven’t checked recently.

TonySmith · February 22, 2020, 9:20pm

Unfortunately it isn’t, that’s the code I reviewed

Thanks for the tip, i’ll have a look at your MP forwarder.

TonySmith · February 22, 2020, 9:39pm

@kersing Any thoughts why TTN server is requesting a power of +24dBm. Isn’t this above the max power outlined in the EU regional parameters?

fishbeetle · February 22, 2020, 10:04pm

See the ‘postscript’ section on this page: http://www.marvellconsultants.co.uk/LoRa/index.html

I too would like to know how the TTN backend decides what powe level to request.

Steve.

kersing · February 22, 2020, 10:32pm

The code is on github available to study

kersing · February 22, 2020, 10:34pm

No, the frequency used for RX2 allows for 27dBm.

TonySmith · February 22, 2020, 10:37pm

OK, thanks.

I was working on the understanding the ETSI limit is +27dBm and the LoraWan specification, as outlined in the Regional Parameters document, limited power to +16dBm.

dermatthias · February 23, 2020, 8:33am

Thanks all for the valuable information.

One thing that I still could not research is how the “powe” value is set. I know that the answer can be found in the source of of TTN (v2), but it’s not easy to wade through an unknown code base.

Someone with knowlegde on this topic can help out?

kersing · February 23, 2020, 10:24am

The power is set based on the region and the receive window used. Again, use the source and spend 5 minutes searching for the word “Power”. You are looking at downlink packets so it is not exactly hard to find.

kersing · February 23, 2020, 10:42am

After re-reading the specification a couple of times I am under the impression the 16dBm limit is meant for nodes (uplink), not for gateways. However the specification does not clearly state this and might be read to mean gateways need to limit to 16dBm as well.
The TTN code is quite clean and uses 27 for EU RX2.

TonySmith · February 23, 2020, 11:03am

Thanks for clearing this up. Appreciate your help

tlu · February 23, 2020, 11:34am

Is this the code here?:

github.com

TheThingsNetwork/ttn/blob/develop/core/router/downlink.go

// Copyright © 2017 The Things Network
// Use of this source code is governed by the MIT license that can be found in the LICENSE file.

package router

import (
	"fmt"
	"math"
	"strings"
	"time"

	pb_broker "github.com/TheThingsNetwork/api/broker"
	pb_gateway "github.com/TheThingsNetwork/api/gateway"
	"github.com/TheThingsNetwork/api/logfields"
	pb_protocol "github.com/TheThingsNetwork/api/protocol"
	pb_lorawan "github.com/TheThingsNetwork/api/protocol/lorawan"
	pb "github.com/TheThingsNetwork/api/router"
	"github.com/TheThingsNetwork/api/trace"
	ttnlog "github.com/TheThingsNetwork/go-utils/log"
	"github.com/TheThingsNetwork/ttn/core/band"

This file has been truncated. show original

xeranos · February 26, 2020, 12:54pm

Hello,

I’m having also issues with different gateways using the Semtech packet forwarder due to a missing LUT entry for 24 dBm. How to solve this issue? Change the entry for 25 dBm to 24 dBm or decrease all entries above 23 dBm by 1 dBm? Or is it possible to add one more LUT entry or is it limited to 16 entries?

sweetpants1 · February 26, 2020, 1:51pm

I had the same issue today. Temporary fixed it by changing:

	"tx_lut_13": {
		"desc": "TX gain table, index 13",
		"pa_gain": 3,
		"mix_gain": 11,
		"rf_power": 23,
		"dig_gain": 0
	},

into

	"tx_lut_13": {
		"desc": "TX gain table, index 13",
		"pa_gain": 3,
		"mix_gain": 11,
		"rf_power": 24,
		"dig_gain": 0
	},

in global_config.json

kersing · February 26, 2020, 4:37pm

Possible solution: Update the software to a packet forwarder that handles these cases.

Patching the Semtech reference forwarder is simple if you are able to build the software yourself. In other cases, complain at your vendor that the software can’t handle this properly.