Problem to guide STL11k with internal sensor

Hi,

I usually guide my STL11k with internal sensor and SGP API guider.
Very often after the image download, PHD restarts guide, performs dithering and then I got a recovery message from SGP. During the recovery time PHD continues to guide without any problem.
After about one minute or a bit more SGP closes the recovery window and restarts with a new exposure. Without recovery, SGP will end the sequence.

I had this problem with both my setup (G11+FSQ) and (AP1200+ODK) always using STL 11K and internal guide sensor. All is fine if I guide with parallel scope and QHY5L camera.

SGP and API guider are updated, PHD is 2.5.0.

Here are the logs:
https://dl.dropboxusercontent.com/u/38866039/sg_logfile_20150829202010.txt
https://dl.dropboxusercontent.com/u/38866039/PHD2_GuideLog_2015-08-29_204550.txt

For example please have look at about 21:11 or 21:29 or 21:39.

Any thoughts?
Thanks.

In each of the instances you mention, PHD2 has reported that the guide star is lost. Unfortunately, that is the wrong PHD2 log (need the debug log, not the guide log) so we can’t really see what happened on that side.

[29/08/2015 21:10:56] [DEBUG] [Sequence Thread] Recovering the sequence (and the auto guider lost the guide star)

This happens when PHD2 sends a star lost message with a distance greater than 50 pixels.

for sure the guide star is not moving 50px. Here is the PHD debug log:

https://dl.dropboxusercontent.com/u/38866039/PHD2_DebugLog_2015-08-29_204550.txt

There was a guide star lost message sent by PHD2 here:

21:10:42.050 00.016 9724 UpdateGuideState exits: Star lost - mass changed

Which could correlate with the SGPro message since the recovery mode is not immediate. We’d need to ask @Andy to determine what distance was sent with that message. I still don’t know how to do this…

Looking at the log the problem comes from here:

21:10:09.435 00.000 6752 Handling exposure in thread, d=1500 o=3 r=(238,369,31,31)
…
21:10:41.856 01.873 6752 Exposure complete

PHD2 issues a 1.5 sec exposure to the camera driver, and it takes over 32 seconds for the exposure to complete. After the exposure completes, the frame is dropped due the the 35% star mass change threshold setting.

Within phd2 there is a 20-second threshold for reporting the distance. If the star is lost for less than 20 seconds, phd2 will return the last known distance. After 20 seconds of the star being lost, phd2 will report a large distance indicating the star is really lost.

In this case because the camera driver did not return the frame for over 30 seconds, phd2 saw the star as being lost for more than 20 seconds and flagged the star lost condition to SGP.

I’m not sure what we can do to make this better. If the star was really lost for 20 seconds or more, the sub is likely ruined and recovery mode is appropriate.

You probably should disable star mass change detection in phd2 to make the problem a little less likely. Even without star mass change detection you can still get dropped frames, and if the camera driver is going to take a very long time to get a guide frame, you still may trigger recovery mode when phd2 can’t find the guide star in the frame right after the driver delay.

Andy

Unfortunately when using the internal guider frames taking over 30 seconds will be quite common. This is because it shares the same shutter with the main imager and we can’t (or don’t want to) open the shutter when an image is downloading from the camera (which takes over 30 seconds). So we sit there waiting until we can open the shutter and take an image.

This is why I don’t guide with the internal guide chip on my STL-11000 (plus it’s behind the filter and I primarily shoot narrowband)

We could cache the last image and return that if we’re in a state where we can’t take an image. Not sure what issues that could cause though.

Jared

Perhaps SGP could tell PHD2 to restart guiding after the image download completes? In other words, call the “stop_guiding” server method before the download, then call “guide” to resume guiding after the download? I guess this this would be similar to the old “pause guiding during image download” option. I don’t remember the history of that.
Andy

to pause the guiding during the image download seems a good solution for me, or not?

The “Pause Guiding during download” didn’t work as intended with most (ASCOM) cameras, so we removed it.

We’ll have some discussions about how to best handle this. Adding a pause back in would likely be the most invasive. Returning the same image over would be a good deal easier and possibly not have any ill effects.

Thanks,
Jared

Hello Gianni,
I am evaluating SGP as my new software for image capturing. I am in the trial phase, but have not had the opportunity to test it under the stars. I have a STL11k too and wants to use the internal guidechip as I can with the old CCDSoft. My download time is usually 25sec, then add 3s for guide star capturing and 2s for download.
I wonder if this can work if I read the postings in this thread.

My question: should I give up my plan to use SGP, or does it work with the internal guider chip?

Thomas

Thomas, you should give it a try and see how it works for you. The issue that Gianni reported is that when the guide star is lost during the ~30 second download, SGP goes into recovery mode. In Gianni’s case the loss of the guide star was caused by an aggressive star mass change setting in PHD2, plus apparent intermittent clouds. The SGP API guider not being able to download guide frames when downloading makes it more likely for SGP to go into recovery mode when PHD2 loses the guide star during the download. Jared and Ken and I have been discussing this and hope to come up with some improvement to PHD2, the SGP API guider, and/or SGP to make it as resilient as other guide configurations. In stable guiding conditions I would guess you would not see the issue that Gianni reported.
Andy

Hi Andy and Thomas,

I can confirm that overall STL11k works very well with SGP/PHD even if the download from the guiding sensor is a bit slow (exposure time + additional 2-3 sec).
The only issue is what I reported in this thread and affecting about 30-40% of the total number of exposures.

In my case the problem is very sistematic and not related to intermittent cloud.
If I disabe the star mass change detection, the situation is even worse because the frame acquired during the download is nearly only noise and PHD will move the guiding star out the green box (I might have the log on my PC for this case).
Using 50% of mass change didn’t mitigate the situation (I tested this case too) and the issue is independent from mount/telescope setup.

Please Thomas if you have the opportunity test your STL11K with the internal guiding sensor, and ket us know your experience.

Andy, Jared and Ken thanks, I appreciate very much your help and effort.
Gianni.

Thanks for clearing that up, I understand a bit better now. Hopefully we can come up with a solution.

Andy

Jared and I have discussed this and decided (sometime during the life of 2.4) that we will re-introduce the notion of pause guider during main camera download. Unfortunately, this feature will be disabled for all ASCOM and QSI users, but we do actually have more control over SBIG cameras (non-ASCOM). So… you will be able to pause the guider during download and PHD2 will not send this message… Can’t be any more specific about release except to say that it will be prior to beginning work on 2.5.

1 Like

This has been implemented and will be released with the first 2.4.3 beta (this weekend maybe?)

Great! I will try it asap and get back to you.