Settling with PHD2

#1

I recently discovered that my guiding improved significantly when I lowered my max RA/Dec values to 200. The problem is, it takes quite a while for PHD2 to settle and it’s failing between frames. Any ideas on what I can do to fix this? Do I just need to turn off dithering? Turn down the level of dithering?

SGP Log file:

PHD2 Log File:

From what I can tell, it flagged that I wanted to ‘slew’ both times it failed and didn’t clear that flag, which caused PHD2 to stop? Maybe it wasn’t settling… When I closed PHD2, it had that message that ‘the mount is slewing, PHD is paused…’. However, the mount wasn’t slewing…

Thanks,
Chris

#2

My first thought would be to reduce the level of dithering. Where is it currently set?

I’m not sure why setting your max slew value to 200 would affect dithering since the dither only moves it teeny tiny bit. That max slew rate seems pretty low. It must take forever to slew anywhere. This is with a Gemini right?

#3

Joel,

I was having trouble with guiding in my 20 minute exposures. So, I started setting the rate lower and lower. I had always used around 1000ms. When I got below 400ms it improved a lot, and 200ms was even better. I know it sounds crazy :).

Of note, I also turned off noise reduction and that made a HUGE difference too. I thought when it recentered, it didn’t use the max values but instead went to the calibration value?

The hanging chad at this point, if you go through the log files (go to 2349 or so), is the ‘mount is slewing, PHD2 paused’ not working I think.

#4

Sorry Chris, I misunderstood your first post. I thought you meant you set the MOUNT max slew rate at 200, but now I realize that you meant the PHD2 max RA/DEC slew rate. If that is the case, then setting the max rate lower would definitely take much longer for PHD to settle and in fact could lead to a fail. I’ve had that happen in the past. If my max slew rate is set too low I even get errors in calibrating because the backlash compensation takes so long that it times out. I hope that makes sense.

I am glad you brought this up because I too have been having a hard time with guiding parameters, because of a new much heavier scope. I’m pushing my G11 mount capacity and I’m not happy yet with the guiding results so I’ve been playing around with the guiding parameters. I’m going to try reducing the max rate and see if that helps with my guiding.

#5

There’s some risk for lowering Max Duration especially in Dec axis. If you have a high end mount that has very little to no backlash in Dec axis, then it may be fine. But mounts with good enough backlash, when the guide command says to reverse direction of Dec axis and Max Dec Duration is low, then it may take several repeated guide commands to finally get the Dec axis moving and it could take a while for guide star to finally move back to original position. I am not sure why there’s Max Duration for RA axis since the motor will always move in same direction. If the guide command says to reverse RA axis, the RA motor reduces speed (less than tracking speed, probably 1/2 of tracking speed) instead of reverses motor direction which is why I don’t think it’s worth having Max Duration for RA axis. I would leave Max Duration in RA axis at a default of 1000msec.

I would check your Dec axis backlash and re-mesh if necessary to reduce backlash. Don’t make it too tight. It might be a good idea to re-mesh every season when temperature changes.

Are you having Dithering issue? Does it take a long time to settle? If so, try increase dithering settling (Settle at < X.X pixels).

Peter

#6

Setting max RA/Dec pulse duration is probably not the best solution. The PHD2 guide log would be more useful for diagnosing this than the debug log. Could you post a link to the guide log? (It’s PHD2_GuideLog_[date]-[time].txt)

A dither just moves the lock position, then guiding proceeds as usual and all guide parameters continue to be honored. So if the max ra/dec pulse value is set low, it will take a long time to recover after the dither.

Do you have Gemini1 or Gemini2? The ‘mount slewing’ problem is a symptom of a bug in the Gemini ASCOM driver that was fixed in version 1.0.54.0, so you need to upgrade your ascom driver to 1.0.54.0.

I believe there is a problem with the latest ascom driver for Gemini1 systems, so upgrading is not an option for Gemini1. In that case, there is an option in phd2 (Mount tab in the brain) “Stop guiding when mount slews”… you can un-check that option to workaround the problem without upgrading your ascom driver.

Andy

#7

Actually, I take that back. After a dither we do one or more large pulses to quickly move the star back (assuming you have the option “Fast recovery after dither” checked in the brain.) The size of the pulse is determined by the size of the search region (the green box) and calibration rates, and the pulse is made as large as possible without causing the star to be lost. The large pulse is unrelated to the calibration pulse size and does not conform to the max Ra/Dec pulse parameter.

After the large recovery pulse(s), normal guiding resumes. If you have substantial backlash, then after the recovery pulses the star could still be quite a way away from the lock position and a low max ra/dec pulse value will cause it to take a long time to recover after the dither.

Andy

#8

I’ve always had that option checked. And I don’t believe I’ve seen this issue pop up with my G1 running 1.0.18.0. My G1 doesn’t appear to report “IsSlewing” when pulse guiding. I’m not sure about the ST-4 port guiding though.

I still have it on my “Todo” list to fix the side of pier in 1.0.54.0 for us lowly G1 users.

Thanks,
Jared

#9

This is about the 4th time in a row this happened. I have the correct driver (wasn’t a problem before either). PHD2 throws a flag on the screen about ASCOMPulseGuide detects mount slewing. Of note, I managed to take 2 images last night. The first one I had a medium dither set and that seemed to work.

There is something wrong, I’ll post the logs:

#10

Do you happen to have an ASCOM driver log from the session where you had the problem? It would be helpful to get a log with the log level set to 5 or 6 (Gemini Telescope => Setup => Configure Telescope => Logging/Diagnostic Options).

Andy

#11

Yes, I do.

Realize it’s 140mb.

So, last night I got it fixed by using the ‘standard’ lodestar driver that is included with PHD2. Before I had been using the ASCOM driver because it allowed me to bin.

Any ideas why that matters?

#12

So that ASCOM log shows that Gemini2 reported that it was slewing at Center rate at 22:34:17.065. Any chance the hand controller button was pressed?

Just curious, what Gemini2 firmware version are you running?

The “Guiding stopped: the scope started slewing” problem is strictly related to PHD2 and Gemini2. The choice of ASCOM vs built-in Lodestar driver really has no bearing. (“Correlation does not imply causation”)

Did you happen to notice my comment earlier in this thread about the option in phd2 to disable the slewing check (Mount tab in the brain: “Stop guiding when mount slews”)?

Andy

#13

Andy,

Firmware is up to date: Main unit is 23 Feb 2014 and HC version is 20 Feb 2014. I do not leave my HC plugged in when I’m imaging remotely.

Glad it just happened to work last night :). I was just adding info on what I changed and that it had worked. I needed a victory and was sick of wasting clear skies!

So, I missed that comment about the checkbox. Should I disable that?

#14

Very strange. I’m using the same ASCOM driver version, the same Gem2 firmware version, SGP and PHD2 and I have never seen the issue since upgrading the ASCOM driver to 1.0.54.0.

At this point I think we need to forward the ASCOM log to Paul K (post on the Gem2 ASCOM driver yahoo group) and point to the event at 22:34:17.065 showing that the ASCOM driver reports the mount slewing at Center speed, despite no slew commands having being sent, and the hand controller being unplugged. He should be able to say whether it is an ASCOM driver problem or a Gem2 firmware problem.

Yes, un-checking the option will absolutely make the problem go away by disabling the slewing check altogether.

Andy

#15

Ok, Thanks! Done.

#16

Well, I can tell you the removal of that check box doesn’t fix the problem. It failed again. Luckily I was awake and caught it.

I can’t tell you why it’s failing, but it’s after it performs the ‘center here’. It just can’t seem to acquire the guide star again and it fails out. Every time.

The annoying part is the star box is on target… guiding and then it says ‘star lost’ and fails out. I h even manually select the star in PHD2 to get it going. It will stop the device each time.

What changed between PHD2 and SGP?

#17

Hi Chris,

Are you saying you got the “Guiding stopped: the scope started slewing” message when the check-box was un-checked!?

“Star lost” and failure to start the guider sounds like something different. Could you post a link to the PHD2 log and indicate the time of the incident?

Andy

#18

No, I had the box unchecked and it didn’t give me an error. It just had the same behavior.

Wilco! Time was around 930pm as it was starting for the night.

#19

still need a link to the log though

#20

So, it was 28 July, 2130 or so. It’s now a 550mb file…

www.mainsequencesoftware.com