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.
For future readers: any update on the result? Did Dragino meanwhile release a fix for the fix? (I am not using that Dragino gateway.)
Yes, they made a fix, but as you mentioned in ERROR: Packet REJECTED, unsupported RF power for TX - 24, i modified the code using your advise.
I am not monitoring my gateway at the moment, but I have not seen this error anymore. My node stays at SF7BW125 now. It used to go to SF12BW125 when the error occurred. Maybe i am going to suggest my fix to them.
Okay, so no official fix for their above erroneous changes of 14 days ago? Did you report back to them?
“Did you report back to them?” Not yet, i will make a pull-request on their github site, don;t know when this will be incorperated
Just created a pull-request with my changes for the [pi_gateway_fwd] https://github.com/dragino/pi_gateway_fwd
Now wait what the think of it
@KrishnaIyerEaswaran2 2020-04-02T08:08:41Z
We’ve just deployed a patch that should revert the behaviour. I’ll wait for some feedback before closing this.
I assume this does not mean that routing of V2 gateways through V3 is reverted, but something is done to fix the requested RF power.
Yeah indeed the fix is targeted only the requested RF Power.
Hello, I have the same error, but according to github (issue 2106) the problem is solved.
I am doing something wrong?
ERROR: Packet REJECTED, unsupported RF power for TX - 24
Node stuck to SF12 already out-of-duty cycle 
I tried to compile kersing’s work but I have nfuse picoGW concentrator with picoGW_hal and picoGW_packet_forwarder. To my understanding I need Lora-net/packet_forwarder as dependency but I failed to compile it too
I also tried to change this: (I have almost no-idea what I am doing)
“tx_lut_15”: {
/* TX gain table, index 15 */
“pa_gain”: 0,
“mix_gain”: 12,
“rf_power”: 24, (was 23)
“dig_gain”: 3
Now I have no errors (?) and those messages:
# TX rejected (collision packet): 0.00% (req:2, rej:0)
# TX rejected (collision beacon): 0.00% (req:2, rej:0)
# TX rejected (too late): 0.00% (req:2, rej:0)
# TX rejected (too early): 0.00% (req:2, rej:0)
But my device is stuck at SF12 (it’s mobile device) although I selected SF10. This is normal?
The pico gateway uses its own repos, even though the code for the packet forwarder is 95% the same, it’s unfortunately distinct in git so you have to move fixes across at the level of “patch” - or making manual changes as you did. Apparently they did this yet again with the SX1302 - it has its own repo encompassing both the packet forwarder and HAL parts, and again duplicating much of the code.
Your messages would appear to indicate your gateway was asked to transmit two downlinks, and found none of the listed reasons not to. So hopefully it actually did.
Your remaining problem may be elsewhere.
Here is an idea. If you can’t change the software then increase the antenna gain setting in the global_conf.json file.
Refer to https://forum.chirpstack.io/t/configure-gw-tx-power-on-a-per-gw-basis/8997/4 where a similar problem was solved using this approach.
By the way, don’t decrease the antenna gain from the original setting, only increase. You will also see in the link its not a good idea to change the tx_lut table.