I can't remember which one I use, but not all of them will work with the Hy's wonderful Terrain (backyard image) feature that maps the trees and neighboring houses onto the sky. Any projection that does't work with that is dead to me!
I also use an miniPC (mine's AMD not Intel) for my home imaging setup. I find KStars/Ekos to be perfectly comfortable on the Pi4, but occasionally I do lunar and planetary and for high-frame rate video capture the Pi just can't come close. I can get anywhere from 3x to 5x or more frames per second on the miniPC. Once it's out there under the scope there's no point swapping it back out for the Pi.
On the other hand, I use a Pi all the time up at my cabin or on the road because it's so much power efficient. I have no line power at all at the cabin, so everything has to be charged off solar, and I just can't see wasting watts on a miniPC.
I rarely compile anything on the Pi, and just work with the ubuntu repositories. Running KStars is just no trouble at all on the Pi, especially when I'm asleep! The interface is just a little bit laggy compared to the mini, but not so much that it bothers me.
I use one of these too. Point of clarification though:
IR is very useful to detect clouds but not rain. If all you want is to close when it's cloudy that will work for sure. What you want is a seasonally-dependent *difference* between air temp and IR sky temp. The actual sky temp varies too much for a single threshold to work.
But the real bugaboo is rain. Failing to close when it's cloudy is no big deal. You just have some bad subs to delete. Failing to close when it's raining can destroy your expensive equipment. IR doesn't help you here except that closing when its cloudy will usually mean you're still closed when it starts pouring.
But you should also look into a rain sensor in addition to a cloud sensor. These work by either detecting moisture using electrical conductivity of a metal grid (most also include a heater to prevent corrosion after the rain stops), or an optical sensor that actually "sees" the drops on a lens.
I find that the stable version (3.5.4 stable) crashes at random maybe once or twice a week on ubuntu 20.04.2 LTS (amd64).
I gave up using the FITS viewer and this helped a little. The crashes don't seem to be consistent or related to any particular action (not associated with meridian flip, or focusing, or losing guide stars, or slewing, or plate solving, for example). Just BAM, no more kstars. The mount continues to track but nobody's home. Wake up in the morning, park the mount, and hope for another clear night sometime soonish.
I'm taking a few months off of imaging and hope things are more stable in 2022.
This would be a fantastic feature, especially for imaging the moon during daylight or twilight when stars are unavailable.
Because this is unavailable in Ekos, I routinely switch to TheSkyX *just for autofocus* and then switch back to Ekos. TheSkyX "@Focus3" uses a gradient (contrast)-based focus metric that produces razor-sharp results by focusing on the Moon.
Implementing this in Ekos would require an alternative focus metric but (in my naive expectation) no new code or logic for moving the focuser, computing the curve, solving for the optimum position, etc.
"Sharpness" metrics are well-studied because it's the basis for autofocus in conventional photography. Daytime photography (eg, in your phone) can't use star sizes. The kind of focus metric required for Ekos to autofocus on the Moon is in fact the metric used by virtually all autofocus logic in the world.
The math is well defined and there are gradient libraries available in many languages to make it fast and reliable.
I calibrate near the meridian near the equator and then save and reside the calibration for weeks and maybe months.
Seems to work just fine. I typically get guide rms < 0.5 arcsec
Wow I had no idea this was possible!
Can ASIAir Pro run generic ubuntu/KStars? Or just StellarMate?
It would be great if there were an option in the scheduler to do a new alignment after X subs, but there's not.
You can fool the scheduler into this behavior by splitting your imaging into lots of short jobs and then doing them all in a row. But yes! Please include this as an option in a future update!
Happens to me too, with kstars 3.5.4 stable on kubuntu 20.04.2 LTS
My last three clear nights have been cut short while I slept by what appear to be random crashes of KStars 3.5.4 on ubuntu 20.04.2 LTS (miniPC not Pi).
I know that there's a bunch of detective work that's possible for random crashes, involving running in the debugger and analyzing logs.
I also know that my crashes don't involve the FITS viewer, which I've disabled.
Maybe I will embark on the detective game, but wow. This is dispiriting. Everything appears to be running really well and then out of nowhere POW. No more KStars.
I wake up in the morning with all the equipment on and the mount tracking and nobody home to collect the data. Over and over.