ERROR: Packet REJECTED, unsupported RF power for TX - 24

1

Since a while i receive "ERROR: Packet REJECTED, unsupported RF power for TX - 24’ downlink messages on my home gateway.

Feb 26 07:32:36 rpilora lora_pkt_fwd[16941]: RXTX: {“stat”:{“time”:“2020-02-26 06:32:06 GMT”,“lati”:51.68546,“long”:3.89974,“alti”:13,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:100.0,“dwnb”:0,“txnb”:0}}
Feb 26 07:32:36 rpilora lora_pkt_fwd[16941]: RXTX: {“rxpk”:[{“tmst”:119802156,“chan”:4,“rfch”:0,“freq”:867.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:9.8,“rssi”:-50,“size”:23,“data”:“QFUpASaAPgEBJT7MvSLLgFf1Rkppajc=”}]}
Feb 26 07:32:36 rpilora lora_pkt_fwd[16941]: RXTX: {“txpk”:{“imme”:false,“tmst”:121802156,“freq”:869.525,“rfch”:0,“powe”:24,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“ipol”:true,“size”:17,“ncrc”:true,“data”:“YFUpASaF/QADVf8AAbBcZ2s=”}}
Feb 26 07:32:36 rpilora lora_pkt_fwd[16941]: src/lora_pkt_fwd.c:2565:thread_down(): ERROR: Packet REJECTED, unsupported RF power for TX - 24

The node is using ADR and joins at SF10 and used to go to SF7 (because my home gateway), but since i receive these downlink messages, it ends up with SF12 because i believe the downlink message is never send to the node due to the ERROR. I now receive a downlink message on every uplink

2

After searching with google this seems to be a known issue of gateways. After changing global_conf.json

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

to

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

Thins started working again.

The downside of when this is happening, that the node ‘thinks’ it’s packets are not received so ends up with SF12 allocating too much airtime

3

I had this with the TTOG. Sent a load of nodes to SF12…

4

hi
i have the “same” error on rpi4 using rak2245
ERROR: Packet REJECTED, unsupported RF power for TX - 17

 "tx_lut_10": {
            "desc": "TX gain table, index 10",
            "pa_gain": 2,
            "mix_gain": 11,
            "rf_power": 16,
            "dig_gain": 0

change to

 "tx_lut_10": {
            "desc": "TX gain table, index 10",
            "pa_gain": 2,
            "mix_gain": 11,
            "rf_power": 17,
            "dig_gain": 0

here error log https://pastebin.com/spiCgxRN

5

Don’t start modifying the global config because you might have issues with the next packet which specifies the value you just changed. Find and install a packet forwarder that addresses the issue.

1 Like
6

I use the PG1301 gateway from Dragino. Had contact with them and they supplied me wit a new global_conf.json. For other Dragino products there will be an update available soon that incorporates the changes. “We will release a new firmware this week to have the 24 power in the index so no changed needed in new firmware.”

7

After installing the new global_conf.json, the same problem appeared at another power level (11). Because there are only 16 indexes availabe, Dragino is going to modify the code so every level below 12 will be mapped to 12.

8

Power should map to the closest lower power level. Not a higher power level.
The best way to solve this would be if Dragino take the existing logic some packet forwarders use already.
MP forwarder includes the fix and the license allows them to reuse the code…

9

Just curious: doesn’t the gateway configuration already take local regulations into account, so using a higher available power would be allowed as well? If true, then I’d also boldly use a higher power, to increase the chances that the downlink is received.

10

I have the same problem with my DRAGINO LPS8, latest Firmware v5.3.1583308432. I get the error message: “unsupported RF power for TX -11”.
The “Join”-Phase takes about 5 min until the nodes (LGT92, LT33222) are set to SF12, BW 125, with SNR (8-10)dB. I regognized that for the first 4 min the LPS8 downlinks on the same frequency that the node uses to transmit. Then after about 4.5 min the LPS8 downlinks on 869.525 MHz and the connection is established. But always SF12/125kHz.
Does this behaviour have something to do with the rejected packets?

Wolfgang

11

Does this behaviour have something to do with the rejected packets?

Yes, it does, I had the same thing and had to adjust the global_conf.json to match it with the requested power settings. I think Dragino is coming out with new firmware for their gateways this week

regards, Harry

12

Thank you for your answer. I installed the new firmware dated 2020-03-04. Because I dont know how to adjust the global_conf.json Ì will wait for the new version.

Wolfgang

13

In Slack, @htdvisser wrote:

Created Downlinks rejected by gateways for certain TX powers · Issue #2106 · TheThingsNetwork/lorawan-stack · GitHub to track this

This also mentions:

…

With the gateway configs that have been distributed through TTN (GitHub - TheThingsNetwork/gateway-conf: The Things Network Master Gateway Configurations), the following TX powers are accepted by gateways:

-6, -3, 0, 3, 6, 10, 11, 12, 13, 14, 16, 20, 23, 25, 26, 27

…

This means that the ERROR: Packet REJECTED, unsupported RF power for TX - 11 is just a misconfiguration of the gateway, but the other reports are valid.

…

1 Like
14

And a bit more from Slack, for future reference, so you know what to expect. Note that for V2 the problem seems to have started when V2 gateways were recently bridged through V3:

@htdvisser 2020-03-09 2:43 PM

Note that this issue is for v3. In v3 we let users register the antenna gain of their gateway. V3 serves config files without the antenna gain field, and subtracts the gain for each downlink.

@TonySmith 2020-03-09 3:05 PM

It would not matter if the antenna gain is entered in the gateway’s config file or the V3 server. Take for example a 6dBi antenna and 2dB of cable loss. The net gain is 4dBi. If this entered in either place, when the server wants to transmit at +27dBm (eirp), the gateway will be requested to send at +24dBm. This power does not exist in the Tx_lut table and the packet will be dropped.

@TonySmith 2020-03-09 2:50 PM

The UDP packet forwarder is compiled from two pieces of code. The first the Packet Forwarder takes UDP packets from the internet and places them on an internal queue. There is a test to check there is a 100% match with one of the 16 entries in the Tx_lut table. The second piece of code, the SX1301 HAL takes the packet from the queue and searches the Tx_lut table (again) for the next lowest power. So in effect the test is performed twice and using different criteria in each case. You can simply remove the first test in the Packet Forwarder and recompile, By the way, there is no error checking and the whole system is incorrect if someone fails to put the Tx_lut entries in increasing order. My revised UDP packet forwarder fixes both problems

The problem does not exist in the packet forwarder for the new SX1302 base band receiver, here the logic is correct from the first release

@TonySmith, not my cup of tea, but it seems some of the above would be good input on Downlinks rejected by gateways for certain TX powers · Issue #2106 · TheThingsNetwork/lorawan-stack · GitHub as well, if only to ensure @KrishnaIyerEaswaran2 sees it too?

15

I have published a version of the Packet Forwarder which corrects the problem. Its been tested by a number of people over the last few weeks and is confirmed to fix the problem.

Refer [https://github.com/JoToSystems/LoraPacketForwarder]

I also know RAK have incorporated this fix into their code, downloading gateway code from the RAK web site is an alternative.

2 Likes
16

I should add, if you are using @kersing MP Forwarder, you won’t experience the problem, the code was corrected right from the start.

Also , gateways using the new SX1302 Baseband receiver chip will not suffer from this problem as the packet forwarder for this chip will select the next lowest power and not cause a problem.

2 Likes
17

It seems Dragino did this:

18

Ah, this also selects a lower power, just like fallback implementations in (most) packet forwarders.

Still wondering why one should not use a higher power, if available in the configuration. I guess the network server won’t request a power that is already close to the minimum required value, if it could even properly determine that? So, I guess the network server will request a bit more than (it thinks) is required?

19

Best practice within ADR is to not go to absolute min power for a given link but rather allow a small headroom buffer of Tx power to allow for some variability in the link budget over time - e.g. through scattering, intense rain/snowfall, foliage growth etc, so if coming down is only option and that takes you below buffer for effective power Tx then going up should be the option me thinks! :slight_smile:

20

Hi @Jeff-UK, I don’t think going down is a problem, its normally only 1 or 2dBm. Its the lack of a match that the big problem. Looking at the normal time variation of RSSI in a gateway, its more than this and so I would assume this has been taken into account when determining the gateway’s transmit power. So I would not think reducing by 1 or 2 dBm would be a big problem.

Could easily change the algorithm if you thought there is a better solution