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

Unexplained and unexpected but repeatable

  • Please log in to reply
21 replies to this topic

#1 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 03:52 AM

A couple of days ago, I experienced a strange issue in the middle of the night and put up a post here about it www.cloudynights.com/topic/699024-can-someone-take-a-look-at-my-logs-and-explain-what-went-wrong/ in which Wade kindly suggested PHD lost the guide star and focused on a pixel....reasonable assumption.

Last night, I was capturing more data and the issue repeated at almost the same part of the night. Guiding just goes nuts (see log and image) and when I try to recover the sequence, SGP refuses to plate solve. Don't think it's an issue with my mount which has been flawless since buying it, I have no snagging cables as they are all hooked into an Eagle and the mount is well balanced. Any ideas? Keen to do another imaging running tonight as it is clear but I'm not thinking the problem is going to replicate. Images to follow

 

 

 

 

 

Attached Files



#2 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 03:53 AM

PHD_Image.PNG



#3 colinrm

colinrm

    Sputnik

  • -----
  • Posts: 30
  • Joined: 16 Sep 2019

Posted 26 March 2020 - 03:55 AM

Does this happen at the meridian flip?  I had a problem where my flip wouldn't work right, and the software would restart PHD2 guiding even though it wasn't pointed to even close to the right part of the sky.  I thought it was a guiding problem at first.  This turned out to be an EQMOD problem, in case it applies to you.



#4 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 03:55 AM

SGP_Screenshot.jpg



#5 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 03:56 AM

Does this happen at the meridian flip?  I had a problem where my flip wouldn't work right, and the software would restart PHD2 guiding even though it wasn't pointed to even close to the right part of the sky.  I thought it was a guiding problem at first.  This turned out to be an EQMOD problem, in case it applies to you.

No...no meridian flip last night. Not using EQMOD



#6 colinrm

colinrm

    Sputnik

  • -----
  • Posts: 30
  • Joined: 16 Sep 2019

Posted 26 March 2020 - 04:15 AM

I'm no expert, but I'm wondering if a worm gear tooth got broken off or is badly machined.  Does it always happen at the same part of the sky?  It's weird how it guides just fine and the goes nuts.  My guess is it must be some kind of mechanical problem.  Maybe a piece of metal dust got stuck in a tooth.  But I guess that wouldn't be the case for both dimensions?



#7 schmeah

schmeah

    Fly Me to the Moon

  • *****
  • Posts: 5,485
  • Joined: 26 Jul 2005
  • Loc: Morristown, NJ

Posted 26 March 2020 - 06:37 AM

I'm no expert, but I'm wondering if a worm gear tooth got broken off or is badly machined.  Does it always happen at the same part of the sky?  It's weird how it guides just fine and the goes nuts.  My guess is it must be some kind of mechanical problem.  Maybe a piece of metal dust got stuck in a tooth.  But I guess that wouldn't be the case for both dimensions?

He’s got an Avalon Linear, so no tooth gear to break. Becomart, I recently had a similar issue with my M Uno. Too much going on at the moment to get back out and try to diagnose it. But same thing. Lost a guide star and wham ... PHD graph went berserk. Now keep in mind, I’ve always had a lot of RA drift which I’ve detailed in older threads. But when I ran the guide assistant, the RA drift was absurdly high. Did you try to recalibrate PHD/ run the guide assistant.

 

Derek



#8 BoskoSLO

BoskoSLO

    Vostok 1

  • -----
  • Posts: 136
  • Joined: 04 Jul 2018
  • Loc: North Slovenia

Posted 26 March 2020 - 07:49 AM

Have you tried using manual control with EQMOD interface to manually drive the mount west using the slowest or second slowest setting just before this happens? While doing this take very short exposures and see if the stars get wiggly like you showed us above. If nothing is comes up and the mount runs fine without making weird noises then maybe there is a problem in software?



#9 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 5,447
  • Joined: 24 Feb 2007
  • Loc: Snohomish, WA

Posted 26 March 2020 - 10:27 AM

What does the PHD2 screen look like when the problem is actually happening?  It looks like the screen shot that you attached shows that it's just recovered.

 

Also, are you using an OAG?  I saw a couple of instances in the SGP log where the guider was failing to settle right after an auto-focus.  If you are guiding through focus changes or filter changes, it's possible that PHD2 is losing the guide star due to either poor focus (as the autofocus routine runs) or during a filter change (if you are using an SCT and have focus shift). 

 

If PHD2 locks onto a hot pixel during these times, it will do full max moves to try and get to the hot pixel.  By the time the image is back in focus, PHD2 might be hopelessly lost by that point.

 

You could potentially mitigate this by lowering the max move in both RA and dec.  Right now, it's set to 2000ms.  Try setting it much lower.  Your guiding is good enough that you could potentially lower it to something between 200ms and 500ms.  That would limit the amount of damage it could do in the event it's trying to guide on a poor image.



#10 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 12:21 PM

He’s got an Avalon Linear, so no tooth gear to break. Becomart, I recently had a similar issue with my M Uno. Too much going on at the moment to get back out and try to diagnose it. But same thing. Lost a guide star and wham ... PHD graph went berserk. Now keep in mind, I’ve always had a lot of RA drift which I’ve detailed in older threads. But when I ran the guide assistant, the RA drift was absurdly high. Did you try to recalibrate PHD/ run the guide assistant.

 

Derek

I will try running the guide assistant tonight before running the sequence. I had been reluctant to use the guide assistant before this because of the way avalon mounts work. Do you know if the guide assistant will give accurate instructions?



#11 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 12:23 PM

What does the PHD2 screen look like when the problem is actually happening?  It looks like the screen shot that you attached shows that it's just recovered.

 

Also, are you using an OAG?  I saw a couple of instances in the SGP log where the guider was failing to settle right after an auto-focus.  If you are guiding through focus changes or filter changes, it's possible that PHD2 is losing the guide star due to either poor focus (as the autofocus routine runs) or during a filter change (if you are using an SCT and have focus shift). 

 

If PHD2 locks onto a hot pixel during these times, it will do full max moves to try and get to the hot pixel.  By the time the image is back in focus, PHD2 might be hopelessly lost by that point.

 

You could potentially mitigate this by lowering the max move in both RA and dec.  Right now, it's set to 2000ms.  Try setting it much lower.  Your guiding is good enough that you could potentially lower it to something between 200ms and 500ms.  That would limit the amount of damage it could do in the event it's trying to guide on a poor image.

The screen shot I put up, I just tested to see whether it would guide again ok in the middle of the night. That’s what you’re seeing at the end of the graph but it was my manual intervention. There was no filter change, no oag and I’m using by 500mm scope. I will give your max move a try after seeing what the guide assistant says. 



#12 klaussius

klaussius

    Ranger 4

  • *****
  • Posts: 358
  • Joined: 02 Apr 2019
  • Loc: Buenos Aires

Posted 26 March 2020 - 03:25 PM

Granted, I'm not using PHD, but I've experienced a similar thing one night when a loose power connector would disconnect as the RA axis moved, gently tugging the cable. It would work fine when I set it up, and then an hour later or so, the power cord would lose contact (it wouldn't fall) and the mount stopped moving. A gentle touch and it was working again, it was quite confusing until I noticed where the problem was coming from. But the power outage made guiding go bonkers trying to get back to the right place. One time it happened (it happened like 3 times) the guiding just couldn't re-settle afterwards, it was left in an unrecoverable place (it had drifted a lot, target fully out of frame).



#13 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 11:43 PM

Ok, this is getting stranger by the minute. Repeated the issue again tonight. Tried guiding assistant, no significant changes recommended. Tried you suggestion Wade...better guiding but no solution. After it stopped tonight, I restarted guiding manually and it was fine, perfect graph. However, as in other nights, it refused to do the plate solve so I started to do some testing. Plate solved on M81, wouldn’t slew to within a few hundred pixels. Tried the same thing on Vega. Same outcome.  Returned to the elephants trunk. Same thing. Decided to try something in the south of the sky. Arcturus, perfect plate solve and sync. Sheepishly went outside to check my clutches....it couldn’t be this simple could it? It wasn’t! Installed Astap and repeated the above with the same results. I have no idea what is stopping the mount from syncing accurately to the slew but now believe this is fundamental to the problem. Any more ideas folks? It’s bizarre that it works fine at the beginning of the night and on Arcturus. Found this thread with a similar issue http://forum.mainseq...ot-working/4304



#14 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 26 March 2020 - 11:57 PM

Just updated ASCOM. No difference. Running the latest versions of PHD and SGP. 



#15 dayglow

dayglow

    Vostok 1

  • -----
  • Posts: 160
  • Joined: 15 Aug 2013

Posted 27 March 2020 - 12:23 AM

Loose dovetail connection to the scope rings ?

 

Satellite trail crossing your guide star ?

 

Airplane light trail crossing your guide star ?

 

Any theories for the dip in guide star magnitude that started at graph time 2:25 am (which I think is tagged in the data stream as 2:22:40 am ?  The magnitude recovers but not for a couple of minutes.  Passing cloud ?

 

The first post with this problem shows guide star profile from PHD2.  In that instance, it looks like you may have been guiding on a double star.  Still would not cause the issue at hand.



#16 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 27 March 2020 - 04:00 AM

Ok...going to take this to the SGP guys. There is one thing that has just come to mind. I had to migrate my Eagle from Windows Enterprise to Windows 10 as I wasn't able to update SGP on enterprise. I'm wondering if something bit of code has logged itself in the registry as part of the transition....getting desperate now. Another clear night - 4 in a row which is almost unheard of for UK skies and I will have lost a total of over 8hrs in imaging time if the problem repeats again tonight.



#17 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,680
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 27 March 2020 - 07:13 AM

Do you possibly have a travel limit set in the mount?

 

Alex



#18 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 5,447
  • Joined: 24 Feb 2007
  • Loc: Snohomish, WA

Posted 27 March 2020 - 10:23 AM

However, as in other nights, it refused to do the plate solve so I started to do some testing. Plate solved on M81, wouldn’t slew to within a few hundred pixels. Tried the same thing on Vega. Same outcome.  Returned to the elephants trunk. Same thing. Decided to try something in the south of the sky. Arcturus, perfect plate solve and sync. Sheepishly went outside to check my clutches....it couldn’t be this simple could it? It wasn’t! Installed Astap and repeated the above with the same results. I have no idea what is stopping the mount from syncing accurately to the slew but now believe this is fundamental to the problem. 

I'm having trouble understanding exactly what you mean here.

 

When you say that it "refused to do the plate solve", what does this mean?  Does it meant that it doesn't attempt to plate solve?  Does it mean that it attempts a plate solve, but the plate solve itself fails?  Does it mean that it can successfully plate solve, but the subsequent sync and precision slew doesn't converge on the target?

 

When you installed ASTAP, did it successfully plate solve (ie. did the solve itself succeed, or was there an error)?  In my experience with ASTAP, it is incredibly robust.



#19 Alex McConahay

Alex McConahay

    Cosmos

  • *****
  • Posts: 8,680
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 27 March 2020 - 11:10 AM

I'm having trouble understanding exactly what you mean here.

 

When you say that it "refused to do the plate solve", what does this mean?  Does it meant that it doesn't attempt to plate solve?  Does it mean that it attempts a plate solve, but the plate solve itself fails?  Does it mean that it can successfully plate solve, but the subsequent sync and precision slew doesn't converge on the target?

 

When you installed ASTAP, did it successfully plate solve (ie. did the solve itself succeed, or was there an error)?  In my experience with ASTAP, it is incredibly robust.

Yeah, distinguish between Plate Solving (identifying where the center of an image) and Centering (correcting the telescope pointing using the plate solve information and the mount mechanics).  

 

If you cannot tell where the picture is, Plate solving is failing. If you cannot subsequently move your scope to the proper position (and confirm with a plate solve), then Centering is failing. 

 

Alex



#20 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 27 March 2020 - 11:22 AM

I'm having trouble understanding exactly what you mean here.

 

When you say that it "refused to do the plate solve", what does this mean?  Does it meant that it doesn't attempt to plate solve?  Does it mean that it attempts a plate solve, but the plate solve itself fails?  Does it mean that it can successfully plate solve, but the subsequent sync and precision slew doesn't converge on the target?

 

When you installed ASTAP, did it successfully plate solve (ie. did the solve itself succeed, or was there an error)?  In my experience with ASTAP, it is incredibly robust.

Apologies for the lack of clarity folks....put it down to sleep! Plate solving works in so much as it solves the image and attempts to centre the mount but it won’t centre correctly on the targets I explained above. It’s always between 200-400 pixels away. My sequence is set to abort at 50 pixels which I don’t really want to change. Astap also solved the image but again would not centre on the image correctly. Therefore, think the fault lies between the software and the mount. Honestly can’t see it been the mount and there are no travel limits, it’s been flawless - suspect it’s SGP related. I may try setting up voyager on a trial basis and see what happens but I won’t be able to sort that before tonight’s imaging run. 



#21 Becomart

Becomart

    Apollo

  • -----
  • topic starter
  • Posts: 1,109
  • Joined: 03 Jan 2015

Posted 28 March 2020 - 03:39 AM

Ok, just an update on this. Think this might be a window problem which has corrupted drivers and software. What I had forgotten about until last night was that I recently had to force my Eagle through a conversion to windows 10. This is because Microsoft stopped supporting enterprise 2015 lstb (and therefore .net so SGP wouldn’t work) with no upgrade path so I bought a license, did some registry edits as advised by people who had been in the same position and went through the conversion. All seemed to go well and I spent a night testing with no problems. 
Last night, I went to set up knowing even if the problem occurred again, I would get to the 30hr point of data I needed to complete my elephant Nebula. SGP wouldn’t load nor would the Avalon Stargo connect to the mount. I did a diagnostic test and got the screen shot below and then it dawned on me, this looks like a windows corruption problem. 
At the very least, looks like I’m going to need to do a fresh install or send back to Italy for enterprise lstb 2019 upgrade. Pretty gutted as everything is in lock down here and nobody is allowed out of their house so this could put me out of imaging for a while. 
002F1FFE-748C-4071-AD0D-06568172E5CE.png



#22 klaussius

klaussius

    Ranger 4

  • *****
  • Posts: 358
  • Joined: 02 Apr 2019
  • Loc: Buenos Aires

Posted 28 March 2020 - 10:44 AM

Apologies for the lack of clarity folks....put it down to sleep! Plate solving works in so much as it solves the image and attempts to centre the mount but it won’t centre correctly on the targets I explained above. It’s always between 200-400 pixels away. My sequence is set to abort at 50 pixels which I don’t really want to change. Astap also solved the image but again would not centre on the image correctly. Therefore, think the fault lies between the software and the mount. Honestly can’t see it been the mount and there are no travel limits, it’s been flawless - suspect it’s SGP related. I may try setting up voyager on a trial basis and see what happens but I won’t be able to sort that before tonight’s imaging run. 

Is the date correctly set?

 

While coding my own centering routine, I found out differences in date (not time) could cause this behavior.

 

Edit: Oof... that ASCOM error doesn't look good.


Edited by klaussius, 28 March 2020 - 10:56 AM.



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