Get Connected!
Come and join our community. Expand your network and get to know new people!
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.
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...
Don't you have a guide camera? You can't guide using the main camera while also using it for imaging.
I have two trains, one specifying the image camera. This is set as the one to use in the CCD tab. I also have a Guide train that specifies the guide camera as the Camera. It also specifies the mount as the "Guide via" device.
Read More...
Well, then I feel lost.
I just have one imager and the mount. No extra device dedicated to guiding.
So, shouldn't I set guiding to none ?
Also, as I don't use extra guiding device, the train is the same in all tabs.
I'll check as soon as I can take photos again, but I think I had to do this way, otherwise it did not work at the time I set it up.
Then, I don't modify anything that works, until I face situations where it fails.
Read More...
Hi Keith,
Click on logs and then set the settings I circled in red...
The Open Logs Directory button (bottom right) will launch a file manager / file explorer / etc in the logs directory so you can then send the relevant (date-timestamped) file.
I suppose the only thing I noticed from your screenshots is that you have a step size of 200 which on some systems will be too big and may take you outside the range at which stars are detected. I don't know if that's the case on your equipment but be aware with number of steps = 11 and step size = 200 you'll move 1000 ticks out to take the first datapoint.
Read More...
Bill - I agree with you. That's the set up I have - the mount is set as the guide device.
Read More...
The guide device should be set to Mount in the train you use in the Guider panel. If you set it to "--" (i.e. None) , then it won't be guiding. At least that is my understanding.
Read More...
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".
Read More...
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.
Read More...
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.
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.
Read More...
A suggestion.
Would it be better to have "All Sky camera management software" as a separate Category on the forum rather than having every single
issue on the one thread ?
We have been getting 100's of updates on this for months on issues that don't have anything to do with original post.
Nick
Read More...
It sounds like you only built the core INDI library. You would have had to build the 3rd-party repo to get the additional drivers. I will work on making my instructions less confusing.
Read More...
Hello! I resolved it by installing Ubuntu instead of Raspiberry OS. In Rasp the only drive that appeared was the simulator. This time the indi drivers were loaded correctly. Thanks.
Read More...
I get the artifacts on the skymap also using both Remmina and TigerVNC.
.
When using VNC over the Stellarmate Hotspot, the VNC connection eventually freezes up and the connection becomes unusable. This only happens with the Skymap over the Hotspot using any VNC program. .
.
If I connect the Rpi to my home network or the mount's handset's router via WiFi or if I plug an ethernet cable directly into the Rpi, then it works normally - with the artifacts.
.
If I can stay away from the Skymap and use only the Ekos and INDI driver pages, then the VNC connection over Hotspot works reasonably well. But once I go to the skymap then the Rpi side freezes and needs to be power cycled.
.
I believe this freezing is happening to only the graphics system since ekos and INDI still operate the mount and cameras normally. I just cannot access any controls. I can still SSH normally into the Rpi and run command line tools such as htop.
Read More...