KStars is extremely unreliable at timekeeping. I have been using Ekos for scheduling and countless times I have found it starts the schedule a hour or two late because KStars has lost the plot and is running way behind real time. This can happen even it was synchronised the night before.

I find this behaviour strange and antiquated. I'm running on a Mac. Macs, like pretty well all modern computers, including R-Pi, use NTP and have timekeeping as good as necessary.

Every other planetarium program I've used uses the computer time to generate its internal time. KStars seems not to, having something like a water-clock, or worse, inside. In its preferences there is the option to have KStars tell the mount what time it is, or the mount tell KStars, or have both controlled by GPS (see below).

Why not NTP or the computer's clock ??

As for GPS -- hah! I have a rack-mounted, GPS-based NTP server in the observatory. As well as NTP services it provides a serial line with NMEA sentences. Neither of these work with any of the 3 INDI GPS devices. I've bought a couple of GPS-USB dongles (U-Blox, a well known brand) and they don't work with INDI either.

The only use case I've seen for INDI GPS devices is a bizarre concept of converting a mobile phone into a wifi-based NMEA source. This is a desperate solution when there are cheap, handheld GPS receivers with hardwired NMEA output. Not to mention other permanent solutions. Why are these hardwired NMEA connections not supported?

Sorry to be grumpy, but I'm a bit fed up with this pathetic timekeeping.

Richard

Can't speak to the issue with the Mac time...
But for KStars under Linux (several different versions that I did articles for setup with on), I have had no issues since I started using the GPS dongles I got from Amazon.
astrowhat.com/articles/setting-up-kubunt...ty-to-the-system.58/
I use mini PCs for the control unit for the telescopes. I only use my Mac to remote into those PCs.
I wonder if your issue is something to do with the Mac OS version of KStars?

Richard, is your issue is that KStars time lags behind real time if you leave it open for extended periods of time?

Jasem, yes that's basically it. I do leave all the systems running indefinitely (4 different computers, with various weather, seeing, dark sky etc monitoring, observatory monitoring, hardware control and monitoring and 2 planetarium apps). I have TheSkyX Pro running on the same computer as KStars because I use it as the interface for my Paramount.

I finished a session last night and by this morning KStars is 2-3 sec behind TheSkyX and the computer clock.

2 nights ago I missed a good part of our short summer nights because KStars was over 1.5 hours slow and was late starting the schedule.

Can you check if this time drift from your system clock? Because otherwise you may need to sync time by clicking that clock icon and setting it to NOW. But yes there should be probably real time mode when kstars clock is kept in sync with system clock.

Nou, yes, I do use this NOW button to resync. But this depends on me remembering to do it, and so is not very reliable.

So either there should be an implicit sync with the computer clock or there should be an additional option in the INDI panel (in the settings) for computer clock sync, and/or NTP sync.

An example from this evening:
Computer clock: 23 Apr 20:30
KStars: 23 Apr 02:35

This is worse than a water clock. More like a hamster wheel, with a sleepy hamster.

How fast this drift happens? I looked at code and there SimClock class that seems to handle timekeeping. It use monotonic clock which means when it start it make store current time as startTime and how many milliseconds that monotonic clock show. Then it return time as startTime + elapsedTime from monotonic clock. As far I can tell there should be no accumulation error. Monotonic clock are not affected by change of system time. That mean KStars doesn't reflect on change of system clock.

So only disrepancy between KStars time and real time should come from drift in that monotonic clock. I wrote simple testing program that output difference between monotonic and system clock. Monotonic clock is running 10ms/hour faster than system clock on my system.

Also I let run KStars for few hours and didn't observe any drift between kstars clock and system clock. So that 18 hours drift most likely mean some faulty hardware clock. Because 18 hours drift even over one month period means it drift 90 second per hour. I am pretty sure someone would notice such huge drift.

I semi-frequently see the clock off by several hours. If you shut KStars down while it is set to current time, it will often start up again set to some bogus time. Sometimes I remember to check this and fix it, but sometimes not.

I don’t think I have ever noticed drift, but I’ll let it run a while and look for it.

OK, I just played with this a bit and see two problems (this is on Mac).

1. If you bring up the Set Time panel in KStars and choose "Now", it sets the time in the panel to current time. But the actual chart time is not changed until you click OK. This always results in the chart time being a second or two behind the computer's time.

2. If you put the Mac to sleep (or let it go to sleep), when you wake it up again the chart time has not advanced since it went to sleep. It will keep advancing at 1 second per second, but it will be off by the amount of time sleeping.

Both these problems indicate a fundamental problem in how KStars keeps time. When you click the Now button in the Set Time panel, this should set a "realtime" mode. When in this mode the time should always be obtained from the system clock (or wherever you've specified the time to come from). KStars should not be trying to keep it's own version of time unless you have explicitly changed the it from "realtime".

I think you've nailed it here Bill. The Mac concerned is on the observatory and it does go to sleep for long periods when I'm not imaging.

Your post, together with the code inspection from Nou, shows that KStars does not have a robust approach to timekeeping.

I have tried changing the time setting to 'Mount updates KStars', since in my case that is a TCP link to TheSkyX, which does have robust timekeeping. but I have't seen any improvement yet.

Another problem with the set of 3 options (i.e. beyond the problem that there is no option of computer clock or NTP) is that they miss some obvious use cases. Imagine you have a GPS-based time (so 'GPS updates KStars'). Then you would also want 'KStars updates all devices' but selecting that option deselects the GPS.

This is oversight from time when KStars was only planetarium so you wanted to have clock with ability to go forward and backward. For some reason they keep using this simulated clock withing Ekos too. Probably because it give you ability to run automatic tests where you can set predetermined date and time and run some sequence.

I started to work on option that will lock KStars clock to system clock. So if you set NTP or GPS synchronisation you should never see this issue again.