Set minimum allowed TxPower

[x0y1z2]

In Service Profile I can set minimum and maximum allowed data-rate. But in some cases server set too low power by ADR to device, and if noise level increases, gateway can't receive data. I want limit minimum TxPower for solving this problem.

And I think, that it will be useful, if minimum and maximum data-rate and minimum TxPower settings will be in Device Profile.

[brocaar]

The service-profile fields are defined by the LoRaWAN Backend Interfaces specification. The min / max data-rate options are not there to make sure that the device stays connected, but to allow a network-operator to put a constraint on the used data-rates by that user. Note that the data-rate is related to the used airtime, the tx power not.

The solution in your case is to increase the installation margin: https://docs.loraserver.io/loraserver/install/config/

  # LoRaWAN network related settings.
  [network_server.network_settings]
  # Installation margin (dB) used by the ADR engine.
  #
  # A higher number means that the network-server will keep more margin,
  # resulting in a lower data-rate but decreasing the chance that the
  # device gets disconnected because it is unable to reach one of the
  # surrounded gateways.
  installation_margin=10

[x0y1z2]

Thank you, I try increase installation_margin. But in many cases margins of packets can be like this: 10, 11, 5, 12, 10, 18, 11, 12, ... Some packet has margin less or more than average. If I set installation_margin = 15 and server receive packet with margin 18, will it reduce power?

[x0y1z2]

I set installation_margin=15 in my loraserver.toml and restart loraserver, but it does not help me. Loraserver reduce power, although margin is less then 15.

log.txt

[brocaar]

See

// SpreadFactorToRequiredSNRTable contains the required SNR to demodulate a
// LoRa frame for the given spreadfactor.
// These values are taken from the SX1276 datasheet.
var SpreadFactorToRequiredSNRTable = map[int]float64{
    6:  -5,
    7:  -7.5,
    8:  -10,
    9:  -12.5,
    10: -15,
    11: -17.5,
    12: -20,
}

LoRa devices can demodulate at a negative SNR. So when your SNR is 5 and you're at SF12 your link budget budget is 25 (without taking the margin into account).

[x0y1z2]

I know about this feature. But, for example, look at the uplink packet with timestamp 1759235027. It has "spreadFactor": 7 and "loRaSNR": 6. Link budget is 13.5. Then server sends packet and reduce power ("txPower": 6). As I understand link budget should be higher then installation_margin.

[brocaar]

You're correct, that should not happen. Are you sure this Mac-command wasn't already scheduled before the restart / that the process was really restarted?

See the ADR algorithm here: https://github.com/brocaar/loraserver/blob/master/internal/adr/adr.go#L92

First it calculates the margin (which could be negative). Then it is divided by 3 to calculate the number of DR or TXPower steps. In case this is negative, the TX Power is increased (thus the TX Power offset index is decreased). This TX power increase (going from TXPower: 1 to TXPower: 0) is tested here: https://github.com/brocaar/loraserver/blob/master/internal/adr/adr_test.go#L169.

On the first view, I don't see any errors here.

[x0y1z2]

Now I reboot gateway and server. In my loraserver.toml installation_margin=15. I rejoin device. In packet with timestamp 1744356948 server send "dataRate": 4, "txPower": 0,

In 2 next packets server doesn't change setting, because margin = 16. In packet with timestamp 1758907740 server set: "dataRate": 5, "txPower": 1,

It is normal, because margin = 21. But then server continue reduce power, although margin is low. log2.txt

[brocaar]

You're right! I've been doing some testing at my side and can reproduce the issue. The issue is that for the tx power adjustment it is basing the SNR on the max SNR of the history table (20 records). For data-rate this is no issue (the data-rate changes the sensitivity of the receiver, not the SNR of the signal), but for tx power this is.

A long time ago you could set the ADR interval, but this was removed (as for the data-rate it doesn't matter to directly react on a max SNR or wait a while) and I overlooked the impact of the tx power. I'm going to fix this immediately.

Thanks for reporting 👍

[brocaar]

@x0y1z2 would you be able to re-test against https://github.com/brocaar/loraserver/tree/fix_adr? If needed I can provide precompile binaries. Just let me know which OS and architecture (e.g. Linux AMD64).

This should hopefully fix your the issue!

[x0y1z2]

It would be better, if you provide precompiled binaries, because I don't have environment for build GO projects. OS Linux (CentOS) amd64.

[brocaar]

Here you go! https://www.dropbox.com/sh/7mwditr9bse0i1w/AACw80vp7RE9pGzrFzQM56zRa?dl=0

[x0y1z2]

I test new version. Server does not reduce power, if margin is low. It is good. log3.txt

But, as I understand, server should increase power, if margin is too low. For example in log3 several last packets have margin 7 or lower. In loraserver.toml installation_margin=12.

[brocaar]

It will, but not directly. It keeps track of the last 20 received frames (meta-data). Then it will take the max SNR from that table (for the current tx-power value, this was missing!). So it might take some frames before the highest SNR would cause LoRa Server to increase the tx-power again.

[x0y1z2]

Yes, it works. I send more packets with low margin, and server increase power.