You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repository and believe that this is not a duplicate.
What happened?
When viewing device data I suddenly saw that multiple errors were present. All of which were UPLINK_FCNT_RETRANSMISSION. After some investigation I found out that this happens when via a LinkADRReq the NbTrans gets set to a value greater than 1.
What did you expect?
I expected no uplink frame-count retransmission error events to be generated when inside the bounds of the NbTrans when a device is configured by the Network Server to retransmit uplinks a certain number of times.
Steps to reproduce this issue
Environment:
Raspberry Pi 3 b+ running alpine-3.15.0 aarch64
Docker version 20.10.11
Latest Docker images for AS, NS and GB from dockerhub
The follwing ADR plugin cross compiled for aarch64 with Go version 1.13.8
package main
import (
"github.com/hashicorp/go-plugin"
log "github.com/sirupsen/logrus""github.com/brocaar/chirpstack-network-server/v3/adr"
)
// Type Handler is the ADR handler.typeHandlerstruct{}
// ID must return the plugin identifier.func (h*Handler) ID() (string, error) {
return"test-nb-trans", nil
}
// Name must return a human-readable name.func (h*Handler) Name() (string, error) {
return"Test NBTrans ADR plugin", nil
}
// Handle handles the ADR and returns the (new) parameters.func (h*Handler) Handle(req adr.HandleRequest) (adr.HandleResponse, error) {
resp:= adr.HandleResponse{
DR: req.DR,
TxPowerIndex: req.TxPowerIndex,
NbTrans: req.NbTrans,
}
if!req.ADR {
returnresp, nil
}
return adr.HandleResponse{
DR: req.DR,
TxPowerIndex: req.TxPowerIndex,
NbTrans: 2,
}, nil
}
funcmain() {
handler:=&Handler{}
pluginMap:=map[string]plugin.Plugin{
"handler": &adr.HandlerPlugin{Impl: handler},
}
log.Info("Starting ADR plugin")
plugin.Serve(&plugin.ServeConfig{
HandshakeConfig: adr.HandshakeConfig,
Plugins: pluginMap,
})
}
I'm running into this issue too. Does Unconfirmed uplink messages still get ACKed by the gateway? The issue I'm seeing is that my device sends an Unconfirmed Upload message to the server, once every 10 minutes, and all is well.
But if the gateway was off, or the device was out of range for a few messages, then the Unconfirmed uplink message isn't ACKed(because the frame counter has advanced and is higher than the server expects?) Then the device sends 3 Unconfirmed Uplink messages every 10 minutes.
The only way to get the device out of this 3 message re-transmission mode is to reset/join the device.
Can Chirpstack not re-acquire the frame counter if the counter sent by the device is HIGHER than expected?
Edit: looks like Chirpstack DOES resync after an hour or two? Never given it that long to resolve the issue by itself.
This issue is somewhat related to #502.
What happened?
When viewing device data I suddenly saw that multiple errors were present. All of which were UPLINK_FCNT_RETRANSMISSION. After some investigation I found out that this happens when via a LinkADRReq the NbTrans gets set to a value greater than 1.
What did you expect?
I expected no uplink frame-count retransmission error events to be generated when inside the bounds of the NbTrans when a device is configured by the Network Server to retransmit uplinks a certain number of times.
Steps to reproduce this issue
Environment:
Steps:
Device payloads of retransmissions
Retransmitted frame:
QOq8GgGACQABD/tOR7II8BPz574 at frequency: 868.3
Orignal frame:
QOq8GgGACQABD/tOR7II8BPz574 at frequency: 867.9
Part of log from relevant situation
Your Environment
The text was updated successfully, but these errors were encountered: