Hello,

In the past few weeks, I had little time with clear skies, but I noticed that when a cloud briefly crosses the FOV, the EQMOD mount shifts a little and don't preserve the primary object (in my case was M82) in the center of the FOV. Here is an example of a sequence of images 30-sec shots from left to right...

The solution that I have is to restart the scheduler so that the plate solver would center the target again. Did anyone face a similar situation, and how to prevent it?

Thank you
      

Hi,

reported this already 2 months ago indilib.org/forum/ekos/10569-guiding-swi...-the-wrong-star.html with log file that clearly shows Ekos taking the wrong guide star.

No reaction, nobody seems to care (same as for the fact that not all remote drivers work with latest rekeases: eg asicamera1, asiscamera2 ....

Paul

Thank you for the report. Right now scheduler only restart astrometry on guiding calibration failure and not on guide failure. I suppose it could be made to also reset astrometry on guiding failure related to loss of star.

We have worked around this problem for a while. One of the options for example is forcing a re-alignment before starting a job. That means ahead of each job iteration, aligning is executed. This way you at least avoid loosing too many frames that are off target.

I would think in a different direction: why do we not execute plate solving for each captured frame and react as soon as we detect being off target? This way we could capture all those problems like lost star events but also drifting through guiding pulses.

I was going to suggest performing plate-solving when the guiding star is lost for more than 2-3 frames. IMO adding plate solving to the beginning of the job is not going to solve this problem, as it happens AFTER the job is already started and in progress (in the above example it happened from img20 to img25), and plate-solving EACH captured frame is so resource-intensive.

@Jasem
I don't understand this behavior of the internal guider (IG). I believe what is happening is that the IG was tracking the guide star, then lose it for a frame or two, then another star pops up from the cloud in the periphery of the captured image, IG search and find this new star and ASSUME it is the same guide star it was tracking and tries to bring it to its original location. If we treat the newly auto found star as a new guide star and just keep guiding based on the new parameters (just trust the mount), I think this will fix many problems. Adding a plate-solving option after losing the guide star will assure accuracy.

I think this would be an overkill and would consume too much time in capture and solving each image. Restarting alignment procedure on guiding failure would be much easier to implement. Drifting shouldn't be too much of a problem now.

@mohammad, was guiding ever aborted during this? then resumed?

Jasem,

look at the log file in this thread indilib.org/forum/ekos/10569-guiding-swi...-the-wrong-star.html

It is exactly the same problem. Even if the "old" guide star is in the image, another one is taken for the olf one and guider starts sending crazy pulses (even bigger than allowed by setting if i remember correctly)

My solurtion: PHD2

Paul

Hi jasem, no, I didn’t abort the guiding. Just checking every now and then, and found the target off center FOV.

For this kind of problem, i not use the scheduler. i look at the guide window and in case of clouds i stop all

Was the guide process aborted (by itself) and then resumed? or it wasn't aborted at all?

In my case, when a cloud hides the guiding star for seconds and not appear again, the systems continues guiding sending pulses as much the value in Maximum pulse. This cause that the telescope move out the field, and then I need to stop the schedule (or the plan) and run the platesolver to center it again, or restart the Scheduler