Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

PHD stops and will not resume during autofocus

  • Please log in to reply
8 replies to this topic

#1 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 26 August 2019 - 10:07 PM

This is a new issue for me. I have both OAGs and a guidescope so I know about the “pause guiding during autofocus” option and this is not that. I am currently using my guidescope. When running a sequence, after “center and rotate”, the autoguiding is resumed and starts. SGP waits to confirm this and then starts the autofocus. This worked flawlessly with me for years. For my guidescope, I have the option to “pause autoguiding during focus” unchecked in the equipment profile, but for my OAG equipment profile, it is checked. Both were working correctly. Last night, I was running with my guide scope. When the autofocus would start, PHD was operating fine. At some point in the autofocus, PHD would just stop. It would simply not update the next point on the guiding graph. It was not hung up. I could do anything with it including stopping guiding, but It would not register then next guiding point. SGP would be sitting there “waiting for autoguiding to settle”. After a while it would time out and abort the sequence. I check the equipment profile and reapplied the profile to the sequence with no effect. SGP would repeatedly do the same thing. I eventually had to turn off autofocus and the sequence would run. Obviously not ideal. It is as if, it is acting like the “pause autoguiding during focus” was checked, but when I use that with my OAG, PHD show a “PAUSED” on the guiding graph and then that goes away when the autofocus is finished, reaquires the guide star and starts running again. I have not tried running my guide scope this way because it should not need this. This is more like SGP issue some command to stop PHD2 but did not issue the command to resume since it thinks that the guiding is not paused. Tonight I will try running with the “pause autoguiding during focus” checked and see if that works, but something is wrong here. I have checked everything I can think of and am out of options. 

 

Tonight, I have spent a bunch more time trying to solve this. I still have the same issue. I have tried both setting for “Pause guiding during autofocus” both checked and unchecked and reapplied to equipment profile to the sequence each time. I have the same issue with PHD stopping. Its like SGP has paused the guiding, but is not sending the resume guiding. I really need help here. I got a response on the SGP forum to post the log file.

 

https://drive.google...?usp=drive_open

 

 

 



#2 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 26 August 2019 - 10:29 PM

Already got some feed back from the SGP forum. They suggested that It might be a USB conflict. I checked and my ASI1600MM-C was set to a USB of 80 - Max. I usually have left it at minimum of 40. Retrying some testing right now and so far so good. 



#3 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 26 August 2019 - 10:51 PM

It is looking like the USB setting on the ASI1600MM-C set to max was the issue. I actually got the sequence running with autofocus. IT started up, ran autofocus and then resumed guiding. Now the wind tonight and 103F temperature today means my mount and guiding are terrible, but I can at least see if the sequence will keep running. 



#4 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 26 August 2019 - 11:27 PM

I just went through automatic meridan flip with autofocus and everything worked. I will do an update with more confidence later, but this is my first issue with any sort of USB communication problem. 



#5 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 27 August 2019 - 09:22 AM

My sequence ran all night without a hitch including autofocus. Tonight, I will be adding 2nd target with different filter combinations that is about as stringent a test as I can come up with. If that passes, then it is clear that I had my first case of USB communication issues. To be clear, my ASI1600MM-COOL camera was set to a USB setting of 80 and the guide scope camera, an ASI174MM-mini, was set to a USB setting of 40. Both are connected with 100% USB3.0 connections through powered USB3.0 hubs. I am wondering if I can cause the issue again by going back to the 80/40 miss-match and if 80/80 would be free of the issue. Easy to test. However, I will try getting data tonight since those sort of tests are for the full moon!...



#6 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 31 August 2019 - 05:43 PM

Well the USB setting seemed to be the issue. Since it reset all the USB speeds to 40, I have had no issues on multiple nights with multiple equipment profiles. Just closing out this thread with the final data.



#7 H-Alfa

H-Alfa

    Viking 1

  • -----
  • Posts: 699
  • Joined: 21 Sep 2006
  • Loc: Spain

Posted 01 September 2019 - 10:15 AM

Hi Chris,

Happy that you solved your issue. I'm facing a similar problem now that I've bought a new guider, a Qhy178M, to work with a Qhy163M. I had connection issues, solved changing the 178M to another port of my USB hub, but I'm still having issues with slow performance on the 178M. Doesn't matter how short the exposure I choose, the delay between guiding samples are at least 1s.
I've been playing with the USB traffic but didn't achieved the performance that I expected, so just to be sure I understood your statement, do you mean that setting USB traffic on both cameras to 40 have been the sweet spot for your system?
Thank you in advance.

Enviado desde mi ANE-LX1 mediante Tapatalk

#8 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • topic starter
  • Posts: 2,800
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 01 September 2019 - 12:57 PM

Hi Chris,

Happy that you solved your issue. I'm facing a similar problem now that I've bought a new guider, a Qhy178M, to work with a Qhy163M. I had connection issues, solved changing the 178M to another port of my USB hub, but I'm still having issues with slow performance on the 178M. Doesn't matter how short the exposure I choose, the delay between guiding samples are at least 1s.
I've been playing with the USB traffic but didn't achieved the performance that I expected, so just to be sure I understood your statement, do you mean that setting USB traffic on both cameras to 40 have been the sweet spot for your system?
Thank you in advance.

Enviado desde mi ANE-LX1 mediante Tapatalk

Yes your statement is correct. However, my cameras are ZWO and I dont know how well that would apply to QHY cameras directly. I have not really had any good luck with QHY cameras - I have tried three in the past and I am trying a fourth right now. I just get a QHY5-III 290 as a camera for my QHY-M OAG and so far it looks good accept from very ugly star shape - not the cameras faults - thats just OAGs. 



#9 H-Alfa

H-Alfa

    Viking 1

  • -----
  • Posts: 699
  • Joined: 21 Sep 2006
  • Loc: Spain

Posted 02 September 2019 - 12:38 PM

Great. Thanks.

Enviado desde mi ANE-LX1 mediante Tapatalk


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics