PHD2 unable to resume guiding after slew

179 views
Skip to first unread message

kevi...@gmail.com

unread,
Apr 12, 2015, 2:12:38 PM4/12/15
to open-phd...@googlegroups.com
Can anyone figure out what went wrong here?  Guiding went well on the first target, and SGP successfully slewed to a second target, but PHD2 was unable to resume and I'm not sure why.  PHD2.4.1f (will update tonight), ASI120MM with an off-axis guider on a C11 at 1560mm focal length.  The PHD2 debug log, the SGP log, and a screen cap of the PHD2 screen are here:

https://dl.dropboxusercontent.com/u/58468743/PHD2%20PostSlew%20Failure.zip

The slew was about 00:30:58.  Looking through the logs, it looks like PHD2 found a star where I expected it (see the screen cap - if it's the star I pre-targeted, that's a 7.7 mag star), and started guiding around 00:31:05.305.  Guiding seems to go okay until 00:33:06.405, when when the log notes star lost because of a mass change (135.1 vs. 75.5).  So at 00:33:07 the SGP log notes "guide star lost."  Nevertheless, PHD2 seems to continue guiding for the next three minutes, until at 00:36:04 the SGP log notes that PHD2 failed to settle.  A minute later, at 00:37:05.804, the PHD2 log shows "ZWO: stopcapture."  And at 00:37:05 the SGP sequence aborts.

Any idea what went wrong?  I was using the ZWO connection, unbinned, so even at 50 pixels the search box was pretty small.  But the focus run hadn't started yet, so I'm not sure what, if anything, would have pushed the star out of the box.

Kevin

Andy Galasso

unread,
Apr 12, 2015, 2:34:46 PM4/12/15
to Kevin Quin, OpenPHD Guiding
Kevin,

Could you also include the PHD2 Guide Log?

Thanks,
Andy

kevi...@gmail.com

unread,
Apr 12, 2015, 9:28:17 PM4/12/15
to open-phd...@googlegroups.com, kevi...@gmail.com

Andy Galasso

unread,
Apr 13, 2015, 2:31:47 AM4/13/15
to Kevin Quin, OpenPHD Guiding
Hi Kevin,


It looks like phd2 may have locked on to a hot pixel since it is continuously sending max corrections on both RA and Dec and the guide star is staying at a fixed offset from the lock position.

Is it possible that there is a new hot pixel that is showing up recently since you created your pad-pixel map? (perhaps because of warmer ambient temperature?)

Although not directly related to your problem, you probably need to improve your calibration.



You probably want a smaller calibration step size so you get 10-15 calibration steps, rather than the 3-4 you are getting.You can move the mount North a little bit to take out the Dec backlash before starting the calibration.

Andy

kevi...@gmail.com

unread,
Apr 13, 2015, 1:16:11 PM4/13/15
to open-phd...@googlegroups.com, kevi...@gmail.com
Thanks, Andy.  As always, very helpful.  I'll update my BPMs. 

I'm not familiar with the first graph you've posted above.  Could you tell me what generated that, and how you interpreted it to lead to the hot pixel idea?  I'm always looking to get better at diagnosing my own problems.

BTW, I would love to get more calibration steps, but dec axis stiction limits this: the dec axis just won't move if I use smaller step sizes.  When I was using my ASI120 binned, I was getting 6-8 steps per axis rather than 3-4, but based on our earlier discussions I'm trying to use it unbinned.  With the search box now only 1/4 the previous size, calibration steps are now 1/2 what they were.  Everything is a compromise!
  
Kevin

kevi...@gmail.com

unread,
Apr 13, 2015, 1:25:50 PM4/13/15
to open-phd...@googlegroups.com, kevi...@gmail.com
One other question:  if it was a hot pixel, why did PHD2 pick that over the star?  Does the findstar algorithm give more weight to a sharply defined source than a spread-out one?  Also, does the log keep some record of how PHD2 evaluated each potential guide star when it ran the findstar routine?

Kevin

Andy Galasso

unread,
Apr 13, 2015, 2:16:29 PM4/13/15
to Kevin Quin, OpenPHD Guiding
Hi Kevin,

The graphs were made with PHD2 Log Viewer.

It looked like a hot pixel problem to me because we see a continuous series of max-duration corrections on both RA and Dec and the guide star staying at a fixed offset from the lock position - RA (blue) and dec (red) star offset is not changing despite the guide pulses being sent. The up and down wiggles are probably due to camera noise, with the hot pixel being fairly dim.

The star selection function in PHD2 is usually pretty good at selecting stars over hot pixels. There is a convolution function that usually all but eliminates the hot pixels from consideration.  However, if there are no stars in the field then a hot pixel is the most likely thing to be chosen.  If it ever happens again, you can do File => Save image to get if raw FITS image from the camera so we can analyze the image to make sure phd2 was not incorrectly choosing a hot pixel over a guide star.

The debug log does record lots of information about the Auto-find.  In the instance around 00:31 there were apparently only two good candidates, SNR 61.1 and 87.7, but those were rejected because they were too close together (about 8.6 pixels):

00:31:05.783 00.001 7152 AutoFind: too close [362, 284] 61.1 - [355, 289] 87.7

Your large search region setting (50) makes it more likely for phd2 to reject stars as being too close, but those stars would have been too close even with the default search region (15). The threshold for "too close" is (search region + 5 pixels).

Based on your focal length in the log, I'm assuming you are using OAG. This is the big down-side of OAG. If your target is in a sparse area of the sky (galaxy season), you may need to make sure that there is a good star to guide on rather than trusting that one will be found automatically. You may need to specifically frame your target to get a guide star in the guider FOV, or else rotate your OAG to find a star.

Andy

kevi...@gmail.com

unread,
Apr 13, 2015, 9:57:59 PM4/13/15
to open-phd...@googlegroups.com, kevi...@gmail.com
Thanks for all the info, Andy.  I'll try to experiment with the log viewer. 

So I just tested this again, and I'm not sure why PHD2 didn't pick the obvious star in the field.  Here's what I did:  I took new darks (15secs x 25 exposures) for the BPM first.  The scope slewed to the target, My pre-selected guide star was near the center of the FOV, but PHD2 picked a non-star very close to one edge.  The logs, with two FITS frames, are here:

https://dl.dropboxusercontent.com/u/58468743/PHD2%20Find%20Star.zip

When I manually select the guide star, PHD2 shows an SNR averaging around 18.  That should be plenty, shouldn't it?

I definitely hear you about OAGs and long focal length during galaxy season.  I pre-target my guide stars, though, so it's not usually a problem. I can easily guide down to mag 11.5 with this setup. 

Kevin

Andy Galasso

unread,
Apr 13, 2015, 11:01:11 PM4/13/15
to Kevin Quin, OpenPHD Guiding
While I would agree that star is obviously present after a big gamma stretch, I can see why the star finder passed on it.  It is very wide -- FWHM > 10 pixels (>5 arc-sec fwhm with your 05."/px scale), and the peak intensity is only about 9.5 ADU relative to the background noise of 3.2 ADU/pixel.  (using a Gaussian fit and statistics from PixInsight).

Is it possible that the guider could be a bit out of focus? If you could sharpen the focus it would help I think.

Assuming focus is as good as you can get it, then this looks like a case where binning could help (star is highly over-sampled). Unfortunately there is no way to do that in PHD2 at present, though we have an open request for that in the issue tracker.

Andy

kevi...@gmail.com

unread,
Apr 14, 2015, 10:02:12 AM4/14/15
to open-phd...@googlegroups.com, kevi...@gmail.com
I'll check the focus.  20C temperature rise since I last imaged, so I can imagine how the OAG may have gotten out of calibration.

Until starting to experiment with the ZWO connection mode a few weeks ago, I always guided binned (using the WDM connection), in part because I figured I could guide on dimmer stars.  In the few minutes before clouds rolled in last night,  I tried switching back to the WDM connection, but I noticed that the status line (or whatever we call the bottom of the PHD2 screen) kept reporting "0 frames," which I've seen a few times before.  Is that an error message?  The images looked almost pure black to me, and the guide star was not visible.

If I was a programmer, I'd be happy to write the binned mode for the camera.  :)

Kevin

Andy Galasso

unread,
Apr 14, 2015, 11:53:26 AM4/14/15
to Kevin Quin, OpenPHD Guiding
On Tue, Apr 14, 2015 at 10:02 AM, <kevi...@gmail.com> wrote:
I tried switching back to the WDM connection, but I noticed that the status line (or whatever we call the bottom of the PHD2 screen) kept reporting "0 frames," which I've seen a few times before.  Is that an error message?  The images looked almost pure black to me, and the guide star was not visible.

Yes, that indicates the camera returned 0 frames. PHD2 stacks the camera frames through the duration, and in this case no frames were returned in that time.  You may need to reset the camera (unplug/plug) if that happens.

Andy
Reply all
Reply to author
Forward
0 new messages