First uplink is retry confirmed

TTN Network and Services
1

For some reason, the first message that I send from a node appears in the console as “retry confirmed”.

00%20PM

This is odd, since there is no other message from the same device with the same frame counter (at least, since the join).

This does not happen all the time, but is fairly repeatable. I am using LMIC library. I am queuing a message immediately after join confirmation.

I thought retries simply mark duplicate frame counters - is this not the case? What is the logic for determining if a message is a retry?

2

It seems your screenshot shows the device’s Data page. Do you also have access to the gateway’s Traffic page?

The screenshot is also missing the first message, with counter zero. (Or does your node always start with counter value 1?) And are the uplinks indeed confirmed uplinks, or is that bogus too? What do you see for the meta data when you click that uplink to expand its details?

Even though it seems you had TTN Console open during your testing (as the Join Accept is shown as well), its output might just be incomplete? Do you get the very same output if you connect an MQTT client?

How do you initiate the join? Most LMiC examples just rely on the fact that LMiC will join when the first packet is scheduled.

3

Hey @arjanvanb

Thanks for the reply! I’ve circumvented this issue for now by adding a longer delay between my JOIN_ACCEPT and my confirmed uplink, but I’m still not sure how it happened in the first place. Here are the answers to your question:

The screenshot is also missing the first message, with counter zero. (Or does your node always start with counter value 1?)

This is the first message - there wasn’t a message with counter zero. That message wasn’t a confirmed uplink, and I think it was lost.

And are the uplinks indeed confirmed uplinks, or is that bogus too?

This message was a confirmed uplink, so it is supposed to get an ack.

What do you see for the meta data when you click that uplink to expand its details?

Sadly, I no longer have the console data, so I can’t look at the expanded meta.

Even though it seems you had TTN Console open during your testing (as the Join Accept is shown as well), its output might just be incomplete? Do you get the very same output if you connect an MQTT client?

I’m not using a MQTT client, but I am using the HTTP connecter. My application server gets the same output from that - despite being the first message it’s marked as a retry.
This is an issue because I usually ignore retries at my application server, since I assume I’ve already handled the original message.

How do you initiate the join? Most LMiC examples just rely on the fact that LMiC will join when the first packet is scheduled.

I send an initial, uncomfirmed, empty payload uplink to initiate the join (this is the lost message with counter 0)

1 Like
4

That’s what I’d investigate then, as that probably confuses LMiC or TTN. Like maybe it’s using port number 0? Or what if you send at least a byte, or remove it altogether?

5

Ah, I seem to be able to reproduce this, if I re-join after only sending a single uplink.

In my case the first uplink has frame counter 0, and the uplinks are unconfirmed. But if I do not let the node send more than a single uplink after an OTAA Join, the first uplink after a rejoin is tagged as a retry (also in MQTT). The time between the uplinks before and after the re-join is at least 5 seconds, being RX1 for an OTAA Join. If I have the node transmit at least two uplinks, then after a new join the first uplink is not labeled as a retry.

Note that in your case, where you first send an empty packet to initiate an OTAA Join, it’s actually the second packet that is labeled as a retry… But then the empty packet might confuse TTN as well.

I guess filing a bug is not worthwhile as all development is currently focused on the network stack version 3. As it’s easy to create a sketch for, say, the The Things Uno to reproduce this bug, I guess I’ll submit a bug report next weekend.