I’ve been imaging with Sequence Generator Pro for awhile now with tons of success. All of the sudden, however, two nights ago, I started having a problem where the image download fails randomly. This is happening both in Auto Focus and during normal imaging. I’m using a QSI 683wsg-8 and am receiving the following error:
“ASCOM (QSI) Camera: Error in GetCoolerTemp. : Camera Error at QSICamLib.CCDCameraClass.get_CCDTemperature()”.
Also, the next line reads: “ASCOM (QSI) Camera Capture. : Cannot Start Exposure at QSICameraLib.CCDCameraClass.StartExposure(Double Duration, Boolean Light) at pt.eu(cs A_0, hd& A_1)”.
I tried reinstalling SGP and the QSI drivers, with no luck. I’ll try a new cable and new computer tonight to see if that is the issue, but I wanted to ask here to see if this is a problem anyone else has seen.
Thanks for the response! I haven’t tried anything else yet (only several different versions of SGP). My next diagnostic step is to try a new cable and a different computer to rule out the cabling and/or the USB bus on the machine.
Nothing changed (which is the weird part). The scope was setup one night, covered during the day and restarted again the next night without any config change…it worked perfectly (as usual) the first night, then started giving me trouble the second night.
I’m going to give these things a try and see if it gets any better…I’ll update once I know more.
I use a usb hub and whenever I’ve had any problems it’s always been a usb lead or the hub. And the first sign of trouble is the camera temp not being reported in sgp - this is with my qsi 683.
So if you can try a different usb port on your computer or different lead I think you’ll be sorted…
My friend and I both have QSI 683’s and experienced random issues. I changed over to a StarTech Industrial USB2 hub and my problems went away. I lent one to him and his did too. These are in metal boxes, have 12V feed and I’m pretty sure use the preferred NEC chipset.
Thanks, all, for the comments here. It does appear it was a USB cable issue…traded out the USB and the problems went away! WOOT!
@Kit, good to know about the temp not being reported in SGP. That was the first thing I actually saw, but then it fixed itself, so I wrote it off as gremlins in the software :)…turns out, that was probably the first sign of impending doom.
Everything appears back to normal now regarding this issue. Thanks!
I did a search on “Sequence Generator Pro QSI camera error” and came across this thread. I experienced a couple of nights of excessive errors with my camera, lost connections, etc. As suggested here, it turned out to be the USB cable. Swapped it out, and now it works fine. Moral of the story: don’t curse the software or drivers until you’ve eliminated simple hardware as the issue.
Good advice. It took me quite awhile to figure out that it usually isn’t SGP :). I was also surprised how often things like cables, hubs, power supplies, etc, can fail in ‘industrial’ gear like we use night after night. It’s nuts!
I always keep a couple USB cables around now just in case. Startech has been good to be for powered hubs (the industrial 12V model).
I recently swapped up my setup so that the computer is now resting on the telescope via a D-plate so there should be less movement with the cables (only a power cord going to it now). We’ll see how that works when I get the new obs up.
Also, personal pet peeve, if you fix it, post how you fixed it! So many of these threads just trail off and I assume people got their equipment working. It helps people who do searches know what ultimately fixed your particular issue.
So, the plot thickens in this behavior for me. I switched out the cable and, initially, it appeared that everything was working correctly. However, a couple of nights later, I experienced a similar issue, receiving the same error message in the SGP log. It seems to be independent of what is happening in SGP and completely random (normal imaging, Auto Focus, or Plate Solving). The dangerous thing is that, if it occurs during Auto Focus, it winds up aborting the exposure, but AF hangs trying to solve the un-downloaded image. This makes the sequence hold, but GNS won’t alert me because it thinks AF is still running. This can cause the mount to track into the pier if it occurs before the pier flip. Regardless, I’ve tried two new USB cables with no success…it seems to work, but then fails later (my latest run had two nights of successful imaging, follow by a failure during AF last night). My new leading theory may be the computer itself (the computer has seen better days and is over 6 years old). I’m going to try switching to a new computer tonight to see if this solves my problem. If not, I’ll have to start exploring camera/SGP issues. If anyone has any other ideas, I’d love to hear them. I’ll keep you all updated.
Well, preliminary tests aren’t very hopeful. I connected to the new computer and the same behavior occurred. When taking a frame and focus frame, the camera briefly reported temperature as “NA” and then the exposure failed. On the plus side, SGP appears to have appropriately aborted the exposure this time, rather than having it hang up. We’ll see how the sequence runs tonight and I’ll report tomorrow. Right now, however, it looks like it is either an SGP issue in how it is communicating with the camera or a camera problem. Any ideas would be greatly appreciated. I’m not convinced this is a new issue…I used to run into problems with the first exposure (my blind solve) not downloading. But, I would simply abort and reissue it and it would work. I never thought to check the logs to see what happened. Only recently, however, has this become a problem where the downloads are failing elsewhere in the sequence. If SGP handles it appropriately and aborts the exposure and either quits the sequence or wakes me up with GNS, it isn’t a problem (or, at least, it is workable)…the big danger I have now is that, because my AP mount has the older Q chip, I cannot use APCC and, thus, cannot impose meridian limits. As such, the scope can track into the mount if the exposure fails and hangs up SGP.
Here is what I use to solve the problem of my AP mount not having built-in safety limits (something I really miss about my G11-G2): Mount Watcher .
The app stops the tracking if the mount tracks too far past the meridian. As an extra precaution, an Arduino cuts the power to the mount if the app is unavailable (like if the PC were to crash.) This solution will work with your Q chip. The app is free and you are welcome to use it. The (optional) Arduino watchdog will cost about $20-25 to put together.
@Andy THANK YOU SO MUCH! You have restored my ability to sleep! I’ll be downloading this app and implementing it tonight. I’ll still have to work the camera download failure issue, but this will, at least, allow me to get through a night without concern my scope will crash. Thanks!
Final Update: It appears the culprit was actually my power to the camera. I’ve been running 12 VDC, but it appears the cable is giving me some trouble. I switched to AC power and this problem has disappeared entirely. I now have had 5 nights of imaging without any sign of this issue.
So many of these threads just trail off and I assume people got their equipment working. It helps people who do searches know what ultimately fixed your particular issue.