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

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.)

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

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.

In stead of error checking a simple sort would solve the issue without the need to reject the input.
However, in 5 years working with packet forwarders I’ve never encountered that issue so the question is whether there is a need to fix anything. TTN gateways should use the TTN provided configuration anyway which has the entries in the right order.

Came across a relevant quote in another post by @htdvisser

Every device has the same transmit duty cycle, gateways are no exception. The TTN backend is compliant with these regulations, so in Europe we stay under the 1% duty cycle for g and g1 and under 10% for g3 . By default, gateways transmit with maximum allowed TX power (14 for EU-868).

See original at Fair Use Policy explained - #7 by jakl5749

So wonder if this approach has changed or something has slipped through in the updates to the TTN server.

@kersing, I also went back and reread the LoraWan Regional parameters and agree, they seem to be written from a Node’s perspective.

1 Like

27 for g3, where 10% DC is allowed.