Help with PHD2 guiding in one direction.

[uma...@gmail.com]

I am currently setting up a new mount (AP Mach2). I created a new profile as per the instructions and recommendations. Ran some test over last two nights. Currently I have not done any sky model. 

Image train: C.9.25 ege -> optec leo focuser -> m68 extension ->ZWO OAG-L -> Bolted to ZWO EFW 2 -> bolted to ZWO ASI 2400mc

Guide Camera: zwo asi 174mm. Bin 2x. 

Night 1: 

• I started with base polar alignment using polemaster camera and Sharpcap (Correct for Atmospheric Refraction checked)
• Re-checked and adjusted polar alignment using Drift Align in PHD2
• Ran calibration and guide assistant
• Ran target session for the night
• PHD2 Log: https://openphdguiding.org/logs/dl/PHD2_logs_Nm7j.zip

Night 2: 

• I started with base polar alignment using polemaster camera and Sharpcap (Correct for Atmospheric Refraction checked) (Did not do drift align for this night)
• Ran calibration and guide assistant
• Ran target session for the night
• PHD2 Log: https://openphdguiding.org/logs/dl/PHD2_logs_AeXS.zip

Looking through the guide logs, for both nights, RA is guiding in one direction no matter what pier side the scope is on. Not able to get it centered. This is baffling me.

Night 1, dec tracking seemed pretty good. (With the exception of last 2 hours starting at 2:25am)

Night 2 (which was supposed to be better seeing than Night 1), DEC was a bit worse. The majority of the guides were in one direction. The direction did change when the meridan was flipped, but later at 1:43am it was on both direction and resutls for that hour looked really good. But the guides were again mostly in a single direction for the next two hours. 

Monty

[Bruce Waddington]

Hi Monty.  Having guide pulses all or mostly in the same direction isn't usually a problem per se and your overall guiding statistics are good.  This one-direction behavior is a symptom of drift and you have a fair amount of drift in RA.  Your RA drift rate generally runs in the range of 1 - 1.4 arc-sec/min which is about 4-5x larger than the Dec drift (it varies by scope position).  Drift like this can usually be handled pretty well by a detailed pointing model - are you using one?  It's hard to know where the RA drift is coming from but it's most likely coming from flexure in the payload that's on the mount.  In your case, I think this could include movement of the SCT primary mirror.  With the high-precision encoders on your mount, it's highly unlikely to be due to anything in the mount.

With this amount of drift, your guiding cadence is too slow to completely correct for it.  In steady-state guiding, you are only issuing corrections at 16-sec intervals.  The guide corrections are always "looking back" in time, so the target will typically have drifted another 0.4 arc-sec by the time the next exposure/guide cycle is started.  I think you would need to increase the guiding cadence in order to let PHD2 "stay on top" of the drift.  The most direct way to do this is to decrease the "long delay" parameter of the variable delay.  I would start by having guide commands issued every 10 seconds.  Of course, this assumes you want to fool with it at all, it's likely that your images don't suffer from any of this drift - as I said, your overall guiding stats are good and you shouldn't be getting elongated stars.

You have another operational error you need to correct.  Your guide camera is running in 16-bit mode but you have specified a star saturation value of 255 ("Saturation ADU") - that should be increased to something like 65000.  This interferes with the auto-find algorithm because PHD2 is judging your brightest stars to be saturated.

Good luck,

Bruce

[uma...@gmail.com]

Thanks, Bruce, for the detailed explanation. I am not currently running a pointing model. I wanted to get a baseline setup and fix any issues before creating one. My mirrors are locked on the SCT as I use optec leo focuser. (similar to moonlite).  I will correct the issue with star saturation value. Does 8bit or 16bit matter?

[bw_m...@earthlink.net]

16-bit operation is generally preferred unless there’s a specific reason to not use it, e.g. some problem with the driver.  I know the SCT has a feature to restrict mirror movement but in my experience, these things are never truly “locked” and of course the primary mirror assembly is fairly heavy.  I’m not saying it will be a big problem but it’s something you should keep in the back of your mind going forward.  In guiding, we’re usually operating at physical scales of a few microns so it doesn’t take much movement to affect what’s seen on the guide camera sensor.

 

Good luck,

Bruce

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/ZORkXLjy2AM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c846a5f3-8407-496c-bfb9-2c64cacb848fn%40googlegroups.com.