Hi
I am a fairly new user of SGP and have had no problem operating my QHY cameras with it. However, I wanted to connect my STT8300, and it won’t connect. I did go back and look for prior info but nothing current enough to address my issue.
Running Windows 10 with SGP 4.0.0.700, current SBIG drivers loaded (camera connects just fine with CCDOps, MaximDL).
In Settings I have Connection Type USB and Guide Chip Internal (self-guiding filter wheel).
I click connect, and get the following dialog: SBIG Error While Opening COMMAND_ERR
When I clear that I get Error Connecting to SBIG Camera.
I know it has to be something I am overlooking as I am sure people are using tons of SBIG cameras with SGP. Can someone help an old man out?
I am certainly no expert but I have been using SGP for some time with my STT8300. However, my settings for Guide Chip are “remote guide head”. Try that.
Thank you for your reply. Unfortunately that did not work. I changed the guide chip to None as well and all combinations gave the same error dialog. It has to be something simple… a dll in a wrong directory - something like that.
I just did a search and found a note that said “SBIG does not support 64 bit drivers - use 32 bit”. That confused me I must confess, as a couple years ago SBIG updated all their drivers to 64 bit, and that is what I am running on my camera (SBIGDriverChecker64). I am also running 64 bit QHY drivers for my two QHY cameras, and I am running SGP 64, so everything is (seems to be?) 64 bit. It is only the SBIG camera that will not connect.
Also that article referenced did not indicate which should be running 32 bit - the camera driver or the version of SGP, nor did it give any hint on how to make changes to do so.
I would not be surprised if SBIGDRiverCheck64 put drivers in the wrong folders… LOL
I “think” the SBIGDriverChecker64 application is 64-bit, but it only refers to the software that installs the drivers. All the legacy SBIG drivers themselves are 32-bit (I think)
In the DriverChecker64 system files, I find a 64 bit folder and a 32 bit folder. There appear to be 64 bit drivers present. I went to the DiffractionLimited help forum, and found an article about using 32 bit drivers for “legacy” cameras (ST7, 8, 9, 10) for SGP, but NOT to use them for the STL, STT series. But nothing more. I can’t help but feel there is a DLL in the “wrong” folder, and if I knew which one it was I could fix this puppy…
Thank you for the suggestion. I downloaded the 32 bit version of SGP and tried that. It did not work, but this time I got a different error: SBIG Error While querying CCD Info: RX_TIMEOUT
Just to make sure… SBIG has released an ASCOM driver but I think it only works for their new cameras. In the camera list where you choose the camera, there is only 1 option for SBIG right?
I verified I have the current firmware on the camera, and am using all the current drivers. I installed SGP 32bit and initially it did not work. I suspected that it couldn’t find the sbigudrv.dll 32bit so I moved a copy of that driver into the same folder as my Nikon drivers. I rebooted the laptop and lo and behold it now works - mounting both the camera and the filter wheel. That was a bench test only - have to wait for a clear night to see if I can actually image LOL.
Furthermore, there is in fact a 64 bit driver for the STT camera, but it has to be installed manually. I did that and was able to mount both the camera and filter wheel in SGP 64 bit. Caveat: I do not know if it is actually using the 64 bit driver or the 32 bit driver I manually put in the folder.
So for now it looks like my problem is solved, pending actually imaging with the camera. Thank you all for your help and patience, much appreciated.
Oh - and Ken - yes - only one instance of SBIG in the camera list!
I am unsure why it became necessary to do that. The SBIG driver installer should automatically modify your PATH environment variable so that apps like SGPro can find it and use it. Having to move it in manually means that the SBIG driver is not in a place pointed to aby a folder within PATH. Maybe there is an option to modify the PATH variable during install and it was skipped? Unsure how CCDOps or Maxim operate… they might distribute that DLL with their software.
The DriverChecker64 app to update and install SBIG drivers is pretty basic. It really has no options. I verified I had the current version of the updater and I verified it installed the latest drivers. I do know that both CCDOps and MaximDL worked without me having to do anything. I recently went with SGP Pro because I wanted to be able to automate my imaging sessions (I like sleeping at night these days!), and that has been working just fine with my QHY cameras.
I have the same problem with my SBIG STF 8300 which prevents use of that version. I also am having problems with the ZWO drivers particularly on my ZWO 294C, where downloads after long exposures hand up.
I have been fighting with the same problem but with one difference - I am 800 miles away from my kit.
I have been using my STT8300 for some years and had to re-install the drivers when I moved to remote hosting whilst also moving from Win 7 to Win 10. I also changed my remote PC to Win10/64.
At that point connection was luck of the draw. I installed remote power switching and remote USB switching but this did not solve the problem.
I then asked the host support guy to restart the remote PC then physically un-plug and re-plug the USB cable and then the power to the camera. This worked and I have done many hours of successful imaging with the STT, but always never knowing when this procedure was going to work at switch-on.
I love my STT8300 but I am now considering retiring it for a camera with new and proven drivers for Win10/64.
Jan
I think you will be OK with your STT8300 - from what I can tell the SBIG driver was not where SGP expected it to be, so I moved the SBIG driver to the folder I mentioned above. But I understand your concern… every time I upgrade/update something I panic, wondering if everything will still work. Windows 10 is really bad with its auto updates - I have started off many evenings with things not working, only to discover Win10 downloaded something and was waiting for it to be installed. I have a Win7 laptop I absolutely refuse to upgrade because I know it is stable. Likewise, I will not go to Win11.