Hi-
I’ve only been using SGP for about 2 months (maybe 20 hours total imaging time). While I have had several successful imaging sessions start to finish, I have had four sessions that were interrupted by what I would assume to be a crash. In three of those cases, when I checked the computer, a blue screen was being displayed indicating that “Windows didn’t load correctly” with options to Restart or Repair. (I have provided a link to a photo I took of the screen as I was unable to capture a screen shot in the usual way: http://astrobytes.net/restart.jpg). On another occasion, SGP appeared to be completely locked up or frozen. I was unable to close the program by any normal means and could not close the program by ending the program in Task Manager. I finally ended up rebooting the computer to restore normal operation. I’ve attached the file logs from the sessions when I had problems and it seems that the problem is occurring when the auto focus routine is running although I can’t say for sure if that is always the case.
The PC running SGP is a new Dell laptop and I am running a QSI 8300, Lodestar guider, Meade Lx-200GPS mount (through ASCOM POTH), Robofocus, SkyAlert for weather control and SkyRoof for roof control. I’ve run MemTest and scandisk on the PC and it all comes back good. Because it is a new computer, I have installed all of the latest device drivers for the cameras, mount etc. and have the latest version of ASCOM installed. The PC is running Windows 10 Home and is up to date. FWIW, the last time the problem occurred, I switched back over to Maxim DL and finished the session with no issues so I don’t think it is a hardware issue. I am at a loss on what to do to correct the problem. I suppose I could try imaging without using the Autofocus feature but the problem is so random it might take a long time to confirm if that is the issue. I would appreciate any hints or suggestions on the matter.
Not really seeing anything in those logs that would lead me to suspect something with SGP crashed. You may need to look through your system logs and see if anything is in there that points you to something being problematic.
In an effort to try to narrow down the problem, I ran several tests. In the first test, I disconnected all equipment from SGP except for the camera and started running continuous 60 second frames. After about an hour, the program froze up and as before, I was unable to close it by any means other than rebooting the computer. In the next test, I disconnected all USB devices from the computer and connected the camera directly to the computer with the QSI factory supplied USB cable. Again, I ran 60 second continuous frames and it froze up again, this time with the blue screen (which I am beginning to think is the Win 10 version of the bsod). Finally, I resorted to swapping out computers. I “borrowed” my wife’s Windows 7 laptop, loaded up the necessary software and repeated the test. It ran for an entire afternoon without any issue. I setup the Win 7 computer to do some imaging and everything worked great for two nights but on the third night I had a problem. Midway through the imaging session, SGP froze up again. This time I was able to get a little more debugging information than I was able to get on the Windows 10 machine. I’ve posted a screen capture of SGP when it froze, the crash report, dump files and the SGP log file on my website. I’m not sure what other kind of troubleshooting I can do at this point (I don’t have another camera to try).
If the problem is Windows update can it be set to run at a different time? Local noon for example. The default is the middle of the night but AIUI it can be changed. For a working astronomer setting a time when you are at work or asleep (possibly both) may be preferable.
If not an issue with Windows 10 updates or laptop overheating (good places to start), then perhaps it is maxing out computer resources. There’s a lot going on during autofocus - frequent imaging downloads, ongoing guiding and pause/start guiding requests etc. This can overwhelm communication channels, specifically usb.
How much memory does the laptop have? Which cpu? What are you using for usb cables/usb hub (powered/unpowered etc.)? Just throwing out some ideas …
@dnube-Thanks for the tips. Maybe our posts crossed, but as I mentioned, I have already tried swapping out the (brand new) Windows 10 computer with a Windows 7 laptop (updates are turned off). Even with nothing else connected to the computer aside from the QSI camera, the computer connected directly to the camera with the factory supplied QSI USB cable and no other programs running, (no guiding or anything else, just taking simple subs) the problem continues to manifest itself. Either computer should have more than enough resources to run the observatory. The new Dell is an i5 proc running at 2.5ghz with 8gb RAM and a 256 gig ssd. The Win 7 machine has an i3 proc@1.8ghz and 4gb of RAM. It also has an ssd hard drive. FWIW, I have been running my observatory on the Win 7 machine with MaximDL (and the same gear) for the last 5 years or so and have never had this kind of problem before. Unfortunately, the problem is very sporadic which makes troubleshooting difficult. For example, I ran imaging sessions on Monday night and Tuesday night without any hiccups. On Wednesday night, SGP locked up midway through the third sub in the same way it has before. It seems that the crashing problem might be less frequent (and less catastrophic) on the Win 7 computer for whatever reason. At this point, I don’t know what else I can do or try in order to nail down the problem.
Here are the error files and a screenshot from Wednesday night.
@Wes
Sorry to hear you are still having problems. Sporadic problems are the worst.
Perhaps someone else here who is better at reading logs than I, will pipe up with some suggestions.
If it were me at this point (given that I have a lot of mistrust and bad experience with usb, and given that you have potentially eliminated the PC as root cause), I would:
Try swapping out the QSI factory supplied cable with a different cable
Having a closer look at your other usb devices and hubs/cables - try swapping. Also need to consider there could be multiple issues at play. Are you using a usb hub? If so what make/model? Usb 2 or 3 cables?
When you did the “isolated” QSI testing (ie. no other devices connected) how long were the subs? If short, perhaps try longer subs to see if it makes a difference (help narrow down the problem at least)
Does your QSI camera have any logging?
I presume you have checked for newer version of drivers (camera, mount etc.) and applications (ie. ASCOM, PHD etc.)?
Maybe someone else here with similar equipment/combination can advise if they have ever had similar issues before?
Just throwing out some ideas … wish I could suggest something more concrete.
Sorry for the late comments on this problem. After a lot of testing, it turned out that the problem was apparently being caused by the focuser driver I was using. My system is currently using a Robofocus focuser. There are two Robofocus drivers that can be downloaded from the ASCOM web site. One (v 3.09) is the basic driver which is what I was using. I ended up installing the other version which is the complete Robofocus Control program with driver and I haven’t had any lock up or reboot incidents since doing this. What is most interesting about the problem is that the focuser always worked correctly with the ‘Basic’ driver and the system malfunctions would occur regardless of the fact that the autofocus routine was turned off and not being used. Strange.
