Ending up off target after cloud passing thorugh

Is there any way at all around the following… it is driving me mad and has so far cost me many hours of data …

Imagine the scenario… all is clear and everything is working, a sequence is running and guiding is working fine. A cloud passes through and PHD loses it’s guide star for say 10 mins. This isn’t enough to activate recovery mode. After the cloud has passed, the target has now moved a lot in the frame (at 1700mm it will) and PHD picks up a guide star, any guide star … and continues.

Now I have the scenario where, because of a passing cloud (and that recovery isn’t activated until 15m after losing a guide star) the target is half way down the frame and so the sequence continues until the time limit set capturing a load of useless frames.

As the target hasn’t changed there’s no reason to plate solve and so on filter changes the target being in the wrong place continues.

I hope that there’s some setting I’ve missed that can help?

Oh, I understand know why I have some frames moved, displaced in relation to the correct position. I have not mesured it but it’s approx. 10min.
I thought it was a bad plate solve… But it’s what you say. A cloud and PhD.

I know my issue is passing clouds as I can time the frames with the capture time ony AllSky camera…

If I could plate solve every x number of frames, this could negate the considerable data loss considerably.

One solution should be as in CCD Commander I used to do to focus:
You send the scope to a near star each n frames.
In this way you force SGP to do a plate solve when you want.
The problems is that you need to add the main object with a new different name.

I can see how that may work, but if I wanted to ensure that I got a full nights run, I would have to have a massive target list for a move at least hourly…

I am not aware of a setting in SGP to trigger recovery sooner or to re-center in this scenario (that doesn’t mean it’s not there but I don’t know about it).

Two things come to mind. First you could try increasing the size of the PHD search box. If the original star is still in that search box after 10min I think it should move the star back to the original crosshair.

Second, I know you’re imaging at a modest focal length but still, 10min shouldn’t be long enough to move the target that far off. Are you sure your polar alignment is good? If the target is moving halfway down the frame then I’m surprised that PHD is even able to keep up guiding under normal conditions.

Hi Joel,

I will look at increasing the size of the PHD box, but it is already about 80px wide as I recall. My polar alignment is good, I use a Polemaster and also when checking in PHD guiding assistant it is in the arc seconds.

My PHD guiding is very good under normal circumstances, so I know that PHD isn’t fighting to keep the guiding going.

Well if your PHD box is already 80px wide that’s really big and I don’t
think increasing it will help. It just puzzles me that there is that much
movement over just 10min. What mount? I just wonder if there’s something
else that is causing the mount to jerk around when the guide star gets lost.

The mount is a Mesu 200 and having sat here and watched what happens so that I can accurately report it, there’s no jerking around by the mount when it loses a guide star … it just serenely waits until it finds another guide star!

If your polar alignment is good, then the guide star should not drift significantly in 10 minutes. What is your measured polar alignment error?

The most likely way for phd2 to pull you off target when clouds move in is for it to lock on to a hot pixel when the clouds are present. Are you using darks or a bad-pixel map in PHD2? A good bad-pixel map can effectively eliminate this problem. Your large PHD2 search region (80 pixels) may be exacerbating the problem by increasing the chance of locking on to a hot pixel.

If you post your PHD2 debug log and guide log from the session we may be able to say more.

Andy

Dumb question…are you sure your mount is tracking properly when PHD loses the guide star?

I’ll be sure to post the logs up when I fire up the Obs PC in a bit.

@joelshort - Not a dumb question at all, as I don’t know how to answer that!!! Is there a tick box I can check?

The tracking would have nothing to do with SGP but with your mount. Your mount should be tracking all the time regardless of guiding, but if for some reason it’s not that would open up a world of trouble. I suspect that Andy is right here and it has to do with false positive guide “stars”. But make sure that your mount is tracking properly.

Just checked his out Joel and the tracking on the Mesu is indeed enabled…

swag72:

The Mesu 200 should be keeping the guide star within a few pixels during a 10 minute period even with no guiding active. If it is not doing that, then there are only a few things to check: Is the mount set to Sidereal Rate, as opposed to lunar, solar, custom, etc? Poor polar alignment. You said your polar alignment is within a few arc seconds. With all due respect, that seems unlikely to me. Even getting polar alignment to one arc minute is a challenge. Finally, periodic error correction. If PEC is not enabled, it is possible that periodic error might move the star that far off in 10 minutes.

As reference data – my AP1100GTO is permanently mounted; its polar alignment is about 1.5 arc minutes (according to PHD2); I am imaging at 2500mm. I have PHD2 paused during auto focusing. The auto focusing routine runs about 3 minutes. During that 3 minutes, the guide star (OAG) drifts about 4 arc seconds. PHD2 easily pulls the guide star back to center when the auto focus routine is done.

Charlie

Hi Charlie, Thanks for your thoughts on this… the mount is indeed set to sidereal. I was hoping to see how it all went last night, but I think I may have suffered with a power cut as things were certainly odd this morning.