Probably because it give you ability to run automatic tests where you can set predetermined date and time and run some sequence.
That could be handled in Ekos (I imagine) by allowing an offset from system time, or to stop it.
Read More...
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.
Read More...
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.
Read More...
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.
Read More...
James, 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.
Read More...
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
Read More...
I have recently completed a OnStepX controlled system (the board was an already finished JTW Astronomy unit, so I'm not concerned about electronics errors).
In setting it up I added sensors to detect the Home position, and set this up while flashing the device. Reading the documentation I understand that in this case the device can find the Home position by looking for a transition in the Home sensors -- they have a 180 degree "blade" to distinguish the 2 halves of the possible movement: essentially a 1-nit encoder. The documentation describes the 3 stages of closing in on the Home position using these sensors.
However, the INDI OnStep driver does not do this. In fact its behaviour on selecting "Return Home" is not understandable. -- BTW: "Return Home" might be understandable if "Find Home" existed, but it does not.
That's INDI. But Ekos is worse, as it has no provision for finding or going home at all.
Either I need some tuition or there's something wrong ; (
Read More...
I share your frustration. In my case I want to use the Align module which is broken in 3.6.9 (see indilib.org/forum/ekos/14373-align-rever...previous-object.html) but fixed in 3.7.0. It's pretty fundamental.
And yes, I've been trying to build for macOS for weeks but the build environment is broken.
Maybe that's why it's taking so long. It would be good to know what's going on.
Cheers,
Richard
Read More...
Go for it ! The Pi 5 is a nice machine and you can always find a use t=fir the pi 4 even if it only works with Ethernet (eg a WeeWX server, an INDI AllSky server, etc)
Read More...
