PHD2 Guiding Question

[Starwiz]

Here's my problem.....

I've left the rig out imaging all night.  Sometime during the night, a cloud passes over which causes PHD2 to lose the star. 

As a result, it starts slewing the mount.

After the cloud has passed over, PHD2 locks onto another star and the imaging continues.  But now the scope is not pointing at my target, so a few hours of imaging are lost.

So, my question is.......

Is there a way to stop PHD2 from slewing the mount when the guide star is lost?

Thanks

John

[Realtimedoctor]

Hi, 

You'll need to give a little bit more information. 

What mount, and eh hat software are you using for acquisition. Phd2 doesn't slew the mount on losing a star, so something else has gone wrong somewhere. 

[teoria_del_big_bang]

From my short experience with PHD2 That is odd.

When I have used PHD2 with both APT/ASCOM and KStars /INDI acquisition software when this occurs PHD just stops delivering guide correction pulses to the mount, but the tracking is still enabled so the mount continues to track the object but without any corrections from PHD2. So I still continue to photograph the target (albeit now covered with cloud) but maybe not as accurately as with PHD2 working so the target may drift over time (but over hours it does not slew to a different position). So when this happens (as it does with everyone at sometime)  then if the cloud clears I will still be more or less on the target and will continue to take images of that target. It is just the target may have moved very sightly.

I have never seen PHD select another star when the cloud clears but depending on the acquisition software I am sure some can be setu to do so and in that case it would pick a guidestar and then continue to guide properly but the target will just have moved a very small amount from when it was guding before the cloud cover.

So it almost sounds like your tracking is the issue rather than PHD2 as you should be able to track a target well enough to take hours of images without losing the target altogether, it may slowly drift so the last image is in a different place on the image compared to the first but should still be there.

So As @Realtimedoctor suggests say what your whole setup consists of , what  acquisition software, are you using PHD2 with ASCOM or INDI or ST-4 etc ?

Steve

[Starwiz]

32 minutes ago, Realtimedoctor said:

Hi, 

You'll need to give a little bit more information. 

What mount, and eh hat software are you using for acquisition. Phd2 doesn't slew the mount on losing a star, so something else has gone wrong somewhere. 

NEQ6

APT

Using ASCOM & EQMOD for controlling the mount.

Thanks

John

[Starflyer]

If your polar alignment isn't great then a target could drift partially or all the way out of the fov during a period of cloud cover.

If you feed your PHD2 log into the log viewer app (separate download)  then it'll give you an estimate of your PA error.  If your PA is good then the tracking should easily keep your target roughly centered throughout a brief period of cloud cover.

[Realtimedoctor]

13 minutes ago, Starwiz said:

NEQ6

APT

Using ASCOM & EQMOD for controlling the mount.

Thanks

John

When you say your mount "slew", do you mean that the mount was pointing in a completely different direction than when you went off to sleep? 

What were you shooting, and what time did it cross the meridian? 

I don't remember much about APT, as I mainly use INDI now - but from my initial days APT and phd2 play well, as @teoria_del_big_bang@teoria_del_big_bang pointed out, your mount should be able to track the object even without any guiding corrections, albeit your notice a drift in the image over longer exposures depending on your polar alignment, and how well your mount tracks.

My current hypothesis of what happened is as follows 

You leave the setup - clouds come -> phd2 loses guiding, still APT continues capturing (as it should) -> your target slowly drifts out of FOV due to polar alignment/tracking errors -> clouds clear, PhD still runny and looking for a star -> locks to a new star, and resume guiding - > now your scope is pointing to a slightly different area of the sky, and not your target 

A wild thought is sometime during the night/imaging session is APT does a meridian flip -> you wake up to the mount pointing in a different direction, assuming it has "slew" to a new target. 

[Realtimedoctor]

Also sorry,

I should answer your initial question as well. Phd2 doesn't slew the mount, it only guides - these pulses are to short to make any meaningful movements in the mount that you can notice with naked eyes. 

So you don't need to do anything with your phd2 setting. Hopefully your next night will be clearer. 

Cheers 

Edited August 8, 2020 by Realtimedoctor

[teoria_del_big_bang]

10 minutes ago, Realtimedoctor said:

A wild thought is sometime during the night/imaging session is APT does a meridian flip -> you wake up to the mount pointing in a different direction, assuming it has "slew" to a new target. 

That is actually a very good thought.

I too no longer use APT and thought if PHD2 lost the star it did not re-select a star when the clouds cleared , but it may well do especially if you have automatic star selection enabled in PHD2, in my case the cloud was usually still there in the morning anyway, the joys of living in the pennines 🙂 

But after a flip without  a successful platesolve then the mount could be a long way off target even if polar alignment was reasonable and tracking was working. Also it would definitely re-enabe PHD2 and select a new star whatever the settings (I think from memory).

Steve

Edited August 8, 2020 by teoria_del_big_bang

[Starwiz]

3 hours ago, Realtimedoctor said:

A wild thought is sometime during the night/imaging session is APT does a meridian flip -> you wake up to the mount pointing in a different direction, assuming it has "slew" to a new target.

 

3 hours ago, teoria_del_big_bang said:

But after a flip without  a successful platesolve then the mount could be a long way off target even if polar alignment was reasonable and tracking was working. Also it would definitely re-enabe PHD2 and select a new star whatever the settings (I think from memory).

Thanks both, but I'm still a few hours away from the meridian flip time, so it can't be that.

John

[Realtimedoctor]

6 minutes ago, Starwiz said:

 

Thanks both, but I'm still a few hours away from the meridian flip time, so it can't be that.

John

How far off was your image after the clouds, compared to your original target? 

[Starwiz]

1 hour ago, Realtimedoctor said:

How far off was your image after the clouds, compared to your original target? 

I've done a plate solve to find out.

Target position RA = 02 : 35 : 38, DEC = 61 : 30 : 51

New (unwanted) position after slew RA = 02 : 40 : 10, DEC = 62 : 39 : 38

[Realtimedoctor]

2 minutes ago, Starwiz said:

I've done a plate solve to find out.

Target position RA = 02 : 35 : 38, DEC = 61 : 30 : 51

New (unwanted) position after slew RA = 02 : 40 : 10, DEC = 62 : 39 : 38

This seems exactly what a drift will do, since you've error in both Dec and RA, a polar alignment error is the culprit. 

Tracking errors are usually very small and mainly dominate RA. Whereas in your case, DEC is more off. 

You can also set phd2 to abort guiding after a number of failed attempts to search for guidestar. Or not sure if APT has such settings, where you enforce align/platesolve after guiding failure. 

[alacant]

10 hours ago, Starwiz said:

As a result, it starts slewing the mount.

Hi

That seems unlikely. The only time when phd2 will slew the mount is during polar alignment.

We need to look at the guide log, find the time when the star was lost and take it from there. I'm afraid anything else is just a guess.

I've found that automation is one of the most difficult parts of AP. The closest I've come out of the box is the EKOS scheduler with the hardware under indi. That will cope with lost star events and go all night unattended. But remember PHD2 only reports the lost star. It's up to the capture software to do something about it. I'm not sure apt has that ability.

Cheers and HTH.

Edited August 8, 2020 by alacant

[Starwiz]

2 hours ago, Realtimedoctor said:

You can also set phd2 to abort guiding after a number of failed attempts to search for guidestar. Or not sure if APT has such settings, where you enforce align/platesolve after guiding failure.

Thanks, I'll have a look at what APT can do.

John

[Starwiz]

2 hours ago, alacant said:

Hi

That seems unlikely. The only time when phd2 will slew the mount is during polar alignment.

We need to look at the guide log, find the time when the star was lost and take it from there. I'm afraid anything else is just a guess.

I've found that automation is one of the most difficult parts of AP. The closest I've come out of the box is the EKOS scheduler with the hardware under indi. That will cope with lost star events and go all night unattended. But remember PHD2 only reports the lost star. It's up to the capture software to do something about it. I'm not sure apt has that ability.

Cheers and HTH.

Thanks, I'm going to investigate if APT can do more when this happens.

John

[michael8554]

At the start of a Star Lost situation I have occasionally seen PHD2 send Fast Recentre or similar corrections that send the mount way off target.

I guess it's only when the Star Loss is at a certain point in the "get image - measure error - send correction" sequence.

Michael

[Starwiz]

13 hours ago, michael8554 said:

At the start of a Star Lost situation I have occasionally seen PHD2 send Fast Recentre or similar corrections that send the mount way off target.

I guess it's only when the Star Loss is at a certain point in the "get image - measure error - send correction" sequence.

Michael

Thanks, I'll look into that.

John

[teoria_del_big_bang]

20 hours ago, Starwiz said:

I've done a plate solve to find out.

Target position RA = 02 : 35 : 38, DEC = 61 : 30 : 51

New (unwanted) position after slew RA = 02 : 40 : 10, DEC = 62 : 39 : 38

So the unwanted position is still in the general direction of your target, but too far off for it to be in the frame.

What makes you think it slew to this position rather than having drifted to it over the imaging session since the cloud cover occurred ?

If you have some evidence it slew to that new position then we can stop talking about drift. 

Before the plateslove did the mount think it was in the correct position or the new unwanted position ?

Steve

[Starwiz]

6 hours ago, teoria_del_big_bang said:

What makes you think it slew to this position rather than having drifted to it over the imaging session since the cloud cover occurred ?

That's a good point.  My subs were 6 minutes and I had long star trails, which I thought were too long for just drifting unguided.  I will try taking an unguided frame to see how far it drifts for comparison.

I've just stretched one of the frames to take a closer look and the star trail looks like a zig-zag.  I think this could mean that PHD2 is still trying to make corrections even though the star is lost????

 

[michael8554]

Can you identify what time that frame was taken and post the relevant PHD2 Guidelog  ?

Michael

[Starwiz]

9 hours ago, michael8554 said:

Can you identify what time that frame was taken and post the relevant PHD2 Guidelog  ?

Michael

The file time for that frame was 08/08/2020 02:40:41.

Files attached.

Thanks

John

 

PHD2_DebugLog_2020-08-07_213456.txt PHD2_GuideLog_2020-08-07_213456.txt

[whipdry]

I had a similar issue with PHD2 the last couple of nights, decided it could be the high temperatures effecting my uncooled guide camera... making a new set of darkframe at 24° C seems to have fixed it.

Here's what the issue looked like on screen;

 

Peter

[Starwiz]

1 hour ago, whipdry said:

I had a similar issue with PHD2 the last couple of nights, decided it could be the high temperatures effecting my uncooled guide camera... making a new set of darkframe at 24° C seems to have fixed it.

Here's what the issue looked like on screen;

 

Peter

Thanks, I'll give that a try.  I also have an un-cooled guide camera and it's in the mid-20s at night in Malta this time of year.

I had a full imaging run last night for the first time in several days.

John

[michael8554]

I've looked at the Star Lost positions in the Log and to be honest I don't know what is really happening.
So I will theorise 😆

First you haven't made any Dark or Defect maps for the camera, so the chances of locking on a hot pixel are high.

 

 

PHD2 then continously send Max Dur corrections (up to the horizontal red dotted line), trying to move that pixel into the centre of the guide box, which it never will be able to do.

(Note the vertical scale is 50arcsecs, so the normal guide pulses leading up to the Star Lost are too small to see, and I've only shown Dec for simplicity).

I notice that all the way through your guiding, PHD2 is showing the SAT message on every guide exposure - PHD2 auto select shouldn't select a Saturated star ?

Even on the very low star signal (yellow line), SAT was indicated.

Was the red SAT message not showing on the bottom taskbar?

You might try changing your Star Detection method.

 

Your guide HFD is about 3.5 pixels, so you could deselect Star Mass Detection and set HFD to 2, which is a higher figure than a hot pixel.

Though the PHD2 developers deny it, I believe it is all too easy to widely loose position during a Star Lost situation.

Finally, I think you're very brave leaving your mount unattended for long periods, when the chances of mount Runaway or uncorrected Star Loss are not zero, leading to wrapped cables or tripod/counterweight intimacy .

(and lots of wasted exposures).

Michael

[Starwiz]

59 minutes ago, michael8554 said:

I've looked at the Star Lost positions in the Log and to be honest I don't know what is really happening.
So I will theorise 😆

First you haven't made any Dark or Defect maps for the camera, so the chances of locking on a hot pixel are high.

 

 

PHD2 then continously send Max Dur corrections (up to the horizontal red dotted line), trying to move that pixel into the centre of the guide box, which it never will be able to do.

(Note the vertical scale is 50arcsecs, so the normal guide pulses leading up to the Star Lost are too small to see, and I've only shown Dec for simplicity).

I notice that all the way through your guiding, PHD2 is showing the SAT message on every guide exposure - PHD2 auto select shouldn't select a Saturated star ?

Even on the very low star signal (yellow line), SAT was indicated.

Was the red SAT message not showing on the bottom taskbar?

You might try changing your Star Detection method.

 

Your guide HFD is about 3.5 pixels, so you could deselect Star Mass Detection and set HFD to 2, which is a higher figure than a hot pixel.

Though the PHD2 developers deny it, I believe it is all too easy to widely loose position during a Star Lost situation.

Finally, I think you're very brave leaving your mount unattended for long periods, when the chances of mount Runaway or uncorrected Star Loss are not zero, leading to wrapped cables or tripod/counterweight intimacy .

(and lots of wasted exposures).

Michael

Many thanks.  Lots to think about and try in there.

John