Lopy Nanogateway fails to pull downlink messages from loraserver


#1

I am using lopy (I also have used Fipy with the same results) as nanogateway and I am able to upload messages from a microchip node RN2903 through the nanogateway to the loraserver (ABP join). However, I can’t receive downlink messages (either automatic ACKs responses without payload as response to confirmed uplink messages, or downlink messages with payload, or even OTAA joins), even when those downlink messages have been generated in the noetwork servers.
The problem seems to be related to the nanogateway because I have tryed with different network servers (loraserver.io and TTN) and different LANs. I have also tryed using a different gateway (multitech conduit gateway) and in that case the netwok works perfectly: I can use any server, any node, any join method, and send and receive uplink and downlink messages. The problem is when I try to use the nanogateway to handle downlink messages.
I have seen in someother posts in Pycom forums that some people have experienced sync problems with RX windows; however, in my case the downlink message never reaches the LoRa RF channel (I have confirmed this with a spectrum analyzer)…maybe if I can fix my issue I will have to face that other one in the future.
It seems that the problem is in the communication between the gateway and the network server. Logs of loraserver’s lora-gateway-bridge suggest the nanogateway can’t handle some PullACK messages:


Note: The boxed logs correspond to the transmission of a confirmed uplink message on frequency 902.3MHz, with one retransmision because the ACK is not received in the RN2903.

Following are the screen shot from the loraserver web-gui for the same experiment (the last downlink is displayed in more detail), and the corresponding jsons of the messages shown in the screen are pasted at the bottom of this message:

I would appreciate any help.
Thanks in advance.

Messages json:

[
{
“downlinkMetaData”: {
“txInfo”: {
“mac”: “30aea4fffe2a4cd0”,
“immediately”: false,
“timeSinceGPSEpoch”: “”,
“timestamp”: 1793513861,
“frequency”: 923300000,
“power”: 20,
“dataRate”: {
“modulation”: “LORA”,
“bandwidth”: 500,
“spreadFactor”: 10,
“bitrate”: 500
},
“codeRate”: “4/5”,
“iPol”: true,
“board”: 0,
“antenna”: 0
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataDown”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “07ab0470”,
“fCtrl”: {
“adr”: true,
“adrAckReq”: false,
“ack”: true,
“fPending”: false
},
“fCnt”: 19,
“fOpts”: null
},
“fPort”: null,
“frmPayload”: null
},
“mic”: “921e47d7”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“mac”: “30aea4fffe2a4cd0”,
“time”: “2018-03-09T17:43:08.793467Z”,
“timeSinceGPSEpoch”: “”,
“timestamp”: 1561513861,
“rssi”: -40,
“loRaSNR”: 5,
“board”: 0,
“antenna”: 0
}
],
“txInfo”: {
“frequency”: 902300000,
“dataRate”: {
“modulation”: “LORA”,
“bandwidth”: 125,
“spreadFactor”: 10,
“bitrate”: 0
},
“codeRate”: “4/5”
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “ConfirmedDataUp”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “07ab0470”,
“fCtrl”: {
“adr”: false,
“adrAckReq”: false,
“ack”: false,
“fPending”: false
},
“fCnt”: 21,
“fOpts”: null
},
“fPort”: 1,
“frmPayload”: [
{
“bytes”: “ag==”
}
]
},
“mic”: “2a0d8365”
}
},
{
“downlinkMetaData”: {
“txInfo”: {
“mac”: “30aea4fffe2a4cd0”,
“immediately”: false,
“timeSinceGPSEpoch”: “”,
“timestamp”: 1789246502,
“frequency”: 923300000,
“power”: 20,
“dataRate”: {
“modulation”: “LORA”,
“bandwidth”: 500,
“spreadFactor”: 10,
“bitrate”: 500
},
“codeRate”: “4/5”,
“iPol”: true,
“board”: 0,
“antenna”: 0
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataDown”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “07ab0470”,
“fCtrl”: {
“adr”: true,
“adrAckReq”: false,
“ack”: true,
“fPending”: false
},
“fCnt”: 18,
“fOpts”: null
},
“fPort”: null,
“frmPayload”: null
},
“mic”: “ee8c3a92”
}
},
{
“uplinkMetaData”: {
“rxInfo”: [
{
“mac”: “30aea4fffe2a4cd0”,
“time”: “2018-03-09T17:43:04.441468Z”,
“timeSinceGPSEpoch”: “”,
“timestamp”: 1557246502,
“rssi”: -40,
“loRaSNR”: 6,
“board”: 0,
“antenna”: 0
}
],
“txInfo”: {
“frequency”: 902300000,
“dataRate”: {
“modulation”: “LORA”,
“bandwidth”: 125,
“spreadFactor”: 10,
“bitrate”: 0
},
“codeRate”: “4/5”
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “ConfirmedDataUp”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “07ab0470”,
“fCtrl”: {
“adr”: false,
“adrAckReq”: false,
“ack”: false,
“fPending”: false
},
“fCnt”: 21,
“fOpts”: null
},
“fPort”: 1,
“frmPayload”: [
{
“bytes”: “ag==”
}
]
},
“mic”: “2a0d8365”
}
}
]


#2

Did you see / try the steps documented here: https://docs.loraserver.io/lora-gateway-bridge/install/debug/?


#3

No @brocaar, I haven’t.
I will take a look.
Thanks!!


#4

I was on mobile when answering and wasn’t able to see the full screenshot. It might be an issue with your packet-forwarder actually, sending data that is not expected.

The error is logged here: https://github.com/brocaar/lora-gateway-bridge/blob/5d72f5ff14aef4d7f94472618f0414dc5513c0c0/internal/gateway/backend.go#L269. As you can see, this is while handling data received from the gateway.

Looking at the PROTOCOL.TXT, you see that this PullACK is supposed to be generated by the server (LoRa Gateway Bridge), not the gateway: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L263


#5

Hi @brocaar,
I have been testing the nanogateway code and I found that ACK response reaches the gateway, but the timestamp of the downlink message is too far away from the uplink timestamp (about tens of seconds), so the gateway discards the message.
I found that the error seems to be in the loraserver, as you can see from the following print screen:


NOTE: The rx1 delay is configured to be 1 sec.

I also found that the timestamp difference seems to be ok for the response during the OTAA join (5 sec)…however, in that case the node still doesn’t join (I have checked the DEVEUI and APPkey are the same in the server and the node, but the problem is somewhere else).
I don’t understand why the timestamp problem occurrs for ABP response to confirmed uplink messages, and not for the OTAA join response. Can it be solved installing an older (maybe newer one) version of loraserver? or is it related to https://github.com/brocaar/lora-gateway-bridge/blob/5d72f5ff14aef4d7f94472618f0414dc5513c0c0/internal/gateway/backend.go#L269?

Thnks in advance


#6

But you describe this only happens with the nano gateway, not with other gateways. So I don’t think this is a LoRa Server bug, else you would see exactly the same behavior with other gateways.


#7

Hi, can you give me a hand here?, I’m trying to connect a Lopy nanogateway to an instance of AWS in which I installed LoraServer to test it, but I have not managed to connect this gateway with my LoraServer instance. In the Lopy load the files from the repository and pointing to the instance in AWS port 1700:
https://github.com/pycom/pycom-libraries/tree/master/examples/lorawan-nano-gatewaygithub.com/pycom/pycom-libraries/tree/master/examples/lorawan-nano-gateway
debug return:
image

nothing more…

from the LoRa Gateway Bridge debug:
Sep 22 22:40:03 ip-172-xx-38-11 systemd[1]: Started LoRa Gateway Bridge.
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“starting LoRa Gateway Bridge” docs=“https://www.loraserver.io/lora-gateway-bridge/” version=2.5.1
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“backend: set max reconnect interval: 10m0s”
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“backend: TLS config is empty”
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“backend: connecting to mqtt broker” server=“tcp://127.0.0.1:1883”
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“gateway: starting gateway udp listener” addr=“0.0.0.0:1700”
Sep 22 22:40:03 ip-172-xx-38-11 lora-gateway-bridge[1312]: time=“2018-09-22T22:40:03Z” level=info msg=“backend: connected to mqtt broker”

On the UI nothing is received.

could help me to find what I’m doing wrong, it is possible to use the Lopy as a gateway in LoraServer? (since it is not listed in the possible ones). Do i have to make any special configuration during the installation of the LoraServer for AU915?
thanks


#8

Yes lopy gateway is working with loraserver

Validate that you have a UDP connection between loraserver and your LOPY GW

  1. open a terminal on loraserver
  2. sudo tcpdump -AUq port 1700
  3. are you receiving UDP records into this terminal session ?
  4. if no, validate the UDP connection between GW and loraserver, maybe FW rules ???
  5. if yes validate your config under loraserver.

#9

Hi, this is what you see in the log of the LoRa Gateway Bridge:
Sep 24 00:10:39 ip-xxx-xx-38-11 lora-gateway-bridge[2711]: time=“2018-09-24T00:10:39Z” level=info msg=“backend: publishing packet” qos=0 topic=gateway/240ac4fffe0009c8/stats
Sep 24 00:10:39 ip-xxx-xx-38-11 lora-gateway-bridge[2711]: time=“2018-09-24T00:10:39Z” level=info msg=“backend: config packet received” topic=gateway/240ac4fffe0009c8/config
Sep 24 00:10:39 ip-xxx-xx–38-11 lora-gateway-bridge[2711]: time=“2018-09-24T00:10:39Z” level=warning msg=“gateway: configuration was not applied, gateway is not configured for managed configuration” mac=240ac4fffe0009c8
image
It seems that the nano gateway after several minutes was connected, but now the problem is the Lopy node device, the packages do not reach the nanogateway, but a gateway from ttn does.