TimeStamp Issue - Join Request and Accept Work - Packet Rejected Timestamp Wrong

Do you still see proper downlinks for confirmed uplinks of other devices?

Does anyone think that regular downlinks (using RX1 of 1 second, RX2 of 2 seconds) might have a different latency than OTAA downlinks (RX1 of 5 seconds, RX2 of 6 seconds)? Like maybe TTN delegates regular downlinks to the gateway a bit earlier (compared to the transmission time), or maybe some intermediate network components might still be active for shorter RX intervals?

So earlier you rebooted the full gateway a few times per day (which also restarted the 3G connection), and now you’re only restarting the packet forwarder every 30 minutes (which does not affect the 3G connection)?

If missing downlinks (for ADR or the confirmed uplinks) make the device start a new join, then I’d say you should have seen the same problems in the past, if the 3G latency was not much different then. But as the problem only started (immediately) after introducing the automatic restart of the packet forwarder, I’m tempted to say that somehow the (3G?) latency was increased when something changed in that gateway.

If your backend keeps track of the frame counters, then you can see how often the device has re-joined in the past (which would reset the counters).

But I guess all that doesn’t help fixing the problem.

(Asides: TTN allows for at most 10 downlinks per day, but that’s not enforced yet. Likewise, at SF12 it only allows for 1 message per hour, when only sending 3 bytes… But maybe it has dropped to SF12 as it’s not receiving the downlinks. Also, if the device has been joining a lot then at some point you might want to read OTAA shows "Activation DevNonce not valid: already used". But all that is unrelated to your current problem.)

1 Like