Scott Denning replied to the topic 'Meridian flip' in the forum. 2 weeks ago

Pretty sure the Ekos Scheduler will NEVER call the goto *during* an exposure.

The logic is as Hy describes. AFTER an exposure, if the hour angle is greater than the specified flip point, Ekos does a goto to the current RA/DEC. It's the mount (not Ekos) that flips.

Peter, from what you describe, your CEM120 does almost the exact opposite of my CEM40! If my mount is within the "tracking past the meridian" limit and Ekos tells it to slew to its current RA/DEC, nothing happens at all.

On the other hand, you describe your mount as performing a flip regardless of what Ekos is doing. In that case the correct thing for you is to just disable the meridian flip in Ekos and let the mont take care of it.

Remember, all Ekos can do is a goto to the current coordinates. It's the MOUNT (not Ekos) that has to know it's time to flip. Many mounts can track well beyond the meridian. If you have your mount set to track say, an hour past the meridian and Ekos tells it to slew to current RA/DEC 5 minutes or 30 minutes past, nothing will happen.


Scott Denning replied to the topic 'Meridian flip' in the forum. 2 weeks ago

For me, the key to successful meridian flips has always been to make the mount settings (either in the driver or the hand control) consistent with the way I'm asking for a flip in Ekos.

For example, set the meridian limit in the mount to something small, like 1 degree past the Meridian. This tells the mount to flip if a GOTO is executed to coordinates more than 1 degree past the meridian

Then in the Ekos scheduler, set the Meridian Flip to take place 3 degrees past the Meridian.

The mount tracks past the meridian, taking exposures. When it reaches 3 degrees west of the Meridian, Ekos issues a GOTO to the RA/DEC to which the mount is already pointing. As Hy says, it's the MOUNT (not Ekos) which then executes the flip.


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!


Scott Denning replied to the topic 'NUC10 vs RPI4b/SSD' in the forum. 2 months ago

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.


Scott Denning replied to the topic 'kstars died last night' in the forum. 3 months ago

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.


Scott Denning replied to the topic 'Autofocusing the moon' in the forum. 4 months ago

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!