[release] LoRa Server v2.6

LoRa Server v2.6.0

Features

  • On ADR, decrease device DR when the device is using a higher DR than the maximum DR set in the service-profile. #375

Bugfixes

  • Implement missing DeviceModeReq mac-command for LoRaWAN 1.1. #371
  • Fix triggering gateway config update. #373

Improvements

  • Internal code-cleanup with regards to passing configuration and objects.
  • Internal migration from Dep to Go modules.
  1. Since upgrade to v2.6.0 the behavior of the system is bad. 20 % of the sensors only araive the GWs (Tektelic Kona Mega) every few days instead of every hour. It seems sensors with SNR < - 7 dB have the problem.
  2. Before the upgrade (v2.4.1) most sensor have been received from two and more GWs now only one GW seldom two GWs receive the sensors signal?
    Installation margin in loraserver.toml:
    installation_margin=10

The only thing that have changed is that now the max DR is respected, thus when a device uses a higher data-rate than configured in the service-profile, the NS will lower the data-rate of the device. Are you sure you have configured the correct max DR in the service-profile?


yes it should be ok: min 0, max 5 ?
It was immediately after upgrade that sensors have been received by less GWs.
Thanks

Yes that looks right. Other than that (unless a regression is causing this), I don’t know what other change could have caused this.

The biggest change has been some internal cleanup, which is more related to passing the configuration objects and database pools. Do you have any error messages?

It seems sensors with SNR < - 7 dB have the problem.

Do you know at which data-rate your devices are? Are devices using ADR? I’m happy to look into this issue but with the current information I’m not sure where to look.

Sensors still working fine but seen from less GWs:

Sensors haven’t received for a few days:


They don’t have a so bad signal??
Thanks

There are less error messages in syslog (loraserver)
Mar 20 10:28:00 lora-server.mgmt.komro.net loraserver[13597]: time=“2019-03-20T10:28:00+01:00” level=error msg=“processing uplink frame error” data_base64=“QJm5kQGDC6sG/vUFMMA1YaIlSDDeugzZoB/rkfkOXCY=” error=“create uplink frame-log error: marshal phypayload error: lorawan: min value of Margin is -32”
Mar 20 10:28:07 lora-server.mgmt.komro.net loraserver[13597]: time=“2019-03-20T10:28:07+01:00” level=error msg=“processing uplink frame error” data_base64=“QJm5kQGDC6sG/vUFMMA1YaIlSDDeugzZoB/rkfkOXCY=” error=“create uplink frame-log error: marshal phypayload error: lorawan: min value of Margin is -32”
Mar 20 10:28:14 lora-server.mgmt.komro.net loraserver[13597]: time=“2019-03-20T10:28:14+01:00” level=error msg=“processing uplink frame error” data_base64=“QJm5kQGDC6sG/vUFMMA1YaIlSDDeugzZoB/rkfkOXCY=” error=“create uplink frame-log error: marshal phypayload error: lorawan: min value of Margin is -32”

Please note that the min. required SNR for SF7 is -7.5:

Given the device with -8.8 SNR, this should not have caused the ADR algorithm to increase its data-rate to SF7 (-8.8 - -7.5 - 10 = -11.3). See also this formula:

Do you also see packet-loss when looking at the frame-counters? Does the device implement the ADR backoff, causing it to lower its data-rate?

I don’t have a statisic about about frame-counters. ADR is implemented because they are doing it sometimes.

1 Like

Hi Brocaar,
I made further analysis:

  1. Receiving
    The NS receives the signal from a single sensor 6 times (3 times with diversity).
    gateway/647fdafffe00524a/rx {“rxInfo”:{“mac”:“647fdafffe00524a”,“timestamp”:3605847803,“frequency”:868500000,“channel”:2,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-113,“loRaSNR”:8.2,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}
    gateway/647fdafffe00524a/rx {“rxInfo”:{“mac”:“647fdafffe00524a”,“timestamp”:3605847803,“frequency”:868500000,“channel”:22,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-121,“loRaSNR”:2.8,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}
    gateway/647fdafffe005247/rx {“rxInfo”:{“mac”:“647fdafffe005247”,“timestamp”:813766475,“frequency”:868500000,“channel”:2,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-119,“loRaSNR”:4,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}
    gateway/647fdafffe005248/rx {“rxInfo”:{“mac”:“647fdafffe005248”,“timestamp”:265319363,“frequency”:868500000,“channel”:2,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-102,“loRaSNR”:10.5,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}
    gateway/647fdafffe005247/rx {“rxInfo”:{“mac”:“647fdafffe005247”,“timestamp”:813766475,“frequency”:868500000,“channel”:22,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-120,“loRaSNR”:3,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}
    gateway/647fdafffe005248/rx {“rxInfo”:{“mac”:“647fdafffe005248”,“timestamp”:265319363,“frequency”:868500000,“channel”:22,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-101,“loRaSNR”:10.2,“size”:32,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QDo5nwGD3LIG/h4FJlTdZ3opcOKVRTmVl5B+ikwflUM=”}

  2. Publishing
    application/2/device/a81758fffe0365d5/rx {“applicationID”:“2”,“applicationName”:“ERS-Raumsensoren”,“deviceName”:“ERS10”,“devEUI”:“a81758fffe0365d5”,“rxInfo”:[{“gatewayID”:“647fdafffe00524a”,“name”:“lora-gw007”,“rssi”:-113,“loRaSNR”:8.2,“location”:{“latitude”:47.86021,“longitude”:12.13177,“altitude”:495}}],“txInfo”:{“frequency”:868500000,“dr”:5},“adr”:true,“fCnt”:45788,“fPort”:5,“data”:“AQDZAiQEAPAFAAYEqAcOMA==”,“object”:{“co2”:1192,“humidity”:36,“light”:240,“motion”:0,“temperature”:21.7,“vdd”:3632}}

  3. my questions
    Since upgrade to v2.6.0 we do not see different GWs in the published signal?
    Why the lora-app-server don’t publishing the best signal (“rssi”:-101,“loRaSNR”:10.2,) from the diversity path?

We still have system problems since upgrade to v2.6.
Is there a way to do a save downgrade to v2.4.1?
Besides the duplicated GWs aren’t published in the receive message it seems downlink communication be worse.
Thanks
Martin

LoRa Server v2.6.1

Bugfixes

  • Fix CFList with channel-mask for LoRaWAN 1.0.3 devices.
  • Fix triggering uplink configuration function (fixing de-duplication). #387

I expect the above release fixes your issue :slight_smile:

Landinger, what path are you using on app-server UI to show this report / information?

Ronan, the report is from MQTT Broker not via app-server UI.
e.g.: mosquitto_sub -t “+/+/rx” -v
Simultanous you have to watch the publishing of the lora-app-server
e.g.: mosquitto_sub -h 10.2.8.6 -p 1883 -t “+/2/+/+/rx” -v -u landinger -P gIs******
we are running two brokers on different host!

Thanks. But what url are you using on the UI in broeser?

it is company internal network.
Martin

1 Like