Re: APCC feature request - Get time from mount
System privileges aside, time synchronization is not as simple as taking a raw NMEA sentence from a GPS or (worse) an undisciplined source, and scribbling whatever it says into the system clock without any further consideration. It's a complex topic and really is best left up to apps that are designed for that task.toggle quoted messageShow quoted text
Using a mount's CP, via the ASCOM driver and then APCC on top of that and all the serial, OS, and COM glue in between those components, doesn't make me feel like pretending that the mount is a disciplined time source is something that'll be accurate. For one, I don't think the CP even has a hardware RTC (there's no battery to change out in it) or, if it does, if it is temperature compensated.
That said, using the CP as a time source could be considered if a future CP version had some hardware and software additions that allow it to be a proper one instead of a hackish, ad hoc one. A "CP-next" could have:
* It would have a hardware interface (GPIO or RS232/TTL) that can interface with a GPS receiver either built-in or accessory; the antenna location is separate and largely site-specific consideration. Obviously having the antenna down on the CP itself is no good if the thing is sitting under a dome.
* A hardware RTC that is also battery-backed so that it can keep time while unpowered. This would reduce the initialization time of a connected GPS on a cold boot.
* It would run an embedded OS (already exists on the CP4/5) that can operate a time service which properly disciplines its own local clock and run a NTP/SNTP service so that any system that's connected via ethernet or wifi to use it as a stratum 1 time server.
The time service itself would know how to handle GPS initialization and syncing. I would not offer this over a PC's USB/serial connection to the CP simply because the code and mechanisms needed to address complexities of time sync over those many moving parts would need to be introduced; and these are things that the local OS's NTP client would already have built-in. The time service being NTP over the CP's ethernet/wifi would also make it available to any modern OS and system arch; something that could not be done if exposed only by the ASCOM driver or APCC.
But, after all that effort and rigamarole, one could still just have the GPS connected to their PC and a proper app such as NMEAtime2 to discipline the clock. The existing APCC/A-P ASCOM driver options can write the time to the CP during initialization. This is what I do currently and it works *just fine*. The ublox GPS dongle that I use is stuffed into a port on my telescope-mounted USB hub. So I don't really see a compelling advantage for the mount to be a time source as there still needs to be a GPS receiver somewhere in the mix; and right now the best software for GPS-based clock discipline is available for any PC and modern OS (NMEAtime2 on Windows, and any of the menu of NTP daemons/services for *NIX OSes.)
On Sep 27, 2021, at 08:37, W Hilmo <y.groups@...> wrote: