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

Gateways
4

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?

5

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

  1. 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
  2. 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.

2 Likes
6

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.

1 Like
7

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

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

8

@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?

9

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.

10

The code is on github available to study :slight_smile:

11

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

12

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.

15

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?

1 Like
16

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.

17

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.

1 Like
18

Thanks for clearing this up. Appreciate your help

19

Is this the code here?:

20

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?

21

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

22

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.

23

Nice. And on Slack, @TonySmith wrote:

Tony Smith 2020-02-27 1:40 PM

@arjanvanb its caused by an “error” in the packet forwarder. instead of finding the next lowest power in the Tx_Lut table in the conf file, it rejects the packet. I have a fix which has been tested for about a week now. Will release soon.

First: silently fixing it by falling back to a lower (or: higher?) TX power is a great help, of course. :+1:

But still, just curious: shouldn’t a network be notified about that? Rejecting a setting might allow the network to know that the gateway does not support it, which (at least in theory) might make it select another gateway next time?

(The network can infer if MAC commands have been received by validating if the next uplink uses the new settings, which TTN indeed does for ADR. But not so much for application-level downlinks.)

24

AFAIK there is no mechanism to do so.

Keep in mind the the antenna gain in the configuration is used to chance the value provided by the backend to the actual value used to lookup the transmission parameters. By using a packet forwarder that has been ‘improved’ the gateway is perfectly able to handle the issue.

1 Like
25

There is another issue, the packet forwarder has no error checking of the Tx_lut table which is stored in global_conf.json file. If the entries are not in increasing order of power, the second part of the packet forwarder, (which takes the packet from a queue and passes it to the SX1301 gateway chip) can select the wrong power.