Yes, you are right, temperature has a big impact on it. But the same happens if you image one night at 15 degrees and another night at 5 degrees.
Read More...
Thank you Euripides, your feedback and experiences are also hugely appreciated! And again the crucial advice: don't upgrade. Do it rarely and only during off-time.
Yes, John has done a tremendous job, both in the algorithms that he added, as well as the support to debug and improve them. I've had some interaction with him during an early release of the Linear 1 Pass algorithm, when we discovered a bug related to backlash settings, which he corrected super quickly.
Hard wiring is indeed the way to go, and that is in the plan.
Using regular home automation is an interesting tip as well. Although coupling it to actual imaging sessions (you only turn camera on when the sky is clear and roof is open) will then probably require some scripting again.
Thanks again for sharing your experiences, much appreciated.
CS, Willem Jan.
Read More...
Derek, thank you so much for sharing your experiences. This was exactly the type of feedback I was looking for.
Regarding reliability, yes I agree, this depends as much, or even more, on the equipment than the software. And I'm sure some of the reliability issues I have encountered over the years had to do with setting up and breaking down the system each time. As much as you do it the same each time, a cable snag, a loose screw, or a differently plugged USB cable is always around the corner and can cause issues. That would be much less of course in a remote observatory. Not upgrading, or only rarely and only during off-time is another very good suggestion.
As far as automation goes, you have worked out a nice setup. Like you say, for the last 10% or so, writing scripts is probably the way to go. It makes a lot of sense, just another thing to keep in mind. The 'monitoring it for a while' before letting go automatic is exactly how I use it now as well. Interesting you mention that first autofocus run needing a bit of tweaking, as that is exactly what I experience as well. But the goal would be to build the setup such that this initial monitoring is not necessary. Perhaps too optimistic?
Indeed weather monitoring is done centrally, so that takes some complexity out of the equation. But still need to respond to an incoming boltwood file that indicates a (temporary) closing roof.
Again, thank you very much for sharing your experiences, much appreciated.
CS, Willem Jan.
Read More...
Thanks Euripides, great to hear you have used it successfully. Main background of my post was to gather experiences from users that are actually using KStars for robotic imaging. Do people use it that way, and if so, what do they like and what would they like to see different. As I will setup a rig in a remote hosting observatory, should I keep using KStars, or better looking for an alternative?
Some areas of concern that I would have right now are:
Reliability. How often did you experience interruptions, due to failed autofocus routines, crashes of a driver, or the whole app, updates, etc. In my current non-remote setting, all these happen from time to time, but as I’m usually following what’s happening, I can often quickly correct and move on. But in the planned robotic setting, I may not look at it for a couple of days, so if something goes wrong on day 1, that would be a lot of imaging time lost.
Robotic scheduling. What is your experience with the scheduler? How well does it work in ‘robotic’ mode, so run startup activities lets say an hour before dawn, switching equipment on using dragonfly, start imaging at Astronomical night, image from a list of targets, figuring out priority based on visibility, moon distance, distance around meridian, % completion, manually set importance, etc., and switch equipment back off in the morning and go to sleep until the following evening. I am not a programmer, so writing scripts would not be an option for me.
Are you still operating remotely? And still with KStars?
Many thanks for your thoughts.
Willem Jan.
Read More...
Just wondering if anyone has experience using KStars/Ekos to run a remote observatory automatically? Remote here meaning many hours traveling away. And automatic as in load a series of targets in the scheduler and let the system start/stop automatically each night, handle emergency stops etc.
If so, what were reasons to choose KStars/Ekos over usual suspects such as Voyager, Prism, NINA, etc.?
KStars/Ekos has been at the heart of my imaging for many years, including the occasional use of the scheduler. But so far always just meters away from the rig, just in case....
Read More...
Something weird has happened during the upgrading process. Normally I run the update manager from Linux (Linux Mint 20, Ubuntu 20.04). Apparently only the INDI library was upgraded, not KStars. When running the software it still says 3.6.3. While if I look in the INDI change-log, it mentions 2.0.2 (20230531).
Manually upgrading does not work either. I get a message saying that 3.6.3 is already the latest version.
Any ideas how I can force it to upgrade to 3.6.5?
Read More...
I haven’t tried this in a while anymore, and kind of gave up. I’ve replaced the focuser on my Mac system with a non-Primaluce lab focuser and use the Esatto and SS2 now on Linux only. Perhaps in the meantime there have been updates in the firmware that might help?
The WiFi capability of these focusers is a kind of hotspot functionality. Even if it connects, it would not work for my setup, as the WiFi signal would be much too weak to run my in-house computers on.
Would really be great to have a solution for this, as it will essentially lock out more and more Mac users with Primalucelab focusers and Kstars.
Read More...