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) {
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.
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
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.
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.
But you can. It’s open source, it’s even mostly the same code, it’s just a different repo than for a plain SPI setup.
Very little is in the picoGW MCU. This isn’t. Actually the above change is to json configuration, not program code, though one could also change the program code to take the best match instead of requiring an exact one.
For changing the power table in the json, I believe you already have that in the thread.
For changing the algorithm in the code to settle for the closest match, I’d assume someone has done it in some version, they’re all pretty comparable when you start diffing the relevant portions of the actual code.
But that may be a legitimate question - is there a version of the packet forwarder which settles for a close rather than exact match?
The first thing that struck me, there is duplicated and redundant checking being conducted.
So the simple solution is to remove the test in the Packet Forwarder and allow the HAL to perform the check and select the most appropriate power.
CAUTION: I have checked the PicoGW HAL code and its not the same as the other versions of the HAL. There isn’t a test in the PicoGW HAL code for power so this solution will not work.
What is required is to edit these lines and change them from being an exact match to selecting the next lowest.
This is the code from the sx1301 HAL that could be used as a concept to create the solution
/* interpretation of TX power */
for (pow_index = txgain_lut.size-1; pow_index > 0; pow_index--) {
if (txgain_lut.lut[pow_index].rf_power <= pkt_data.rf_power) {
break;
}
}
Edit:
Try this in place of lines 2014 - 2026
if (jit_result == JIT_ERROR_OK) {
/* interpretation of TX power */
for (i = txlut.size-1; 0; i--) {
if (txlut.lut[i].rf_power <= txpkt.rf_power) {
/* Found an exact match or next lowest power, we can continue*/
break;
}
}
}
The patch I published also addressed another issue.
If you look at line 971 of the code you will see a “ToDo” where there is no checking of the configuration parameters.
There is no check for the entries in the tx-lut table are in increasing order of power. This is necessary for the selection process in the HAL code to work. As long as the tx_lut table has not been modified it should work fine.
