PHD2 does not find a new guide star after flip

[Bobby Sapovits]

I've been having problems with PHD2 finding a guide star after the Meridian Flip. The flip has no problems. APT does what it is supposed to do. APT controls guiding is checked. Guide camera is a Meade Advanced LPI-G. Mount is ZWO AM-5. Re-Calibrate after flip is off. Blind solve after flip is checked. PHD2 delay set to 30s. 

Logs uploaded: https://openphdguiding.org/logs/dl/PHD2_logs_tsKg.zip

What happens is this:

• When the flip starts, PHD2 stops guiding and the green multi star point circles turn into red dashed circles.

• After the flip, and Point Craft re-centers, the red dash circles turn green and the guide box resumes at the same position as before the flip.  Guiding starts immediately with no looping.

• If you leave PHD2 alone, it will continue to try and find a star in the guide box. It does not look for a new star. Eventually, it will fill the box with a star (when one wanders into the box by drift), but by this point the mount has now moved from the target.

I'm working on M101 and the stars are sparse in that region. I think this is the reason I have not seen this before. This could be a APT problem as well, although it's probably "user error".
It seems that the looping step is missing. Shouldn't the sequence be:

• Guiding stops.
  
• Flip occurs.
  
• Re-centering
  
• PHD2 Looping starts.
  
• Guide star is chosen.
• Guiding resumes.
• All is at one with the universe.

Log file from APT is attached.  Thanks in advance.

Bobby

[Brian Valente]

Hi Bobby

From your guidelog it looks like you were able to guide successfully on both sides of pier. Did you intervene?

It looks to me like it was able to achieve a guidestar, but that reverse dec option was set incorrectly.

Try using the 'calibrate meridian flip' tool just to confirm that setting

Also I'm curious how you came up with your settings for the AM5? you are using ppec at a long period length, which seems odd to me. I thought the strain wave mounts have a very different periodic error signature

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, 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/cb25c2b7-7adb-4f42-a072-7b6f605e523fn%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

[Bruce Waddington]

These are the commands that APT sent to control guiding:

 

21:59:24.452 01.555 6164 evsrv: cli 0B842330 request: {"method":"guide","params":[{"pixels":0.6,"time":10,"timeout":60},false],"id":3}

22:00:14.451 00.749 6164 evsrv: cli 0B842330 request: {"method":"stop_capture","id":4}

22:03:38.741 204.149 6164 evsrv: cli 0B842330 request: {"method":"guide","params":[{"pixels":0.6,"time":10,"timeout":60},false],"id":6}

23:26:10.077 00.063 6164 evsrv: cli 0B841C50 request: {"method":"stop_capture","id":8}

23:36:54.405 644.250 6164 evsrv: cli 0B841C50 request: {"method":"guide","params":[{"pixels":0.6,"time":10,"timeout":60},false],"id":10}

 

This would have produced 3 guiding sequences but there are 5 in the log.  That’s because you chose to dive in from the user interface and try to change what was happening.  It looks like APT isn’t sophisticated enough to know when this happens so it just plowed ahead assuming that it was in control.  If you are going to use an automation app, you need to let it run the show.  If you have to do something interactively, you need to stop or pause the automation app or you will get everything out of synch.  So I would say you shot yourself in the foot here.  Meridian flipping works fine as long as you have available stars – and you did.  Everything would probably have gone according to plan if you had let it run. 

 

Good luck,

Bruce

--

[Bobby Sapovits]

I'm confused about what you are saying.  The first three log events you list are well before the flip (23:25 start) and all are due to automated refocusing due to temperature change.  (APT stops guiding during refocus.)   How do they contribute?  What does "dive in from the user interface" mean?  After I got APT started, I did not make any changes in it up to the flip.

Here is the sequence of events that happened at the time of the flip:

1. Meridian flip occurs.  APT stops guiding.
2. Meridian flip ends.  APT re-acquires target after plate solving.
3. APT resumes guiding.
4. Guiding resumes with the target box in the same location as before the flip.  No star is found.  PHD2 continues to look for a star in the same position.  PHD2 does not look for a new star in a new position.
5. I let PHD2 run for about a minute trying to find a star.
6. I stop guiding, disconnect and re-connect equipment.  
7. I use APT to re-locate target.
8. I use PHD2 to find a new star and begin guiding.

This problem started two nights earlier.  On that night, I checked progress about an hour and a half after flip.  PHD2 was all over the place.  I stopped PHD2 and did steps 6, 7, and 8 from the above checklist to get back on track.  (That is why I stopped PHD2 on the night in question.  I assumed that it was going to do the same thing.)   Checking files the next morning, everything was star trails for 1.5 hours of images. 
So here is where is gets weird.  Last night, I decided to screen record the whole automated flip.  Which I did.  Except that everything worked as it should.   The difference that I saw was what PHD2 did when guiding resumed.  Instead of the target box not moving, the image blanked for a fraction of a second almost immediately after guiding re-started and a new star was acquired (target box now in new location with a star).  This is not what happened on the night in question.  At that time, PHD2 did not have a green target box when guiding stopped, but just the small red dashed circles.  When guiding resumed, the green target box resumed in the same location as before the flip and did not try to move to a suitable star (which was visible in the frame) in the time I observed.  Settings, target, equipment, etc. were the same for all nights.

I have attempted to upload logs from the other nights in question, but there appears to be problems as neither can I upload, or access the PHD2 website.  I'll try again later.

Bobby

[Bobby Sapovits]

I continue to have intermittent flip/guide problems.  Sometimes it works, and sometimes it doesn't.  Last night it did not work and I did manage to get a screen video to help better describe the problem.  (Link below.)

The video starts a few seconds before APT completes it's flip procedure and sends the command for guiding to resume.  The video shows about two minutes of the trouble before it ends.  

If you watch the video carefully,  you will see that in the seconds before the guiding continues,  the PHD2 screen shows the dashed circles of stars from the previous guide session.  Next the screen changes to green circles and the green target.  The green target is centered on a star with a SNR of three digits.  A fraction of a second later the screen now has a new star field and the star that was in the target box is now gone.  It appears that the first screen to pop up is a frame from the guiding done before the flip.  Once a frame from the new star field is used, PHD2 continues to look for that star that disappeared and does not attempt to auto find a new star to use.  This continues until I manually stop the camera and restart looping and find a guide star.   It does this despite min SNR is set at 40.   On one of my earlier run ins with this issue, the guiding continued to look for a  star where one wasn't for over an hour.

I've posted this question in the APT forum, but all APT does is start and stop guiding, which it does.  My only settings in APT which include PHD2 are delays of 15 seconds after GOTO's and a Guiding Resume Delay of 10 seconds.  I also dither PHD2 through APT with varying distances and number of images.

I would recommend reading my previous two posts to get more facts on what is going on.  PHD2 log link is below.

Bobby

https://equusbicycle.com/phd2/PHD2_Flip_error_2023-06-01%20223044_Trim.mp4

https://openphdguiding.org/logs/dl/PHD2_logs_8vc2.zip

[Bruce Waddington]

Your problem is that your gear isn't able to do meridian flips with any kind of stability.  After the meridian flip, the mount is essentially wandering all over the place and the primary star selected by auto-find is immediately  lost. Here's the sequence:

1.  After completion of the meridian flip, auto-find successfully found a new list of guide stars.  The primary star was located at sensor location {2726, 526}, had an SNR of 176.9 and an HFD of 3.2 px.  It was a fine guide star.  The auto-selection was accomplished using a guide camera exposure taken at 22:24:19.014.

2. At 22:24:23.717, the next camera exposure was examined and the guide star was no longer in the search region at all.  Instead, a different star had moved into the search region with a much lower SNR and a completely different position at {2744, 541}.  This wasn't the same star, it wasn't even close.  Bottom line, your original guide star, the one chosen by auto-find, was long-gone.

3.  From that point on, you encountered a series of lost-star events and large guide star excursions.  A more capable automation app could have recognized this and decided what to do - e.g. stop the main camera exposure, re-start guiding, confirm guiding was stable, plate-solved a test image, determined the scope was no longer on-target, re-centered the target, and resumed guiding.

The wild guide star excursion isn't surprising at all.  Look at the huge guide star excursions that were occurring even before you did the meridian flip (RA in red):

These have nothing to do with guiding, the problems are being caused by the equipment riding on the mount. Meridian flips can severely test the mechanics of the imaging payload - cables wrap and drag across stationary surfaces, components move and sag where there are slightly loose mechanical interfaces, etc.  I don't think you have any of this nailed down sufficiently to expect a meridian flip to proceed smoothly.  Until you do, you should expect these problems to continue.

It takes time to sift through someone's log and reconstruct what happened, so it's a skill you should probably master.  By looking at the debug log file and using  the time stamp information and the other details I've given you, you should be able to see how I've done this - and then you can do it yourself going forward as you try to work through these issues.  Important strings to search for on these kinds of problems are  'Star::AutoFind called',  'AutoFind returns star' , ,Star::Find returns'.  It's not hard, just tedious.  Squinting at the screen and taking videos is a waste of time, it won't tell you what's happening.  if you can't deal with it any other way, you could impose a long delay after a meridian flip before the automation app tries to resume imaging - assuming that it will then plate-solve and re-center correctly.

Bruce

[Bobby Sapovits]

Bruce,

Your example was from 4 hours before the flip.  It was due to a cable problem which was fixed.  I have tried different delays with no change.  You are correct on the guide logs, I study them often.  But sometimes you have to step back few feet and take a broader look.  For instance, the guide logs do not show an image of what star field was on the screen or a plate solving.  If I fed PHD2 with a video where the star field changed randomly every few frames, how would it react?  Would you be able to figure that out with just the logs?  With that, I would ask you to kindly bear with me and try to understand what I think is going on.

I've taken the screen video and broke it down.  The first image below is the image that PHD2 saw immediately after guiding started (with the high SNR):

Next is an image taken just a few frames later:

The two images next to each other (enhanced in Photoshop to show the stars more clearly).

Note how different the two star fields are.  Remember, these images are only a few frames apart from each other.  Well under one second.  You can see this in the screen video if you scrub back and forth during the change.  This also shows another hint that the mount is not the problem.  None of the images have star trails.  Any movement of this size should produce star trails in one or more frames.  (3 second exposures).  Now I took the two images, flipped one upside down and stacked them in PS slightly misaligned:

It's the same star field.  One from the east side of the mount, the other from the west side of the mount.  But both images were presented to PHD2 while on the west side.  The mount did not move erratically, the images did.  As I stated in previous posts,  I'm pretty sure that the image first seen by PHD2 is a 'leftover' image from before the flip. That is enough to allow PHD2 to start on (what it assumes is) a good star.  But a frame or two later, the actual star field is shown.  PHD2 thinks that the star has moved when what has actually happened is that an entirely new star field image is now being presented.  From my understanding of how PHD2 works, it will continue to try and find that star forever until it is commanded to find a new guide star.  I tried to plate solve the images, but there is not enough resolution in the star fields.  

I don't think PHD2 is at fault.   The guide camera used is a Meade Advanced LPI color.  Perhaps there is something in it's driver that keeps that one image in it's 'memory'.  Perhaps it is something to do with the USB pipeline.   I'm going to try a different camera and will report in a few weeks (if it works) or very soon (if the problem persists).

Bobby

[Bruce Waddington]

If you think your problems are caused by bad data being returned from the camera, you should be using the Diagnostic Image Logging features in PHD2.  Those options are located on the 'Global' tab of Advanced Settings and are discussed in the User Guide.

Bruce

[Bobby Sapovits]

Here are diagnostic images from a recent night:

https://www.equusbicycle.com/phd2/2023_09_03/

Here is the logs:
https://openphdguiding.org/logs/dl/PHD2_logs_zZC6.zip

You will notice that both an event image (star lost) and an auto select image have the same time stamp.  When viewing both you will also see that one is a flipped version of the other.  After the first Star Lost image, there follows 19 more Star Lost images spanning approximately 2 minutes.  At this point I manually restart PHD2.  The framing has also moved a considerable amount as well.  PHD2 is not looking for a new star as it thinks it has already done this.  If you watch PHD2 after the flip, you will see the Auto Select image below flash for a second; long enough for PHD2 to auto select a star.  Then the second image loads and PHD2 continues to look for the star that it selected in the first frame.  This all occurs post flip, the mount is not flipping back and forth.  In any event, I doubt any mount can make a flip in under 60 seconds.

 

I don't believe that PHD2 is at fault.  This has only occurred with Meade cameras, (LPI, LPI Advanced).  For some reason, a pre-flip exposure is getting "stuck" in the pipeline.  I need to find a way to clear it out before PHD2 starts guiding.  Perhaps an optional AutoSelect delay of 1-5 seconds?

Bobby

[Bruce Waddington]

Why do you have to restart PHD2?  Doesn't the problem resolve if you simply do another auto-find?  Are you saying that bad camera frames continue to be returned until you disconnect the camera? Doesn't your automation app respond to the lost-star condition by repeating the auto-find and resuming guiding?

[Bobby Sapovits]

I do not restart PHD2.  I stop the current guiding and use the auto find to get a new star(s).  This can only be done manually.  If I let PHD2 continue, it will continue to look for the original star.  Eventually, it will find a star that may drift into the field, but by that point, the scope may have moved far off of the target.  It was my assumption that APT can only send a 'start guiding' command.  I was unaware that it is possible for APT to also tell PHD2 to look for new star when one cannot be found.  If it can perform that function, I'll see if I can get them to add it to the features.  I have tried to use the start guiding delay but it only puts off the time the troubles start.  Be that as it may, there is still the problem of the first image that PHD2 sees.  It is leftover from the pre-flip and does not represent what the guide camera actually sees post flip.  This is really what needs to be fixed.  Everything else is just a workaround.

Bobby

[bw_m...@earthlink.net]

Yes, that is what needs to be fixed and the fix needs to be in the camera driver or the hardware, whichever is the root source.  We don’t want to lard up the UI in PHD2 to sidestep hardware problems unless those problems are endemic to the amateur astro community – things like backlash and periodic error.  Your situation does not fall into that category, not even close.  I suggest you communicate with Meade to fix the problem or replace the guide camera.  If the latter, I suggest getting a better camera from a different manufacturer, one better suited to guiding.    If you are committed to kludging a workaround in PHD2, you can download the source code and do whatever you’d like.

 

Bruce

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Bobby Sapovits
Sent: Monday, September 4, 2023 12:54 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>

Subject: Re: [open-phd-guiding] PHD2 does not find a new guide star after flip

 

I do not restart PHD2.  I stop the current guiding and use the auto find to get a new star(s).  This can only be done manually.  If I let PHD2 continue, it will continue to look for the original star.  Eventually, it will find a star that may drift into the field, but by that point, the scope may have moved far off of the target.  It was my assumption that APT can only send a 'start guiding' command.  I was unaware that it is possible for APT to also tell PHD2 to look for new star when one cannot be found.  If it can perform that function, I'll see if I can get them to add it to the features.  I have tried to use the start guiding delay but it only puts off the time the troubles start.  Be that as it may, there is still the problem of the first image that PHD2 sees.  It is leftover from the pre-flip and does not represent what the guide camera actually sees post flip.  This is really what needs to be fixed.  Everything else is just a workaround.

Bobby

On Monday, September 4, 2023 at 1:51:19 PM UTC-4 bw_m...@earthlink.net wrote:

Why do you have to restart PHD2?  Doesn't the problem resolve if you simply do another auto-find?  Are you saying that bad camera frames continue to be returned until you disconnect the camera? Doesn't your automation app respond to the lost-star condition by repeating the auto-find and resuming guiding?

On Monday, September 4, 2023 at 8:43:30 AM UTC-7 bobe...@equusbicycle.com wrote:

Here are diagnostic images from a recent night:

https://www.equusbicycle.com/phd2/2023_09_03/

Here is the logs:
https://openphdguiding.org/logs/dl/PHD2_logs_zZC6.zip

 

You will notice that both an event image (star lost) and an auto select image have the same time stamp.  When viewing both you will also see that one is a flipped version of the other.  After the first Star Lost image, there follows 19 more Star Lost images spanning approximately 2 minutes.  At this point I manually restart PHD2.  The framing has also moved a considerable amount as well.  PHD2 is not looking for a new star as it thinks it has already done this.  If you watch PHD2 after the flip, you will see the Auto Select image below flash for a second; long enough for PHD2 to auto select a star.  Then the second image loads and PHD2 continues to look for the star that it selected in the first frame.  This all occurs post flip, the mount is not flipping back and forth.  In any event, I doubt any mount can make a flip in under 60 seconds.

 

I don't believe that PHD2 is at fault.  This has only occurred with Meade cameras, (LPI, LPI Advanced).  For some reason, a pre-flip exposure is getting "stuck" in the pipeline.  I need to find a way to clear it out before PHD2 starts guiding.  Perhaps an optional AutoSelect delay of 1-5 seconds?

Bobby

On Sunday, June 4, 2023 at 12:28:25 PM UTC-4 bw_m...@earthlink.net wrote:

If you think your problems are caused by bad data being returned from the camera, you should be using the Diagnostic Image Logging features in PHD2.  Those options are located on the 'Global' tab of Advanced Settings and are discussed in the User Guide.

 

Bruce

 

On Sunday, June 4, 2023 at 7:17:44 AM UTC-7 bobe...@equusbicycle.com wrote:

Bruce,

Your example was from 4 hours before the flip.  It was due to a cable problem which was fixed.  I have tried different delays with no change.  You are correct on the guide logs, I study them often.  But sometimes you have to step back few feet and take a broader look.  For instance, the guide logs do not show an image of what star field was on the screen or a plate solving.  If I fed PHD2 with a video where the star field changed randomly every few frames, how would it react?  Would you be able to figure that out with just the logs?  With that, I would ask you to kindly bear with me and try to understand what I think is going on.

I've taken the screen video and broke it down.  The first image below is the image that PHD2 saw immediately after guiding started (with the high SNR):

Next is an image taken just a few frames later:

The two images next to each other (enhanced in Photoshop to show the stars more clearly).

Note how different the two star fields are.  Remember, these images are only a few frames apart from each other.  Well under one second.  You can see this in the screen video if you scrub back and forth during the change.  This also shows another hint that the mount is not the problem.  None of the images have star trails.  Any movement of this size should produce star trails in one or more frames.  (3 second exposures).  Now I took the two images, flipped one upside down and stacked them in PS slightly misaligned:

It's the same star field.  One from the east side of the mount, the other from the west side of the mount.  But both images were presented to PHD2 while on the west side.  The mount did not move erratically, the images did.  As I stated in previous posts,  I'm pretty sure that the image first seen by PHD2 is a 'leftover' image from before the flip. That is enough to allow PHD2 to start on (what it assumes is) a good star.  But a frame or two later, the actual star field is shown.  PHD2 thinks that the star has moved when what has actually happened is that an entirely new star field image is now being presented.  From my understanding of how PHD2 works, it will continue to try and find that star forever until it is commanded to find a new guide star.  I tried to plate solve the images, but there is not enough resolution in the star fields.  

I don't think PHD2 is at fault.   The guide camera used is a Meade Advanced LPI color.  Perhaps there is something in it's driver that keeps that one image in it's 'memory'.  Perhaps it is something to do with the USB pipeline.   I'm going to try a different camera and will report in a few weeks (if it works) or very soon (if the problem persists).

Bobby

On Saturday, June 3, 2023 at 11:47:49 PM UTC-4 bw_m...@earthlink.net wrote:

Your problem is that your gear isn't able to do meridian flips with any kind of stability.  After the meridian flip, the mount is essentially wandering all over the place and the primary star selected by auto-find is immediately  lost. Here's the sequence:

 

1.  After completion of the meridian flip, auto-find successfully found a new list of guide stars.  The primary star was located at sensor location {2726, 526}, had an SNR of 176.9 and an HFD of 3.2 px.  It was a fine guide star.  The auto-selection was accomplished using a guide camera exposure taken at 22:24:19.014.

2. At 22:24:23.717, the next camera exposure was examined and the guide star was no longer in the search region at all.  Instead, a different star had moved into the search region with a much lower SNR and a completely different position at {2744, 541}.  This wasn't the same star, it wasn't even close.  Bottom line, your original guide star, the one chosen by auto-find, was long-gone.

3.  From that point on, you encountered a series of lost-star events and large guide star excursions.  A more capable automation app could have recognized this and decided what to do - e.g. stop the main camera exposure, re-start guiding, confirm guiding was stable, plate-solved a test image, determined the scope was no longer on-target, re-centered the target, and resumed guiding.

 

The wild guide star excursion isn't surprising at all.  Look at the huge guide star excursions that were occurring even before you did the meridian flip (RA in red):

 

 

These have nothing to do with guiding, the problems are being caused by the equipment riding on the mount. Meridian flips can severely test the mechanics of the imaging payload - cables wrap and drag across stationary surfaces, components move and sag where there are slightly loose mechanical interfaces, etc.  I don't think you have any of this nailed down sufficiently to expect a meridian flip to proceed smoothly.  Until you do, you should expect these problems to continue.

 

It takes time to sift through someone's log and reconstruct what happened, so it's a skill you should probably master.  By looking at the debug log file and using  the time stamp information and the other details I've given you, you should be able to see how I've done this - and then you can do it yourself going forward as you try to work through these issues.  Important strings to search for on these kinds of problems are  'Star::AutoFind called',  'AutoFind returns star' , ,Star::Find returns'.  It's not hard, just tedious.  Squinting at the screen and taking videos is a waste of time, it won't tell you what's happening.  if you can't deal with it any other way, you could impose a long delay after a meridian flip before the automation app tries to resume imaging - assuming that it will then plate-solve and re-center correctly.

 

Bruce

 

 

 

On Friday, June 2, 2023 at 12:46:49 PM UTC-7 bobe...@equusbicycle.com wrote:

I continue to have intermittent flip/guide problems.  Sometimes it works, and sometimes it doesn't.  Last night it did not work and I did manage to get a screen video to help better describe the problem.  (Link below.)

The video starts a few seconds before APT completes it's flip procedure and sends the command for guiding to resume.  The video shows about two minutes of the trouble before it ends.  

If you watch the video carefully,  you will see that in the seconds before the guiding continues,  the PHD2 screen shows the dashed circles of stars from the previous guide session.  Next the screen changes to green circles and the green target.  The green target is centered on a star with a SNR of three digits.  A fraction of a second later the screen now has a new star field and the star that was in the target box is now gone.  It appears that the first screen to pop up is a frame from the guiding done before the flip.  Once a frame from the new star field is used, PHD2 continues to look for that star that disappeared and does not attempt to auto find a new star to use.  This continues until I manually stop the camera and restart looping and find a guide star.   It does this despite min SNR is set at 40.   On one of my earlier run ins with this issue, the guiding continued to look for a  star where one wasn't for over an hour.

I've posted this question in the APT forum, but all APT does is start and stop guiding, which it does.  My only settings in APT which include PHD2 are delays of 15 seconds after GOTO's and a Guiding Resume Delay of 10 seconds.  I also dither PHD2 through APT with varying distances and number of images.

I would recommend reading my previous two posts to get more facts on what is going on.  PHD2 log link is below.

Bobby

https://equusbicycle.com/phd2/PHD2_Flip_error_2023-06-01%20223044_Trim.mp4

https://openphdguiding.org/logs/dl/PHD2_logs_8vc2.zip

 

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, 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/dae21d34-c4ff-48c4-95ef-189986e74912n%40googlegroups.com.