Try the nightly or build the git.
Cheers

So even without the force realign option I can still make it realign after each job with this option right?

This has been coming up on the SGP group as well. What seems to happen, at least with PHD2, is that if the guide star is lost behind a cloud for a few minutes the mount cn drift sufficiently that when stars reappear a different one is detected and guided to the same place. After all all stars look the same.

What I've been wondering is if this could be managed in the guider by collecting a pattern of stars over the frame and comparing the pattern. If the pattern shifts then the guider guides it back to the correct position as part of the re centering process. Using multiple stars may also improve guiding by reducing the star position noise. I'm not sure if there's enough processing power to do this every guide frame though.

The scheduler/image collection process only sees a message from the guider that guiding has failed and pauses image acquisition. The guider only signals that guiding has resumed when the mount has been moved to the correct position. The scheduler/image acquisition modules shoud have nothing more to do.

No.

Chris,

We think alike. You have just described the algorithm already implemented in SEP Multistar!

See
invent.kde.org/education/kstars/-/blob/m...guide/guidestars.cpp
invent.kde.org/education/kstars/-/blob/m...arcorrespondence.cpp

I had originally implemented it to be totally unconstrained, so that it could conceivably recover from large shifts,
but when testing with @alacant (Steve), I found his setup, when looking at dense star fields, for some reason could trick it.
I wound up compromising and having SEP Multistar not accept a guide-star detection if it was outside the guide reticle (which you can set up to 128x128).
Perhaps I should allow that reticle to get larger, or allow SEP Multistar to locate its guide star further away.
The other issue that could come up is that guiding currently has a check that causes it to fail if the guide error (distance from desired guide star location to located guide star location)
is too large. Of course, we could experiment with disabling this check too, but for all things like these, it's hard to guess the side effects.

Hy

causes it to fail if the guide error (
Hy, everyone
Please at least make it an option. Disabling something which helps guiding on less than perfect mounts perhaps isn't gonna bring many benefits.
Cheers and clear skies,
Steve

Any good news on this topic ?.

I did add something several weeks ago
invent.kde.org/education/kstars/-/merge_requests/221
just after 3.5.2 was completed (i.e. will be released in 3.5.3) which should make the guider a little more robust to losing the guide star.
This is something along the lines of what I described above.
Still, if a cloud comes by and obscures the image for several guiding cycles, guiding will fail.
In that scenario, the scheduler needs to come to the rescue, and I trust Wolfgang and Eric's wisdom on those issues.

Hy

Maybe add option that if there was no guiding for 5-10 min trigger align?

My temporary solution is to use CCDciel instead of Ekos.

What if we just run plate solver on each exposed frame and queue realign on next frame if we drift too much from target?

This thread is still in the pipe for Scheduler changes, but unfortunately don't expect a quick update to the code here. We still have things to fix in CI prior to this.

-Eric