Unfortunately it isn’t, that’s the code I reviewed
Thanks for the tip, i’ll have a look at your MP forwarder.
@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?
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.
The code is on github available to study 
No, the frequency used for RX2 allows for 27dBm.
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.
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
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.
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
Thanks for clearing this up. Appreciate your help
Is this the code here?:
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?
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
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.
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. 
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.