Hi
My HEQ5 mount regularly disconnects from SGPro. This happens all of the time, the frequency changes, but certainly a few times during a typical astrophotography session. The mount is still tracking, and if I reconnect, then immediately hit the sidereal button, I can carry on.
I can’t, however rely on the link meaning that I can’t rely on SGPro to change targets, so I can’t set up to image all night, or to do a mosaic.
I have just completed an extentsive week of testing with APT (Astro Photography Tool), and during that week of 12-14 hour sessions, APT did not drop out once.
This implies to me that it’s maybe to do with protocols used, or perhaps timeouts and retries of the process…obviously the ascom and EQMOD settings should be the same for both.
I need to use SGPro, APT doesn’t have the facilities I need !!! HELP !!!
It is likely that APT is just not checking the connected state and therefore unlikely to expose something like this. We are checking the connected status fairly frequently. The check is pretty minimal, we’re literally just asking the ASCOM driver “IsConnected?” and it is returning “False”. For the most part APT’s interaction with the telescope is pretty limited. You’d probably get a better idea of things using something like Stellarium which is frequently polling the telescope.
Jared,
Thank you, that makes some sense. I haven’t really looked at the log files before. When is a new log file created? If I know the rules I can really try and target it down next time I get a failure.
Is there anyway in SGPro I can influence the connection check behaviour (i.e to try and fix it) by changing retries, timeout or baud rate.
Really appreciate your help, I’m desperate to keep running SGP !
Hi Jared,
You mention Stellarium. Haven’t done that yet, and will try, but for your information Cartes De Ciel doesn’t disconnect either. Is that similar to Stellarium?
OK Jared, I just had a failure… THIS IS IN MY DROPBOX FOLDER as BAD_ONExxxxx.log
I got this in the log…
[05/20/20 22:25:20.492][DEBUG][TEC Thread][NONE] SGM_CHANGE_COOLER_TEMP complete…
[05/20/20 22:26:46.684][DEBUG][Telescope Thread][NONE] Telescope Dispatch loop: Received SGM_TELESCOPE_CONNECT…
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] Failed to connect to telescope. : Object reference not set to an instance of an object.
at ASCOM.DriverAccess.MemberFactory.SetTargetInvocationExceptionHandler(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 636
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 373
at ASCOM.DriverAccess.AscomDriver.set_Connected(Boolean value) in C:\ASCOM Build\Export\ASCOM.DriverAccess\AscomDriver.cs:line 144
at r6.j5()
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] SGM_TELESCOPE_CONNECT complete…
[05/20/20 22:26:50.179][DEBUG][Telescope Thread][NONE] Telescope thread is IDLE…
[05/20/20 22:26:57.087][DEBUG][CP Update Thread][NONE] Error in control panel UI updater: Object reference not set to an instance of an object.
[05/20/20 22:27:07.166][DEBUG][CP Update Thread][NONE] Error in control panel UI updater: Object reference not set to an instance of an object.
Hi,
Later on I had another similar failure. This is the dropbox folder as BAD TWO xxxx.log.
It looks to me like an unhandled exception. If you want me to do any specific tests, or run any special diagnostic code, I’d be very happy to do so, I used to be a software developer…
[05/21/20 01:35:08.959][DEBUG][Telescope Thread][NONE] Telescope Dispatch loop: Received SGM_TELESCOPE_CONNECT…
[05/21/20 01:35:13.892][DEBUG][Telescope Thread][NONE] Failed to connect to telescope. : The callee (server [not server application]) is not available and disappeared; all connections are invalid. The call may have executed. (Exception from HRESULT: 0x80010007 (RPC_E_SERVER_DIED))
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 266
at ASCOM.DriverAccess.AscomDriver.get_Connected() in C:\ASCOM Build\Export\ASCOM.DriverAccess\AscomDriver.cs:line 131
at r6.j5()
[05/21/20 01:35:13.892][DEBUG][Telescope Thread][NONE] SGM_TELESCOPE_CONNECT complete…
Sadly I don’t have a great answer for you. It seems the possible solutions are:
1 - SGP stops checking if the devices are connected.
2 - Stop the device from stating it is disconnected (when maybe it’s not?)
Do you happen to have an ASCOM log from the telescope that corresponds to one of those SGP logs?
I’m not sure if those logs match up or not. But they seem to be an hour off (maybe DST error?). Regardless something does seem up a little higher in the log:
That RX timeout certainly seems suspect. Maybe a USB or driver problem? I’m not sure. But it seems that the driver is dropping communication with the mount occasionally.
I’m not sure of all of the software layers involved here.
1)Does SGPro talk to Ascom, which then talks to the mount? … and that this timeut is the Ascom driver not getting a response from the mount.
I did try on a completely seperate computer and got the same disconnect issue. I also tried swapping the USB PC to mount lead, again to no avail.
2)Is that then implying that it could be the mount itself? The mount was damaged, but the electronics were changed twice, and I had he same problem after each repair. I DID NOT have the problem before the mount blew up though. I’m going to try and borrow another ascom mount to see if that has the issue. Won’t be an HEQ5 though.