×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Guiding - Lost guide star causes abort of the ccd sequence

  • Posts: 17
  • Thank you received: 2
My guiding sometimes fails with no apparent reason.
I don't like the behavior that this aborts the ccd sequence. I think it would be a better guiding procedure to automatically try to restart the guiding a few times. For myself I have just to press the Guide-Button and the guiding works again because the star is with good polar alignment at the same position. But I lost the current exposure and have to manually restart the ccd sequence.
Last edit: 6 years 1 month ago by Niklas.
6 years 1 month ago #23362

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
If you are using PHD2 with Ekos, I implemented a "lost lock" timer because PHD2 sometimes loses track of the star and then reacquires it. So if it does lose the star, I give it 5 seconds to reacquire it before aborting. I know this is not exactly what you are looking for, but maybe it will help.
6 years 1 month ago #23366

Please Log in or Create an account to join the conversation.

  • Posts: 17
  • Thank you received: 2
Currently I use the internal guider. This sounds like my problem except that the internal guider doesnt reaquires the star although its still exactly in the star box. Maybe I have to use PHD2 as a workaround but I would prefer using the internal guiding.
Last edit: 6 years 1 month ago by Niklas.
6 years 1 month ago #23373

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
Indeed, when using external guider such as PHD2 and starting it from Ekos reaquires a lost star. I have tested it recently (see this threat ). I believe the behavior should be the same for internal guider. If it's not it would be good to change it.

BTW. Rob, could you give access to the 5 secs parameter to a user? or set it to a higher value? I believe 5 secs is too low - if you guide with 4 secs exposure time it will try to reaquire after loosing just one frame, which in many cases is not enough (e.g. passing clouds). In my case ZWO ASI 120MM, used as a guiding camera, sometimes scrambles the image, which renders 2-3 subsequent captures lost. I would then set the value to 15 secs and would be just fine.
Last edit: 6 years 1 month ago by Radek Kaczorek.
6 years 1 month ago #23376

Please Log in or Create an account to join the conversation.

I think internally it already tries for a few times before it gives up. Let me double check that.
6 years 1 month ago #23385

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
I have had a chance to test this issue recently. I think that lost lock timer mentioned by Rob could be the reason for aborting CCD sequence. 5 seconds is just too short for guiding timeout. A passing cloud would trigger this timer easily. Note that PHD2 handles lost star very well. It can give its alert sounds for many minutes and as soon as a star reappears it recovers instantly.
CCD sequence timeout is very useful feature. It should be general timeout though, not just guiding, but any device taking part in a imaging session. The parameter should definitely be accessible to a user. Still CCD sequencer needs to retry a configurable number of times before aborting. The retry procedure should include guiding restart procedure as well (BTW. this would address a "scrambled image" issue with ZWO cameras, which causes guiding stop - manual guiding restart fixes the issue).
Only while a configurable number of retries failed, session should be aborted. I would find it extremely useful if such a session abort procedure aborted also tracking or parked a mount.
The following user(s) said Thank You: Vincent Groenewold
6 years 1 month ago #23550

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Yeah we can build on the lost lock timer and/or make the variable accessible to the user. I think thats a good idea. But it is a very necessary feature because before i added it, the first time phd2 reported a lost lock, ekos would immediately abort the sequence. I figured we should give it a chance to reacquire first.
The following user(s) said Thank You: Radek Kaczorek
6 years 1 month ago #23569

Please Log in or Create an account to join the conversation.

  • Posts: 365
  • Thank you received: 32
Yep, this is the behaviour SGP has as well, it simply goes into recovery mode if one of the devices acts up and retries everything for say 30 minutes. It actually saved my sequence last night as that passing single cloud came along.
6 years 1 month ago #23572

Please Log in or Create an account to join the conversation.

Time to create page: 0.231 seconds