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…
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.
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
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
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
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
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:
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.
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.
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?
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
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
It seems Dragino did this:
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?
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! 
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
Just to add information regarding this issue. I have a Lorix One which gives me the same error message in the log:
ERROR: Packet REJECTED, unsupported RF power for TX - 24
It does not transmit downlinks.
Just installed v1.0.3 for my dragino PG1301 with a fix for this.
This was implemented:
int pwr_level = 14;
for (i=0; i<txlut.size; i++) {
if (txlut.lut[i].rf_power <= txpkt.rf_power &&
pwr_level < txlut.lut[i].rf_power) {
pwr_level = txlut.lut[i].rf_power;
}
}
if (pwr_level != txpkt.rf_power) {
MSG_DEBUG(DEBUG_INFO, "INFO~ Can't find specify RF power %ddB, use %ddB\n", txpkt.rf_power, pwr_level);
txpkt.rf_power = pwr_level;
}Wouldn’t that, along with the initialization of int pwr_level = 14;, yield that the minimum supported power level is now 14? (Even if an exact lower match exists.)
This was the complete change:
> jit_result = JIT_ERROR_TX_FREQ;
> MSG_DEBUG(DEBUG_ERROR, "ERROR~ Packet REJECTED, unsupported frequency - %u (min:%u,max:%u)\n", txpkt.freq_hz, tx_freq_min[txpkt.rf_chain], tx_freq_max[txpkt.rf_chain]);
> }
> - if (jit_result == JIT_ERROR_OK) {
> +
> + if (jit_result == JIT_ERROR_OK) {
> + int pwr_level = 14;
> for (i=0; i<txlut.size; i++) {
> - if (txlut.lut[i].rf_power == txpkt.rf_power) {
> - /* this RF power is supported, we can continue */
> - break;
> + if (txlut.lut[i].rf_power <= txpkt.rf_power &&
> + pwr_level < txlut.lut[i].rf_power) {
> + pwr_level = txlut.lut[i].rf_power;
> }
> }
> - if (i == txlut.size) {
> - /* this RF power is not supported */
> - jit_result = JIT_ERROR_TX_POWER;
> - MSG_DEBUG(DEBUG_ERROR, "ERROR~ Packet REJECTED, unsupported RF power for TX - %d\n", txpkt.rf_power);
> + if (pwr_level != txpkt.rf_power) {
> + MSG_DEBUG(DEBUG_INFO, "INFO~ Can't find specify RF power %ddB, use %ddB\n", txpkt.rf_power, pwr_level);
> + txpkt.rf_power = pwr_level;
> }
> }
I have to look this over this weekend, I have the source code now, but ideed it looks odd
I think this will do the job
if (jit_result == JIT_ERROR_OK) {
for (i=0; i<txlut.size; i++) {
if (txlut.lut[i].rf_power == txpkt.rf_power) {
/* this RF power is supported, we can continue */
break;
}
if (i == txlut.size) {
MSG("ERROR: Unsupported RF power for TX - %d\n", txpkt.rf_power);
/* end of lut table, no supported power level found, use next lower entry in lut */
int pwr_level = txlut.lut[0].rf_power;
for (int j=0; j<txlut.size; j++) {
if (txlut.lut[j].rf_power < txpkt.rf_power) {
pwr_level = txlut.lut[j].rf_power;
} else {
break;
}
}
txpkt.rf_power = pwr_level;
MSG("INFO: Using RF power for TX - %d\n", txpkt.rf_power);
}
}
}Are you assuming the table is sorted? Then I’d say that the code you posted earlier could simply use that too, instead of hardcoding 14. Also, when defaulting to the first entry, the loop can skip that one:
// Assume the table is sorted, lowest power first
int pwr_level = txlut.lut[0].rf_power;;
for (i=1; i<txlut.size; i++) {
if (txlut.lut[i].rf_power <= txpkt.rf_power &&
pwr_level < txlut.lut[i].rf_power) {
pwr_level = txlut.lut[i].rf_power;
}
}
if (pwr_level != txpkt.rf_power) {
...
Of course, when it’s not sorted then this won’t suffice. (And then your fallback might also not choose the lowest power.)
Asides: your if (i == txlut.size) { ... } should certainly be outside of the for (i=0; i<txlut.size; i++). Also, in all versions I’d swap the order of the arguments, for slightly better readability:
if (txlut.lut[i].rf_power <= txpkt.rf_power &&
txlut.lut[i].rf_power > pwr_level) {
But that’s a matter of taste.
Yes, i assume the table is sorted, on an Rpi it’s located in /etc/lora-gateway or /etc/lora.
thnx for the input.