In that run it happened at 11:25pm. When I went out to check on the scope after noticing this, it had not parked itself. Maybe I got there before that would have happened? Or would it have stayed unparked? This came up last year, and as far as I know there was no solution for it - it just went away after a while, so I stopped worrying about it:
Thanks for looking at this, Ken. It didn’t pull a cord out, but I’m not sure what happened. For right now, I’ll just wait and see if it comes up again. I’ve had two sessions since this without a problem, so crossing my fingers seems the best strategy for now.
It happened three more times tonight, and I think I have some clues about what’s happening. This seems to happen only during platesolve (though in the past I’ve also seen it happen during frame and focus mode). And it only happens on the second platesolve image - ie, after the slew is finished. This never happens while imaging a target, only during platesolves. No cables are being pulled out; the camera simply stops during the download phase, and SGP appears to lose the connection to it, as the temperature stops reporting (it reads “NA”). I have to close SGP, restart it, and reconnect the camera (all via software - hardware plugging seems unnecessary).
Also, PHD2 appears to lose its own connection to the guide cam at the same time, because it reports “camera disconnected” and I also have to reconnect it. I’ve seen the PHD2 aspect of this at least three times, and maybe more before I really clued into it. Does any of that help? Three logs from tonight’s sessions, each of which should show the camera hang at the end, are here:
Ken, you mentioned the ASCOM camera logs. If you have any idea where I’d find those - or if I have to turn logging on - please let me know and I’ll pass along whatever I can find. I’m using Bret’s SX-ASCOM driver.
I looked through those logs and, unfortunately, they are just like the first. Something happens with the camera and then it starts emitting error after error until SGPro is terminated.
Is that the preferred one for SX cameras over the one’s provided here?
You will almost certainly need to turn it on… usually in the setting dialog, sometimes called “Trace”. As for where they can found that is ultimately up to the driver’s author, but usually here:
C:\Users\user name\Documents\ASCOM
We definitely need them to understand what is happening.
Thanks Ken. I’ll turn on the camera log. As far as the driver, my understanding is that SX’s in-house drivers aren’t ASCOM compliant - that’s why they link to Bret’s ASCOM driver. I started using the ASCOM driver years ago because I understood that you and Jared hadn’t been able to get an SX camera from Terry to test out your own connection. Has that changed?
Not really. The bottom line around this stuff is that we can usually get cameras as loaners to test initial implementations then we send them back. Not really a great method in place for debugging.
We have bunches of SX CCD users, so I don’t think this is likely a problem with the camera software itself, but likely some (possibly unique to you) combination of things.
Maybe start by removing / replacing / testing as many variables as you can… hubs, power supplies, USB cables, USB buses, etc.
An ASCOM driver is normally just a wrapper over the native drivers used to adapt to ASCOM standards. In terms of native drivers, are you using 1.3.7.2?
Just throwing my uneducated experience in here…
I used an SX-694 for a long time and I had these sorts of problems with the native SX camera driver 1.3.7.2. I went back to 1.2.2.0 and the connection was much more stable. Again, just my experience and I don’t know if this is a good or advisable solution for you, but try going back to 1.2.2.0.
I can say the same thing as Joel. I had several disconnects with SX Lodestar using SX driver 1.3.7.2 and reverting back to SX version 1.2.2.0 seemed to fix frequent disconnects. This was autoguiding with PHD2 and I can imagine the same applies to using other capture software including SGP.