Slightly off-center before flip - dead center after flip

Hi folks.
Last night, I ran a completely unattended session. Connected equipment, set sequence to start at a later time in the evening (when I wasn’t home) and kicked it off. Everything seemed to go ok - it unparked the mount and proceeded with slew, center, autofocus etc. at the appropriate time.

However, when I checked today, most of the subs are slightly off center. But there was a meridian flip which happened toward the end of the session - which was successful - and after the flip the target was dead center in FoV.

So presumably the pre-flip target coordinates were correct, but somehow the scope got “disrupted” near the beginning, after centering. Could this be from mount backlash at beginning of guiding? Where else could I look for root cause?

Before flip:

After flip

Running 2.6.0.24 Mount is EQ8 with EQMOD and PHD2 2.6.3dev7.

I realize this is probably not enough info to go on. If logs or other info would help, let me know.

DaveNL

@dnube

Is every pre-flip frame off center or does the target go off center over time? Sometimes, if your mount has the ability to craft its own model, it can influence positional information on one side of the mount…

Are your EQMOD settings in line with the recommended setting for use with SGPro?

I had some weird stuff happen to me with eqmod and plate solving too. What I did to fix it was to not use a pointing model and set syncing to dialog based in eqmod(forget the exact wording). Just get a polar alignment and let SGP and plate solving do the work. Try that and see if it helps.

@Ken
The very first image was off-center. All the following images (until flip) maintained that off-center placement. My suspicion is that the initial centering process worked but when the autoguider started up it had trouble with backlash resulting in target drifting off-center. But I welcome suggestions for other possible sources of the problem.

If this is a PHD2 and backlash problem, how would I address (besides trading up to a new mount:grinning:)? I’ve got backlash compensation turned on in PHD2.

@djnetboy
I do have a small point model in EQMOD - I found that the slews were too far off otherwise and therefore PS2 would not solve (and Astrometry.net would even struggle). I believe my other EQMOD/SGP settings are per recommendations (ie. Dialogue based so no additional points added to model, etc.). In fact a search of this forum will find details of my SGP and EQMOD journey, with details of settings used.

DaveNL

Hmmm … I should have looked at this more carefully earlier … my notification messages seem to indicate that the autoguider was having trouble with guide star around the time SGP finished the centering process. Perhaps there were some intermittent clouds. Here’s an excerpt:

10:30 (July_24_2017_Cocoon Nebula) Slewing to target “Cocoon Nebula”…
10:30 (July_24_2017_Cocoon Nebula) Centering on target “Cocoon Nebula”…
10:32 (July_24_2017_Cocoon Nebula) Attempting to resume the auto guider (post slew / center)…
10:32 (July_24_2017_Cocoon Nebula) Successfully centered on target “Cocoon Nebula”…
10:35 (July_24_2017_Cocoon Nebula) Guide star lost!
10:36 (July_24_2017_Cocoon Nebula) Guide star lost!
10:42 (July_24_2017_Cocoon Nebula) Something has gone wrong while attempting to resume auto guiding
10:44 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:44 (July_24_2017_Cocoon Nebula) Auto guider has resumed (post slew / center)…
10:44 (July_24_2017_Cocoon Nebula) Sequence recovery was successful (Guiding)!
10:44 (July_24_2017_Cocoon Nebula) Waiting on camera temperature to start sequence (cooling to -10C)…
10:44 (July_24_2017_Cocoon Nebula) Running auto focus…
10:44 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:44 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:45 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:45 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:45 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:46 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:46 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:46 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:47 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:47 (July_24_2017_Cocoon Nebula) Attempting to settle the auto guider…
10:48(July_24_2017_Cocoon Nebula) Starting integration of Cocoon Nebula; Event 2; Frame 11 for 300s…
10:53 (July_24_2017_Cocoon Nebula) Image “Cocoon Nebula_300sec_2x2_G_Baader_amb_13.3C_-10C_224842.fit” saved.

Sucks that this resulted in me having to discard most of the nights images. However not sure if there is anything that could be done to prevent such a situation?

DaveNL

@dnube

It seems like it would be best if, in this situation, SGPro’s recovery logic also re-ran the centering routine. Easy enough change.

@Ken
Sounds good. I guess this would be initiated when a more serious guiding error (triggering Sequence recovery) has happened, not just a transitory “guide star lost” error?

What about when a PHD does a “Frame restart: distance was XXX pixels” (where XXX is a particularly large #) - would this be an indication of need to re-center?

DaveNL

Yes, currently guide star lost is the only type of recovery that attempted to save time by skipping the re-centering.

No. This event typically means that there was some gust of wind that ruined the frame, not usually that you are way off center.