# TimeStamp Issue - Join Request and Accept Work - Packet Rejected Timestamp Wrong **URL:** \ **Category:** LoRaWAN Discussions\ **Created:** [January 24, 2020, 4:04pm UTC](https://www.thethingsnetwork.org/forum/t/timestamp-issue-join-request-and-accept-work-packet-rejected-timestamp-wrong/33644 "2020-01-24T16:04:16Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [January 27, 2020, 1:30pm UTC](https://www.thethingsnetwork.org/forum/t/timestamp-issue-join-request-and-accept-work-packet-rejected-timestamp-wrong/33644/12 "2020-01-27T13:30:40Z")
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? > [@harveyben](#): > > The solution with Kerlink Support was to set up some form of cron job to automatically restart the Gateway packet forwarder every 30 minutes. Before this we were rebooting the gateway several times a day. 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](https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy-guidelines/1300) 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"](https://www.thethingsnetwork.org/forum/t/otaa-shows-activation-devnonce-not-valid-already-used/5079). But all that is unrelated to your current problem.) --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/timestamp-issue-join-request-and-accept-work-packet-rejected-timestamp-wrong/33644)._