TTN & GPRS: dealing with the latency

TTN Network and Services
18

This is not an answer, but just in case it helps:

  •  INFO: Received pkt from mote: D00XXXX0 (fcnt=46037)

    This is a Join Request. The printed DevAddr (which is not a secret) and counter are bogus but that’s not an issue.

  • Seeing the first Join Request at the gateway’s wall time of 10:45:33.971123Z, and then the retry at 10:45:40.253025Z is more than 6 seconds later. Also, 2287977668 - 2281695764 yields 6.281904 seconds now. That’s nicely after RX2, so that’s good; earlier it seemed we saw a difference of only 5.3 seconds, but I guess we can discard that occurrence.

  • WARNING: [up] ignored out-of sync ACK packet
...
PULL_DATA sent: 3 (133.33% acknowledged, ping 1915.86 ms)

    This out-of-sync error and the funny 133.33% also seem to confirm latency issues.

Does anyone know if TTN supports JIT queues for the Semtech UDP protocol? (And above all: would then send the downlink commands much earlier? If TTN supports it, but as TTN is clearly not showing that in this case, then the protocol version in the TCP dump messages might be relevant? That’s apparently the first byte in the TCP/IP packet.)

Also, I wonder if “TOO_EARLY” isn’t a bug, which should read “TOO_LATE”. If it is, then I’d assume Kerlink would have fixed that long ago, making me wonder if there’s more recent software available. But then: even if reported back to TTN I wonder if it’s acting on that error (by, say, sending the downlink command earlier next time).

2 Likes