Device rapidly sending port 0 messages
SloMusti opened this issue · 4 comments
The issue has been observed on a few devices deployed in the filed, where they start sending port 0 messages - mac commands at a rapid pace (every few seconds) until they are rebooted. This appears to be some anomaly related to the MAC commands form the network server.
To resolve this issue, it would be good to understand the mechanism what can trigger this @GrumpyOldPizza . Alternatively I need to find a way to safeguard against it.
Well, first off, do you know what mac commands they are sending off ?
The best thing you can do is to look at the source code and use a ST-Link debugger to see what is going on.
Debugging is unfortunately not practical, as this only happens to a few devices in the field after a while, haven`t been able to reproduce this in the lab yet.
At this point, also the mac commands are not logged and available. Generally the network server is not configured to be sending any.
As the first action, a monitor logic will be implemented on a few devices to detect how many messages are transmitted that originate from the stack itself, then we can better understand the case.
@GrumpyOldPizza managed to get a better debug of the issue. Device keep sending the RXParamSetupReq to which the network server does not respond or send the ack. What triggers this behavior is unknown, device reset resolves it for a while, which can be up to a month and then it may repeat again.
{
"cid": "RXParamSetupReq",
"payload": {
"channelAck": true,
"rx2DataRateAck": true,
"rx1DROffsetAck": true
}
},
Has there been any updates? I believe I am experiencing the same issue.
TTN is reporting that the last time it had seen the device was "Now" but it has not actually displayed any data in the console.
The "Now" has not gone away for over 3 hours.