UPLINK_FCNT_RETRANSMISSION on Laird RS191

rsebi · June 12, 2024, 7:26pm

Sensor: Laird RS191
Gateway: Femto IoT Internal Gateway(test), Laird RG191 (Production)
Distance: 10m (lab), 50m(production)

I am facing the following issue on chirpstack (v4 in test,v3 in production) with laird sensors

v3 error:
“type”: “error”,
“payload”: {
“applicationID”: “16”,
“applicationName”: “sen-7”,
“deviceName”: “sen-7”,
“devEUI”: “***”,
“type”: “UPLINK_FCNT_RETRANSMISSION”,
“error”: “frame-counter did not increment”,
“fCnt”: 217,
“tags”: {},
“publishedAt”: “2024-06-12T19:05:22.645543605Z”

v4 error:
{
“time”: “2024-06-12T19:14:11.184668413+00:00”,
“deviceInfo”: {
“tenantId”: “52f14cd4-c6f1-4fbd-8f87-4025e1d49242”,
“tenantName”: “ChirpStack”,
“applicationId”: “799f8080-8f92-439b-bd78-ca2987b15950”,
“applicationName”: “sen-1”,
“deviceProfileId”: “96a8e18e-db2b-4e95-8486-2c4d507869b4”,
“deviceProfileName”: “Sentrius RS1xx Temp-RH Sensor”,
“deviceName”: “sen1”,
“devEui”: “***”,
“deviceClassEnabled”: “CLASS_A”,
“tags”: {}
},
“level”: “WARNING”,
“code”: “UPLINK_F_CNT_RETRANSMISSION”,
“description”: “Uplink was flagged as re-transmission / frame-counter did not increment”,
“context”: {
“deduplication_id”: “81a7b638-3344-4234-83b3-bdd9bafe5543”
}
}

Remedy Tried:
In v4 increased rx0 time to 3 seconds, and then 8 seconds. Making no impact to the issues faced. After error 4 or 5 error transmissions, subsequent transmission goes on DR0 and the next transmission goes back to DR3 which is DR used by other RS191 on chirpstack v4.

Any insight or suggestions are most welcome.

Liam_Philipp · June 12, 2024, 7:30pm

Try turning off the f_count verification in the device’s settings, that will make it so Chirpstack will accept multiple of the same f_counts and you can figure out what the device is really trying to do. Send a photo of the events and device_frames after. Note that disabling f_count verification makes you vulnerable to replay attacks but for the sake of debugging it can be very helpful to see what the device is actually sending.

Also is the device set to confirmed uplinks? Could be that the downlink from the server is not reaching the device.

rsebi · June 12, 2024, 7:33pm

I can definitely try this in my test setup.

Will now wait for next set of error window.
Thanks!

rsebi · June 13, 2024, 4:44pm

Since the change was made to sensor(1) settings, i see no more error on sen1 however, I see the error has now moved to another test sensor(3) which previously did not have any record of retransmission error.

All laird devices do come with confirmed uplinks by default.

These are values of last good packet received by sen3.

rssi:-11
snr:10.3
channel:3

The following are values after retransmission error faced by sen3.

rssi:-8
snr:11.8
channel:6

Liam_Philipp · June 13, 2024, 5:06pm

What about the f_count of the device that has f_count verification disabled, does it properly increment by 1 with each uplink? Could you share the events / frames?

Don’t know what to say about the error being “passed along”, hopefully a coincidence and not a serious bug.

My current assumption is that there is an issue with the device receiving the downlink from the confirmed uplink. How far away from the gateway are your sensors?

rsebi · June 13, 2024, 5:55pm

What about the f_count of the device that has f_count verification disabled, does it properly increment by 1 with each uplink? Could you share the events / frames?

yes they look good now. I do not see any missing frame count. Following is screenshot from sensor with frame counter disabled.

Following is screenshot from sensor which faces retransmission error. (frame counter enabled)

How far away from the gateway are your sensors?

Test setup sensors are in direct line of sight located less than 5 meters from gateway.

Liam_Philipp · June 13, 2024, 6:01pm

Try moving the sensors a bit further like 15 meters, I’ve read before that having the sensor very close to the gateway can cause the gateway to receive the message multiple messages.

If that is not the issue, the device without the f_count verification is incrementing properly so it is not an issue with the device incrementing, it must be an issue with the device receiving the downlink, and then retransmitting the message. This can be tricky to debug, does your gateway have some type of monitoring where you can confirm that the downlink was broadcast?

Liam_Philipp · June 13, 2024, 6:02pm

Also please share the “device frames” from the one with fcount verification disabled, as it shows the “confirmed up” and “unconfirmed down” packets.

rsebi · June 13, 2024, 6:14pm

We did try this and the error is still happening.

We do have logging on gateway and will try to followup on it.

Attaching single frame of sensor1 - 1 each of downlink and uplink.

unconfirmed datadown:

{
    "phy_payload": {
        "mhdr": {
            "m_type": "UnconfirmedDataDown",
            "major": "LoRaWANR1"
        },
        "mic": [
            26,
            94,
            35,
            11
        ],
        "payload": {
            "f_port": null,
            "fhdr": {
                "devaddr": "01fb310d",
                "f_cnt": 888,
                "f_ctrl": {
                    "ack": true,
                    "adr": true,
                    "adr_ack_req": false,
                    "class_b": false,
                    "f_opts_len": 0,
                    "f_pending": false
                },
                "f_opts": []
            },
            "frm_payload": null
        }
    },
    "tx_info": {
        "context": "dE+MGw==",
        "frequency": 923300000,
        "modulation": {
            "lora": {
                "bandwidth": 500000,
                "codeRate": "CR_4_5",
                "polarizationInversion": true,
                "spreadingFactor": 7
            }
        },
        "power": 21,
        "timing": {
            "delay": {
                "delay": "8s"
            }
        }
    }
}

confirmed data up:

{
    "phy_payload": {
        "mhdr": {
            "m_type": "ConfirmedDataUp",
            "major": "LoRaWANR1"
        },
        "mic": [
            180,
            200,
            14,
            242
        ],
        "payload": {
            "f_port": 1,
            "fhdr": {
                "devaddr": "01fb310d",
                "f_cnt": 887,
                "f_ctrl": {
                    "ack": false,
                    "adr": true,
                    "adr_ack_req": false,
                    "class_b": false,
                    "f_opts_len": 0,
                    "f_pending": false
                },
                "f_opts": []
            },
            "frm_payload": "01015c2c4a160400000000"
        }
    },
    "rx_info": [
        {
            "context": "dE+MGw==",
            "crcStatus": "CRC_OK",
            "gatewayId": "****",
            "location": {},
            "metadata": {
                "region_common_name": "US915",
                "region_config_id": "us915_0"
            },
            "nsTime": "2024-06-13T18:08:30.818226497+00:00",
            "rssi": -41,
            "snr": 9.800000190734863,
            "uplinkId": 53634
        }
    ],
    "tx_info": {
        "frequency": 902300000,
        "modulation": {
            "lora": {
                "bandwidth": 125000,
                "codeRate": "CR_4_5",
                "spreadingFactor": 7
            }
        }
    }
}

Liam_Philipp · June 13, 2024, 6:22pm

Everything looks normal there, doesn’t look like any band-mismatch is happening. If the downlink is being sent from the gateway I don’t know what else would cause this issue besides the device simply failing to receive it.

rsebi · June 13, 2024, 6:29pm

I would want to attach more however i do not see a button to attach a file. But yes everything looks normal to my eyes too. I probably have scoured through all device technical manual for this and found no reason. I also wish to add that i tested on TTN cloud with same gateway and sensor and found no retransmission error.
I also have tektelic and browan sensors which runs on both confirmed and unconfirmed packets and yet to face any retransmission errors on chirpstack v4.

Overall this causes an issue for us because we have an api that works on this data and it gets lost when there is continuous retransmission error in the data stream.

Liam_Philipp · June 13, 2024, 6:46pm

I still think you should (if possible) verify that when the retransmission errors occur the gateway did send the downlink response to the device.

One thing I am pondering is that if there is a real issue with the device receiving the downlink you should be able to see the device retransmit the same packet multiple times in the LoRaWAN frames when f_count verification is off. Essentially the 5 f_count errors should become 5 of the same packets. Is that the case? If not, maybe this is a Chirpstack side error where something causes it to just spit out a bunch of f_count erros and possibly something Brocaar might want to dig into.

Other than that I think your only options are work arounds. The way I see it your options are:

Disable f_count verification for all the devices (probably not viable for security reasons)
Change the devices to unconfirmed uplinks (if possible on device)
Create a middle man between your API and datastream that filters out the errors.

rsebi · June 13, 2024, 10:55pm

Thanks for the steps and troubleshooting guidelines. I will reach out to vendor as well to make sure we cover all tracks.
Should @brocaar require any further information will be more than happy to provide them. I will likely have my test chirpstack v4 server and more than 10 sensors handy.

For obvious reasons we cannot use this in production or even test site as we are in a high IoT density area.

RS191 does not have an option though the app but i will dig around lora commands to try and set it. This was not previously required since all setups for these sensors could be done via their own app before deployment.

This will be the next step as as mentioned earlier we have to make sure that LNS or the hardware is not faulty and I am always in my learning curve.

Cheers.

system · September 11, 2024, 10:56pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.