In some situations, the Ekos Guiding module ignores, that PHD2 failed to start guiding. As a result, the Scheduler waits forever and neither starts capturing nor restarts guiding of PHD2.

The problem occurs, when PHD2 cannot find an appropriate guiding star, sends a"settling failed" event and terminates guiding. Briefly, the following happens:

• 02:25:12: star lost timeout
• 02:25:13: guiding and capturing aborted
• 02:25:13: scheduler restarts guiding
• 02:25:22: PHD2 reports failed to find a suitable guide star, status line: No star selected
• 02:25 - 03:26: scheduler waits for a positive or negative answer from PHD2

Is there anybody out there who is familiar with the Ekos guiding module sources? I have an idea what to fix, but I would really appreciate having somebody who at least cross-checks it.

- Wolfgang

Well, as always, it's not that easy. Currently, the guiding interface ensures that a state is reported only once. If we simply call the PHD guide command again - as it is currently implemented in the Scheduler - the settling problem will not be repeated if it remains.

If we change the guiding interface behaviour sending the same event twice in a sequence, the frequency where the Scheduler will get the problem reported is by approx. once a second. Since the Scheduler only retries guiding only five times in a sequence, the job will abort with an error stage after approx. 5 seconds. This is definitely not the behaviour that we would expect.

It would be great, if there is somebody out there with experience to fix this, because this problem has substantial impact on the robustness.

- Wolfgang

I made an attempt to improve the robustness of the guiding module - see diff D21739 . It contains the following improvements:

1. Directly skip scheduler stage to capturing when guiding is already running. During the scheduler startup, the scheduler module recognizes if guiding is already running and directly jumps to capturing.
2. Recognizing settling errors and handle them as aborted guiding. When using PHD2 as guider, EKOS recognizes settling errors. They occur for example when no guiding star can be found during the attempt to start guiding.
3. Restart guiding with increasing delay. When a guiding problem occurs while starting the guiding, restarting guiding is delayed by an increasing delay.

Feedback and critics warmly appreciated.

Hi
Would this solve this?
www.indilib.org/forum/wish-list/4594-sch...-obtain-another.html
A lost guide star spelling the end of imaging is a show stopper for us.
Cheers and thanks for your effort.

Hopefully, yes. I had the same problem as you mentioned in the thread you mentioned above . When PHD2 looses the guide star, it tries to reaquire it for a while. If this fails, it stops guiding with the message "Settling failed".

With this fix, the Guiding module recognises this situation and signals a "GUIDE_ABORTED" to the scheduler. Obtaining this signal, the Scheduler module tries 5x to restart guiding. The restart of the guiding is increasingly delayed by 5, 10, 15, ... secs. After five unsuccessful retries, the Scheduler gives up and marks the job as ABORTED.

If there are other scheduler jobs waiting, the Scheduler will start the next one in the queue. As Patrick rightfully stated in the thread mentioned above, it might be a better strategy to jump to another target to resolve the lost star issues - because of clouds, trees or whatever.

Currently, the Scheduler does not restart aborted jobs. As soon as all jobs are completed or aborted, the Scheduler shuts down. As a workaround, you could add the same job several times to the schedule, maybe with different starting times. That way you at least do not loose the entire night.

Hope that helps.
Wolfgang

Hi. That sounds like it solves our issue.
I'm currently using the stable repositories on Ubuntu 18.04. Is there any way I can add your diff to this version?
Cheers

You can either check out the sources from my kstars clone using the branch guiding_robustness . Or, if you are familiar with arc, you can apply an arc patch from phabricator diff D21739 .

In any case, you need to compile the sources until this diff makes it into a KStars release.

<strong></strong>It's a few years since I've done this. Looking at the documentation... How does this look?

**EDIT install the dependencies:
sudo apt install build-essential cmake git libeigen3-dev libcfitsio-dev zlib1g-dev libindi-dev extra-cmake-modules libkf5plotting-dev libqt5svg5-dev libkf5iconthemes-dev libkf5xmlgui-dev kio-dev kinit-dev libkf5newstuff-dev kdoctools-dev libkf5notifications-dev libqt5websockets5-dev qtdeclarative5-dev libkf5crash-dev gettext


mkdir ~/kde && cd ~/kde
git clone github.com/sterne-jaeger/kstars.git
mkdir build && cd build
cmake ../kstars -DCMAKE_INSTALL_PREFIX=/usr
make
sudo make install

Is there anything I need to do to indi? Does that need building before/after your kstars?

TIA

It's in KStars master now.

knro wrote: It's in KStars master now.

Ah, OK. But I still have to build it, right?

Is there anything I need to do to indi? Does that need building before/after your kstars?

Looks good, no, there is no need to do with INDI.

Since Jasem has already committed my diff, you could directly use the master branch from kstars GitHub . And yes, you need to build it.

Yes you can build it or wait for the nightly.