I’ve seen several threads about people wanting to disable positioning via GPS , but keep processong the 1PPS signal.
I’m using 2 x Raspi-IMST88xx based GW’s , and have no GPS connected.
I have set static GPS coordinates , and have NTPD up & sync’ed (stratum 2).
I seem to remember there was a 1-PPS input on the IMST board and that makes sense if you’re NOT connected to the internet. But as “almost all” TTN units are using the internet , why be concerned about 1-PPS.
What am i missing ??
Does the IMST88xx board only timestamp via 1-PPS or ???
Does the IMST88xx board only timestamp via 1-PPS or ???
Traditional packet forwarders don’t convert to a wall-clock time unless you use a GPS PPS input, yes.
Essentially the state of the local system comprising the gateway (including what time its operating system thinks it is) isn’t considered to be terribly relevant in a LoRaWAN network - it’s job is to transparently pass things. There is latency between the software and the LoRa chip, and more latency on the network, but there isn’t seen to be a lot of utility in trying to parse that latency to one side or the other.
When a GPS PPS signal is present, then a hardware path into the LoRa chip captures the value of the gateway’s 32-bit microsecond counter in relation to the PPS signal. This can then be fixed up by software against the later serial time output of the GPS to build an essentially latency-free model for converting hardware timestamps to times, and a new PPS should arrive before that model can drift out of credibility.
What exactly is the goal that you are trying to accomplish by applying a local wall-clock-time annotation from an approximate NTP source to received packets, vs letting the server approximate the received time?
I’m not trying to accomplish anything , was just wondering why people that enabled static LAT/LON still wanted 1-PPS. And maybe learn something about the timestamping in my IMST board, which i just did , thank you.
My gateways doesn’t have GPS attached, and I wanted to know if timestamping then was done via “OS Time”. And would benefit from NTP diciplining “OS Time”.
As for NTP timestamps to be approximate …
Yes compared to a “decent gps 1-pps” that is usually within 30…40ns , with a good view to the sky
The NTPD on my Raspi usually disciplines the clock to be within 300us from the upstream peer , that in my case is a 1-PPS stratum1 server. NTP packet Jitter is around 200us. So NOT your average wall-clock.
