Frequent hangs during download with SBIG CCD


#1

Hi, everybody. I looked around the forums for others having my problems and although there were some tantalizing near misses there didn’t quite seem to be an ideal match.

I’m working with SGP 2.4.1.10 and have been having a tough time with hangs during download using Windows 8.1 and an SBIG STL-11000M.

The symptom is typically that the lower leftmost downloading progress bar stops repainting, typically in the fully filled in with green state. The camera, once the above has happened doesn’t respond to disconnect attempts when I try to toggle its connection status in the connect equipment section of the sequence window.

If I look in the logs I almost always see the message “SBIG read compete. Took XXXXms” where the XXXX is a duration that’s entirely plausible for the binning setting I’m using.

If I close SGP and connect to the camera with SBIG’s CCDops I can get it to expose and download again. if I then restart SGP, disconnect CCDops, and reconnect SGP, I can usually take a few images before it happens again.

Sometimes other messages will appear in SGP’s log long after the download that appears to have completed in the log, but that left parts of the UI paralyzed and didn’t ever display an image. An example is “[TEC Thread] TEC Change: Complete”. Such messages often appear long after the partial hang incident though which makes me think they’re unconnected and they’re just other threads within SGP going about their business.

Any suggestions on what I should be doing differently, experiments I should perform or log files I could present?


#2

Not entirely sure. None of other SBIG 11000 users have complained of anything like this. Seeing the logs might help. Also understanding how you connect your camera to the machine might help. Are you using the onboard guider or remote guide head?


#3

Hi, Ken… Actually I’m using an external guide scope and camera because at my focal length finding guide stars for the built in guider can be fussy… But I think I may have thrown out a total red herring in my initial problem report.

On a lark I tried doing a bunch of snaps without my mount connected… Unexpectedly, doing the exposures without the mount seemed to make things more reliable.

I’d been using ASCOM POTH to multiplex SGP, PHD2 and sometimes The Sky X into the ASCOM Celestron Mount Server, so I decided to try pulling the POTH piece of the mess out and pointing both SGP and PHD2 directly at the Celestron Mount Server. It’s never been abundantly clear to me just what the concurrency semantics of these things working together are supposed to be and I’d fallen into the habit of using POTH with other software and one of my other mounts in the past. With POTH removed things seemed to get much more reliable!

I’m going to let SGP try a 12 frame guided sequence now and see if it can complete without getting upset. SGP got through centering and plate solving, and an autofocus run without difficulty and the first four sequence frames have downloaded happily so things are looking good so far.

Knock on wood. Maybe having POTH in the mix was the problem.

I’ll update this thread with my findings tomorrow. Weather looks promising for the next little while so with a bit of luck I’ll get some solid nights outside to finish chasing my problems down.


#4

I would like to chime in and report this has happen a few times with my ST-2000XM. Also it happened with my Nikon D5100 last night. Below is a link to my SGP log file. I am running 2.4.1.10 also. Looking at my Windows Event Log I see a Application Hang error. I typical have to end the process for SGP at this point. I am running Windows 7 x64. I should note that I tested the Nikon with another Astro capture software afterward and had no issues.


#5

Actually, after reading through a few more threads researching this, I found that my Nikon download hang issue should be resolved by disabling image history:


#6

I had this problem with my Atik 383L when testing long runs of USB cable. I can get 3m runs of cable to work (with a powered USB hub), but if I go to a 5m cable, then the camera will often fail to download the image.

In my case, I think it is a USB limitation. I don’t know if any of that applies to your situation.


#7

I’ve been having the same problem using an STF8300M. I’m using a powered USB2 hub, at the mount, with a run of a 36’ boosted USB cable to the laptop (in the shed). It, generally, takes me 2.5-3 minutes to download an image. Using Maxim Dl 6, or CCDOps, it generally takes 8 seconds for a download. I’ve tried using new USB hubs with the same problem and a spare boosted USB cable. Another user, on the SBIG forum, suggested using an Icron Ranger USB (4 port) over Cat5e. I have one on order, so hopefully it will help. Still can’t figure why I’m only having trouble with SGP for the length of download time. However, I’ve been also having “Camera Error 8” errors (RX_timeout) on Maxim Dl, on occasion.


#8

This may not apply to your situation but my SBIG download hangs vanished entirely when I started connecting SGP directly to my Celestron mount driver and Moonlite focuser/rotator drivers via ASCOM. Prior to that I’d connected the mount and focuser/rotator to POTH and then connected SGP to POTH.

Once I took POTH out of the equation my troubles vanished entirely. It’s not clear to me why camera downloads, which POTH never had its paws on, would have been related, but the moment I stopped using POTH in such a manner, the problem disappeared.

I wonder if perhaps something got racy between POTH and either the Celestron or Moonlite ASCOM server apps, and this backed up the line into confusing SGP.


#9

After getting an Icron Ranger hub it still hung up. Last resort was to re-format the computer, wipe it clean, and reload. That fixed it. SGP is now downloading in less than 8 secs. I figure it was corrupted driver(s).


#10

Glad you got it solved. It would be nice if there was an easier way to verify such problems under Windows short of repaving the entire machine, a not inconsiderably time consuming process…


www.mainsequencesoftware.com