Hi community,
I wondering if it would be possible to use the board’s GPS for an own stratum 1 NTP time server which could decommission an existing one based on a separate Raspberry Pi with a discrete GPS board? I’m not sure the access would interfere with the packet-handler. Any comments/ideas?
Current packet forwarders open the device exclusively. You would need to modify the packet forwarder to allow for sharing the gps device.
Thanks kersing, that’s what I feared the most 'cause it’s understandable for time stamping priority reasons to do so. Nevertheless I think it could be worth to have a closer look on this since the benefits of that solution could be interesting for many of us. There are common requirements (failproof, UPS backed, reachability, power saving, etc.) for both applications.
The question is what the savings would be compared to the investment. Also question is it wise to combine the two functions in one device. A (unintentional) DOS of the ntp server would bring the LoRaWAN gateway down as well (and vice versa)
While a packet forwarder typically consumes the GPS serial (or in some cases possibly I2C to leave the serial free for other use) output directly, it doesn’t really need to - the precise timing is accomplished by the concentrator chip itself recording the PPS signal against its internal timer, the serial message in then parsed to determine which second that was. So a slight delay from doing something like consuming the message with something else and then passing it over on a local or unix socket or pipe should probably not be an issue.
It’s not clear if your ntp scheme needs the PPS signal. If it does some electrical re-routing may be needed. Once you are doing that, running the serial signal to two UARTs could be a possibility, though if you are on a pi you really only have one - using a USB serial device is likely to introduce more latency than a reasonable software sharing scheme would.
For that matter, it may be worth considering if having the GPS referenced timestamps for the LoRaWAN gateway functionality is really accomplishing all that much for you - especially in the case where you can get a fairly correct system time. It’s possible that the simplest solution could be to modify the packet forwarder to not open the GPS port and not be GPS referenced, and let the ntp own it instead.
Thanks cslorabox. Yes indeed, the NTP’s accuracy depends on PPS signal and uses the single UART of the Pi. USB isn’t an option due to the mentioned latency. I think the solution will be more or less on the s/w side.