"retry confirmed" in application data view - what does it mean?

1

Can anyone tell me what this message means please ?

“retry confirmed” and whether it matters?

2

Was this a confirmed uplink, which was also received (forwarded) much sooner by other gateways?

If yes, then something similar seems to to happen with some Ali Express Dragino LG01-S LoRa Gateway:

3

Hi @arjanvanb, at the Dragino LG01 it looks a little different: I just get exactly the same packet delayed by ~10 secs. Both packets are identical. They are just marked as “reply”. In @patmolloy 's screenshot the above packet shows no counter and payload, the one below does. Maybe it helps.

1 Like
4

@schulti the top message is unrelated to the question; it’s a downlink (a downwards icon). So, @patmolloy is hardly providing any details, and I merely added a reference to your nice findings for future readers. (I assume that for this very question it might even be a true retry; we cannot tell lacking details.)

(As an aside: you meant “retry”, not “reply” like you wrote above, right?)

5

@arjanvanb you are right: “retry” :wink:

6

I was also in the APPLICATION DATA view, and yes it was a confirmed message … I am pretty sure my gateway is the only one in range. The retry confirmed message was on my uplink. There is no payload on the downlink. Here is the full thing …

The data is making it through, so I am not sure what the “retry” is all about … I am only seeing it with one transmitting device (the IMST Mote ll), not others (e.g. MicroChip LoRa Mote, and some homemade things …) … Here visualised in Cayenne.

7

Then the obvious probably applies: it simply was a retry as the node somehow did not receive the confirmation and, well, tried again. And each uplink will show a downlink that is the confirmation (which @schulti does not get for the unrelated problem with the slow gateway).

It seems to me you apparently don’t need a confirmed uplink, so please send unconfirmed messages then. Confirmations need downlinks, and when a gateway is sending a downlink it cannot receive any uplink at all. So downlinks, and hence confirmed uplinks, should be limited as much as possible. (And will be limited to only 10 per day on The Things Network.)

2 Likes
8

Thanks, All understood now. I am learning!

9

One might also see “retry” (with or without the “confirmed”) if the very same transmission is received by multiple gateways, but one gateway is much slower to forward the packet than the others. The metadata will then reveal it’s a different gateway but the same channel/frequency, so most likely the very same actual transmission:

image

image

10

I have pretty much the same thing as @patmolloy.
It looks like that all the time:
grafik

For example, message 16 was already confirmed but the same message was “retry confirmed” afterwards. According to you answer @arjanvanb, that the node didn’t receive the confirmation first (and because of that a new confirmation was send) this woulnd’t make sense.
Does somebody have an idea how to explain that?

Thanks in advance!

11

I can see a confirmation downlink was sent, but did your node receive that?

For frame counter 16, the next uplink with the very same frame counter is 6 seconds later. I doubt such delay could be caused by a slow gateway (if the packet was even received by multiple gateways), but maybe some other problems (like slow handling of some queues in the backend servers) could cause the same thing.

For frame counter 15 the difference is only 1 second, so maybe that’s a slow gateway after all.

So, to tell if both uplinks are received by the same gateway(s): peek into the uplinks’ metadata by clicking on both the 15:54:20 and 15:54:26 lines. (And while looking there: also compare the channels/frequencies that should be different for a retry.)

Yes, and: no. If the node did not receive the confirmation then it would have retransmitted the uplink, and hence have requested a new confirmation. The “retry confirmed” is displayed on an uplink, so that’s a message as sent by your node, not by TTN. (And yes, after that, TTN has sent another confirmation downlink.)

Why not?

As an aside: the seconds in the timestamps are weird; it looks like TTN sends downlinks before it even receives the uplink that requested it (like the downlink at 16:54:19 for the uplink of 16:54:20).

And on a related note: it seems you’re sending all your uplinks as confirmed uplinks. Your node can use at most 10 confirmed uplinks per day.

12

Thank you for answer!

I only have one gateway in the range, hence both messages were received by the same gateway. But you’re right, they have different frequencies.

What’s the use of having this hint in an uplink message?

I just started working with Lora and did not know that. So far, the device is in the default settings.
I sent much more messages than 10 a day and got for every message a confirmation. How is this possible if the number of downlinks is limited?

13

Hi friends,

I’m facing with a problem, Last week my device (RAK811) worked well, it sent messages continuously in all day and TTN received all messages. But from yesterday, the TTN was only success received few messages, then one message had been retry confirmed 8 times, then TTN stopped display new message.

After I restarted my device and gateway also, the problem happened again, and not fixed today.
image

Anyone can help me to find rootcause and fix this problem?

Br,
Hai Nguyen

14

I can confirm what @arjanvanb mention in this thread. I had to change my code to send “unconfirmed” messages by using the modem.endPacket(false) instead of modem.endPacket(true) with the mrkwan arduino library to achieve this. How I do no longer receive retry messages with the same content. Thanks for pointing to this!