Hello, forum.
I am new to the LoRaWAN technology is there any way to calculate the packet delay.
when I send my packet from the end node (Arduino) I have the real-time from the serial port but when I received it by the TTN it’s not obvious. It showed the air time that depends on some parameters (SF, BW,freq, payload size) and it easy to calculate ** and its not depend on the distance.**
so if I send the packet with 3 KM it does not take the same time as when I send it with 100 M. so where I can find the time that is received by the gateway to calculate the time delay.
1-can I say the timestamp (the server time) is the real-time that received by the gateway and what is the Z letter at the end ??
2-the normal time that showed in the gateway traffic or the application one represents as the hour, min, second, and what I need is more accurate (the fraction).
thanks for all the efforts
Why do you want to know the delay ?
You may be confusing ToF with TDoA, Time-of-flight vs Time-difference-of-arrival
https://www.digikey.com/en/articles/simplifying-time-of-flight-distance-measurements
3 km at 300,000 km/s is 10 micro-seconds
100 m at 300,000 km/s is 0.333 micro-seconds
To measure time-of-flight you need an accurate clock on the sending side and a time-stamp. End-devices do not have a nano-second accurate clock, they will drift at several ppm.
For TDoA you need accurate time-stamps at the gateway. Only the Semtech v2 gateways are currently capable of providing nano-second time-stamp for TDoA. Most gateways on the market will be v1.5 versions without this capability.
Hi @haidarm,
ref your Q1; The timestamp shown is the time as received by the network server. The timestamp is in ISO8601 format. The “Z” on the end is for “Zulu” time which is UTC.
ref your Q2; The web console list page only shows hh:mm:ss. When you expand it as you appear to have done in the image you show it shows the full JSON including the ISO8601 timestamps with the fraction of the second.
for comparision with simulation and some statistical measurements .
but its not applicable i think cause its its drifted too much some cases more than one min at sf12
thanks for the replay, im my case with arduno its impossible to get the right time stamp …
thanks for the replay. I think it must be accurate but when today’s test I got more than one min differences as shown in the pic for two different packets
Well, I hope you understand what that means.
I will try my best with the help of that community …thanks for the efforts.
LMiC doesn’t typically produce any debug output when it actually transmits, because it then has to open precisely timed receive window(s) shortly thereafter and typical ways of producing serial output on an MCU incur some delay which the authors of various ports have some concern could disrupt the receive window timing if not implemented with a high degree of care.
The practical result is that in your logs the actual transmission go out just a few seconds before the EV_TXCOMPLETE messages, NOT at the Packet queued messages - those have to be interpreted a bit literally, the packet has been staged but NOT yet sent.
thanks for the replay … I got it …