SGP PHD Communication error? Star lost?

Sequence Generator
1

Hi guys,
I’m sorry I can’t be more specific, but each of the last two nights SGP has aborted the sequence due to the guide star being lost, or for a loss of communication with PHD (?). Examining the (PHD) logs is a bit beyond my understanding so I was hoping someone could take a look and tell me what you see. I can’t figure out the underlying cause of the aborts.

Logs: Dropbox - Error

2

Are you using SX autoguider? If so, the latest SX driver is buggy so I reverted back to previous version and have not had issues since then. Previous version driver is available at SX web site.

Peter

3

Hi Joel,

The logs show your sequence went into recovery mode at around 2:53 am; there were lots of “Star lost” events in the PHD2 Guide Log leading up to that, so you probably had some intermittent clouds coming through. SGP kept trying to recover for 90 minutes but kept failing since the mount refused to slew reporting it could not slew past safety limits:

[7/24/2015 4:09:13 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 20.8149198624585 Dec: 29.998829574766 [7/24/2015 4:09:13 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Error in Slew : CheckDotNetExceptions ASCOM.GeminiTelescope.Telescope SlewToCoordinates System.Exception: Slew to outside of safety limits (See Inner Exception for details) (System.Exception: Slew to outside of safety limits) at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 630 at ASCOM.DriverAccess.MemberFactory.MethodTargetInvocationExceptionHandler(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 678 at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 487 at ASCOM.DriverAccess.Telescope.SlewToCoordinates(Double RightAscension, Double Declination) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1030 at ah.Slew(TelescopeInformation tp)

No indication of loss of communication with PHD2. Just clouds and the mount safety limit problem.

Andy

4

Thanks Andy and Peter for the replies. Peter, I’ll check to see which version of the driver I’ve got but I’m pretty sure it’s the newest one since this is on a new computer.

Andy, I would have guessed intermittent clouds as well but these last two nights have been the clearest and driest nights of the year for me. Tell me if this makes sense: something (clouds?) sent SGP into recovery mode some time before a meridian flip became necessary. Because SGP was in recovery mode the flip did not happen and the mount reached the safety limits. Is that expected behavior, or should the flip have happened?

5

Flips will not happen in recovery mode. This is why 2.4.2 will quit when 90 minutes is up OR when the flip should have occurred. This is expected behavior. We figure why try to attempt a flip when SGPro is in an unknown state (might be dangerous)?

6

Thanks for confirming that Ken. Makes sense.

Something is up with my Gemini G11 location info and time zone. I am away from home and in a different time zone. Although I set up the Gemini Ascom location info and time zone ahead of time, the location didn’t “stick” with Gemini and I didn’t realize it. So after a solve and sync the mount may have been synced with the sky but the time zone was off. So I think what’s been happening is that the mount is tracking long past when the meridian flip should have occurred, reached the mount limit and of course that will create havoc with SGP and PHD.

Does that make sense?

7

Yes, that would explain it.

Andy