1. Messages
  2. APCC feature request - Get time from mount

Re: APCC feature request - Get time from mount

Dale Ghent
 

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.

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:

I think that I understand the user's scenario.

They have initialized the mount from a device with accurate time. In my case, I sometimes initialize my mount from Luminos on my phone which has accurate time.

They then connect the computer to the mount. Having spent most of my working career as a software engineer, I have pretty much zero trust in the real time clock on most computers. If they are continuously connected to the internet and syncing to a time source, then they are pretty good, and they tend to stay pretty accurate while running. When you power them down, though, they lose their time information and have to retrieve it from the real time clock when they boot. Partly because I'm a bit OCD, and partly because I do a daytime polar alignment, I want the most accurate time and location information as accurate as possible. Computer real time clocks can drift a noticeable amount over a few days.

The solution that was requested here is to have either the ASCOM driver or APCC able to get the time from the mount and update the PC's time. I would love a similar feature where APCC can use GPS time to update the computer clock. I already have APCC connected to a GPS receiver, so that it can get location information. And APCC can show me the GPS time - but it cannot update the PC clock. As I mentioned in an earlier reply, I believe that this is because updating the PC clock requires administrator privilege, which is not available to APCC unless you "run as administrator", and that is strongly discouraged.

There are workaround for this to be sure. I have multiple, accurate time sources. My watch syncs nightly to a time source. I could just read the time from the watch and enter it manually, for example. What I've chosen to do is to connect a second GPS receiver to my computer. I then have a service that I installed that has sufficient privileges to periodically update the PC time.

It would be convenient for APCC to offer this feature. I could then remove the service, and one of the GPS receivers, from my imaging computer. But I understand why it may not be possible (privileges).

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Mike Dodd
Sent: Sunday, September 26, 2021 8:20 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC feature request - Get time from mount

On 9/26/2021 10:51 PM, Brent Boshart wrote:
...The original poster was referring to a circumstance where the
computer is not connected to a network (internet).
NEVER?

If the PC or laptop can be connected to a network every few days (maybe with a wi-fi dongle), the network time sync software could accurately set it then. Most PC clocks are good enough to maintain fairly accurate time over several days.

Or, as The he said, a GPS dongle would do the job. They're inexpensive.

Worst case: Set the PC clock manually by watching an analog clock on a cell phone, and clicking the PC clock button when the cell clock second hand passes 12.

--- Mike
Join main@ap-gto.groups.io to automatically receive all group messages.