For what I understood the pps is usually internally connected to the lora wan rf for time keeping, if the signal is not available the gateway use something like an ntp sync. The question is simple, which is the main advantage when the gps is available and the pps is running? Yeah of course a more accurate timestamp, but how a better timestamp can enhance the system? at least which level of the stack get advantages?
Honestly I didn’t find a clear documentation on where the pps is involved.
Thanks for the tip. However I already did.
It is still not clear, in which way an high precision timestamp could enhance the the packet forwarder?
I think I’m missing a fundamental understanding of some parts of the lora wan network, this is the main reason because I opened a new thread.
In other words, what will happen if the pps is not available and the ntp from the network return an high drift timestamp?
Take in account, my network (at least for now) doesn’t need to triangulate, knowing that a packet arrived with x nano seconds of delay compared to another gateway is useless for me. Also for what I know the ADR doesn’t take in account timestamp but only the noise.
I’m quite sure the reason is simple but I’m missing it.
In short, a gps does not anything of value if you don’t have the Semtech proprietary decoding algorithm.
The essential timestamps required for the network to function do not require gps or ntp. The most important time value is a timestamp generated by the concentrator when receiving the packet. That one is used for timing of the return packet.
The “ UTC time of pkt RX, us precision” field can drift minutes without any issues (in TTN at least).
Semtech has the high resolution timestamping code that allows (with sufficient gateways etc etc) localization. That requires GPS with PPS.
And GPS is required for the exact timing for Class B support as well. I usually overlook Class B as TTN does not provide it. (TTN V2 does not provide Class C either but Class C does not require GPS)