"frame-counter did not increment" happening sometimes on uplink

Devices
#1

Hello! I am trying to figure out an issue I am seeing with all of my devices in their current configuration.

I am periodically seeing frame increment errors, but I can’t figure out the source. I am hoping you can help me figure out if this is a configuration issue between my gateway / chirp / device, or if its an RF connectivity issue.

I have played around with the configuration a bit with no luck. However I noticed when changing the max data rate in the Service Profile in ChirpStack from 3 to 2 it almost completely eliminated the frame increment errors, however I still see this error every 20 uplinks or so.

image
image3256×1826 233 KB

My chirp stack is running in docker-compose at https://chirp.takkacor.com
My sensor is: RM-191 module running LoRaWAN 1.0.1
My gateways is: RG-191

#2

Unfortunately not an answer to your question, but I have faced the same/similar issue with my devices as well. In theory: This error is supposed to trigger at the event of a replayed uplink packet. However, I have seen it trigger so often and from different devices that I doubt it is actually a replay attack.

I spent a lot of time trying to figure out the source of the problem and at this point I am almost giving up.
In my case, I get a few of these retransmission errors per device after a successful uplink, this happens for a few uplinks and then they stop showing for a while. The timings between the retransmissions are consistent, as well as the timings for the periods of uplinks that are followed up by these errors.

I have different types of devices and the error happens will all of them, which makes me believe that the issue is not at the device side. I also experimented with two different gateways (IMST Lite and Wirnet iFemtoCell) and saw the error in both cases.

@takka-bryan Question: do you have many devices in close proximity from each other? and/or in close proximity to the gateway? I have somewhere around 100 devices and two gateways in one building (two floors).
I am starting to think it could be some sort of echoing/bouncing of the signal between devices’ antennas that generates these replayed uplinks because of their close proximity, but I am not at all an expert in communication or electromagnetism to be sure of that :sweat_smile:

@brocaar Question: have you seen such behavior when deploying many devices in close proximity from each other?

#3

@hbilal Thank you for the response, and it’s good to know that I’m not alone in having this issue. Perhaps we can all figure out what’s going on.

I can tell you with high certainty it is not an issue with too many devices. I am able to easily reproduce the issue with a single device sitting right next to my gateway.

@brocaar I’m curious if you’ve seen this issue yourself. Thanks in advance for any advice!

#4

Probably due to nb_trans and ADR.

ADR asks the device to repeat sending its packet n times. If no packet loss happens with nb_trans=3 in the next interval, you will see two duplicates in your logs, while only the first packet was processed.

2 Likes
#5

Hi All isn’t this just caused by mid-air collisions on the uplink?
I see this in my lab test network only when I have more than one end device running and send at quite a high rate.
P

#6

Opp no, if you are using LMIC check this: LMIC.upRepeat = ?
RN2483,: no access to NBRep :frowning:— ADR can set this from the network side

#7

Sorry to revive old post…

I am seeing this with a dragino device, on further research, came across this link: Notes for ChirpStack - Wiki for Dragino Project

I am however not sure where to change this in the TOML files or f this requires a change in the underlying code before packaging. Anyone have any pointers?

#8

Can anyone help with changing the nbtrans in Chirpstack? ( the value to determine the re-transmission time for unconfirmed uplink data.)