Hi,
I have an issue with a sensor (NKE Modbus Bridge) at one particular gateway: in the grafic below you can see that after the initial join, a downlink is sent to the sensor for each uplink received. After x Uplinks (not consistent), the sensor stops sending Uplinks. Some time (not consitent) later, he will send again a Join request to restart the cycle.
The Sensor supports LoRaWAN 1.0.2. and is setup as Class C Device with OTAA. A second sensor is working fine (connected through another gateway and different organization to the same network server).
Step 1
The phyPayload of the first uplink looks as follow:
"phyPayload": {
"mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
"macPayload": {
"fhdr": {
"devAddr": "0181707c",
"fCtrl": {
"adr": true,
"adrAckReq": false,
"ack": false,
"fPending": false,
"classB": false},
"fCnt": 0,
"fOpts": null
},
"fPort": null,
"frmPayload": null
}
},
"mic": "f2613547"
}
Step 2
The network-server immediately sends the first downlink:
"phyPayload": {
"mhdr": {"mType": "UnconfirmedDataDown", "major": "LoRaWANR1"},
"macPayload": {
"fhdr": {
"devAddr": "0181707c",
"fCtrl": {
"adr": true,
"adrAckReq": false,
"ack": false,
"fPending": false,
"classB": false
},
"fCnt": 0,
"fOpts": [
{
"cid": "LinkADRReq",
"payload": {
"dataRate": 5,
"txPower": 0,
"chMask": [true,true,true,true,true,true,true,true,false,false,false,false,false,false,false,false],
"redundancy": {
"chMaskCntl": 0,
"nbRep": 1
}
}
},
{
"cid": "DevStatusReq",
"payload": null
}
]
},
"fPort": null,
"frmPayload": null
},
"mic": "a8e05de7"
}
Two MAC commands are contained:
-
LinkADRReq
: requesting the sensor to perform a rate adaptation to dataRate 5 -
DevStatusReq
: requesting status information. According to LoRaWAN specs, the sensor must respond withDevStatusAns
.
Step 3
This is followed again by the second uplink:
"phyPayload": {
"mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
"macPayload": {
"fhdr": {
"devAddr": "0181707c",
"fCtrl": {
"adr": true,
"adrAckReq": false,
"ack": false,
"fPending": false,
"classB": false
},
"fCnt": 1,
"fOpts": [
{
"cid": "LinkADRReq",
"payload": {
"channelMaskAck": true,
"dataRateAck": true,
"powerAck": true
}
},
{
"cid": "DevStatusReq",
"payload": {
"battery": 0,
"margin": -10
}
}
]
},
"fPort": null,
"frmPayload": null
},
"mic": "408a0929"
}
Apparently, the sensor acknowledged the LinkADRReq
and responded to the DevStatusReq
.
According to the LoRaWAN specs, he should however do so with LinkADRAns
and DevStatusAns
.
Step 4
The network server sends an immediate downlink again:
"phyPayload": {
"mhdr": {"mType": "UnconfirmedDataDown","major": "LoRaWANR1"},
"macPayload": {
"fhdr": {
"devAddr": "0181707c",
"fCtrl": {
"adr": true,
"adrAckReq": false,
"ack": false,
"fPending": false,
"classB": false
},
"fCnt": 1,
"fOpts": [
{
"cid": "LinkADRReq",
"payload": {
"dataRate": 5,
"txPower": 2,
"chMask": [true,true,true,true,true,true,true,true,false,false,false,false,false,false,false,false],
"redundancy": {
"chMaskCntl": 0,
"nbRep": 1
}
}
}
]
},
"fPort": null,
"frmPayload": null
},
"mic": "d8e05f48"
}
This time, only LinkADRReq
is send.
Step 5
The sensor comes back with the following uplink:
"phyPayload": {
"mhdr": {"mType": "UnconfirmedDataUp","major": "LoRaWANR1"},
"macPayload": {
"fhdr": {
"devAddr": "0181707c",
"fCtrl": {
"adr": true,
"adrAckReq": false,
"ack": false,
"fPending": false,
"classB": false
},
"fCnt": 2,
"fOpts": null
},
"fPort": 125,
"frmPayload": [
{
"bytes": "NiLnCxlbWQXj7XnUYNk/ubgYW4mVogb3ze6Yc21ACg=="
}
]
},
"mic": "43999959"
}
The LinkADRReq
has been completly ignored, the sensor sends only regular payload.
Now the cyclic behavior starts:
- an upload arrives (without any MacCommands) (message as in Step 5)
- a downlink is send with
LinkADRReq
(message as in Step 4)
-…
After some time, the sensor stops sending uplinks. Some time later, it rejoins the network. This has been consistent over the last few days, with typically 5-200 iterations and 30-90min breaks in between.
Any idea how to stop this / what might cause this?