Duplication of message

I am experiencing that the same message arrives twice (suspect this), anyone have experience this?

If I query my BD, I pick up that there a quite a few messages that arrives within a seconds of each from my v3 application in TTN and get posted to my DB.

All these messages are from tracking data and I don’t suspect the node, as these messages have the same coordinates although the tracker is travelling at +100Km/h.

So what part of the json from TTN will possibly indicate duplication - as the messages are possibly from two different gateways (cant ID the gateway as they are v2 gateways) as the RSSI are different.


have read

1 Like

On the TTN v2 stack, a duplicate message was indicated by the “is_retry” field, see https://www.thethingsnetwork.org/docs/applications/mqtt/api/index.html
This was occasionally seen for devices with a super wide geographical reach, like balloon trackers.

In the TTN v3 stack, I can no longer find a similar field, possibly it no longer exists: Data Formats | The Things Stack for LoRaWAN

Perhaps the “is_retry” property was actually internally present in the v2 stack, but lost somewhere in the bridge between v2 and v3.

1 Like

Is f_cnt different for the duplicates?

This kind of duplicates can happen if the node uses confirmed uplinks. The node does not receive the confirmation (download) and transmitts the packet again without increasing the fcnt.

@mfalkvidd I don’t save the f_cnt in my DB, my application is in V3 and the gateway is a V2, so will need to experiment if the f_cnt is present in V2 to V3 instances.

@wolfp I cant find a setting in my node that sets confirmation of packet, so I am not sure if it does it or not.

@bertrik if the “is_retry” were maybe in v3 it would be easier to disregard duplicate msg.

“frm_payload” - Frame payload (Base64) - Can you decode it? And what does it tell you about the frame?

Can you get the packet at gateway level? If so paste it (skip the keys) at https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 1366
   FCtrl.ACK = false
   FCtrl.ADR = true

So my device sends “Unconfirmed” data.

So is it then maybe two different gateways forwarding the same msg. to the application? And the application think it is two different msg. due to the latency between them?

A few weeks ago I observed something similar with my Dragino LHT65. Looking into the log of my gateway I saw, that after the reception of a downlink (imho MAC-command) the LHT65 startet to transmit every message twice on different frequencies but with the same data and fcnt. The time-difference between this messages was 7 seconds.
Then after a further download (after 6 uploads) this behaviour stopped.
Until now I cant imagine what was going on.

1 Like

If I look at my DB these duplications accrue regular. You will notice this duplication and then for a few msg it’s normal. The duplications are +/- 7 seconds apparat.

I will store a bit more information from the msg now. Need to add some fields to the DB and then see.

1 Like

I’m not sure if this applies to TTN as well, but i have experienced this in a private LoraWAN (Swisscom LPN) when ADR is enabled. When reception was poor the Gateway sometimes not only advised the node to increase SF and TXPower, but also to send each message several times. The MAC command is:
MAC.LinkADRReq.Redundancy.NbTrans : 2
for 2 transmissions. Even had 3 sometimes.


You are right - there is a MACparameter called adr_nb_trans that can cause retransmissions.