Unsupported RF power for TX - 9

[danielknox]

Hi, I have recently updated the lora_pkt_fwd program on one of my gateways and have used the "antenna_gain" variable to match my antenna's dbi. Since then I notice errors arising: "ERROR: Packet REJECTED, unsupported RF power for TX - 9".

This effects downlink packets.

Naturally reducing the antenna dbi removes this issue, but that is sidestepping the real issue. Is the network server in charge of requesting transmit powers (and so it is unaware of this violation)? or is this error likely to be solely coming from the lora_pkt_fwd as the loraserver has nothing to do with suggesting TX power level?

Cheers! Dan

[brocaar]

Thanks for reporting! Would you be able to post the message posted to the tx topic? (https://docs.loraserver.io/lora-gateway-bridge/topics/#gatewaymactx)

Could you also let me know the exact version of your packet forwarder?

[danielknox]

It happens with a join request, here is the response from lora server:

{
  "txInfo": {
    "mac": "d03972fffe180756",
    "immediately": false,
    "timestamp": 71723396,
    "frequency": 868500000,
    "power": 14,
    "dataRate": {
      "modulation": "LORA",
      "spreadFactor": 7,
      "bandwidth": 125
    },
    "codeRate": "4/5",
    "iPol": null
  },
  "phyPayload": "IMGd/TAHkVz0rkWFaa0tSwGd0PeZkDab4WGpVDcotA20"
}

The lora packet forwarder version is v3.1.0, compiled from lora-net.

[nestorayuso]

I think the problem is LoRa Server and Gateways have different RF power table values.

check this related issue: https://github.com/Lora-net/packet_forwarder/issues/21

[danielknox]

So my guess here is loraserver is defaulting to RF power 14. The packet forwarder has been told antenna gain is 5dbi, so 14-5 = 9 (hence reference to TX power 9) and reviewing the global_conf.json there is no entry for rf_power: 9 hence the error. Whereas if I reduce the dbi gain to 3, 14-3 = 11, which there is an entry for?

If so, this leaves two possible considerations

As the gateway responds to the NS with JIT_ERROR_TX_POWER, should the NS attempt another RF_Power (e.g. a lower one)? However, there will always be a case where the NS has exhausted all possible configured TX values.

Alternatively, how does one sanely create a new tx_lut entry for lora packet fwd, given theres a number of parameters that currently look like magic numbers: pa_gain, mix_gain and dig_gain.

[brocaar]

Yes, LoRa Server currently uses the default TX power (which is 14 for EU 868). Given that the packet forwarder subtracts the gain from the TX power to get TX power value to use, what would be the right approach in this case? If LoRa Server would adjust the TX power, it would still be wrong wouldn't it as the packet forwarder would still subtract the gain from that value?

Should the TX power entries in the global_conf.json be overwritten, adjusted to the antenna gain in this case?

[nestorayuso]

The best solution is to complete the remaining LUT entries in global_conf.json It is needed a spectrum analyser and some info about what do each register, I will investigate it. At the moment just fill the LUT entries with copy&paste the nearest lower power entry ones.

[danielknox]

Thanks for the advice. Following nestorayuso's suggestion and link to the related issue, I modified line 2372 of lora_pkt_fwd.c to exclude the jit_result variable being set to 'JIT_ERROR_TX_POWER'

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) { /* this RF power is not supported */ jit_result = JIT_ERROR_TX_POWER; MSG("ERROR: Packet REJECTED, unsupported RF power for TX - %d\n", txpkt.rf_power); } }

It still performs the check, and flags a mismatch to the user; but allows the packet to be forwarded to the concentrator. The lora_gateway driver currently takes the proposed RF power and iterates backwards through the LUT table until it finds a value that is equal to or less than the requested rf power (if none exists, it raises an error) - it uses this for transmitting the packet.

This is not the best solution, but allows the gateway to attempt as far as possible to handle downlink requests from a NS.

[jcourtat]

Hello, i had the same issue. I fixed it by configuring luts in global_conf.json. I have a kerlink lora station gateway, and i updated all tx_lut_0 to tx_lut_15 in the global_conf.json. hope it can prevent you from patching packet_forwarder