Last night ran into an issue that has never happened to me before. I was imaging M27 and was scheduled to run throughout the night, including a meridian flip around 2am. Started imaging around 11PM. around 1:40 i woke up to check on the mount and found it had parked and SGP was stuck on “Image Downloading” with the green bar showing. PHD2 equipment was disconnected, I assumed this was because SGP must had went into some kind or recovery mode and after some period of time because of the image down loading being stuck parked the scope and went through its shutdown routine.
What is very strange up until that point it captured over 30 images in the sequence without any issue before this “Image Downloading” occurred. Also I had the sequence set to take bias and dark frames but that didn’t happen either. So what I did was simply unchecked the image sequence and keep the dark and bias checked and restarted the sequence to get my bias and dark frames and SGP started taking the Darks just like nothing has ever happen just like is was suppose to do.
If the image download gets stuck,can SGP be program to say after some period of time, maybe a minute, if the image has not download within that period of time to simply forget that image and begin with a new? and not trigger a recovery or shutdown? Maybe after three attempts and each of the next three the same error occur then go into recovering and/or shutdown/recovery mode?
Seems to me that what happened last night maybe was a glitch and would be nice if a glitch like this would not shutdown the sequence.
I have had this experience multiple times such that I never leave an imaging session overnight - I much prefer to monitor from indoors. I suspect that it happens if the download has a (temporary?) problem with the USB cable. When it does happen it is unrecoverable. I have to reboot the entire laptop and adjust the program to carry on from where it left off. I recall reporting this more than a year ago. The s/w needs to recognise the problem and forcibly abort the image and attempt to recover - not simply stick on the error message ad infinitum.
I have had download issues before with latest SX ASCOM driver (H18, Lodestars and Superstar) with both imaging and guiding applications. I rolled back a few versions and I had better luck (or used an application driver). I’ll have to wait until I return home to check up on my notes.
As much as I like SGP, I have had the hang on download issue so many times I am beginning to consider switching to another platform. There are plenty of threads on this, and not one definitive fix I can find. The common suggestions are to roll back software version (shouldn’t have to), check USB cable (cables don’t fail at the rate this issue is reported), lower USB download speed (shouldn’t have to), and reboot computer (shouldn’t have to and takes too much time to get back to where you were). I walked away from the first clear night, tonight, I have had in two months, shaking my head, because even after multiple restarts, I couldn’t get one frame to download after the issue started. It was working fine for about an hour, then haywire.
SGP team, this has been called out as an issue for years; please help us. Imaging nights are rare for some of us and having to walk away because you can’t get an image to download is frustrating.
As frustrating as this issue is, it is not likely a SGP issue. If you look at the ASCOM drivers for cameras, it is pretty simple. SGP starts an exposure and waits for the camera to finish. Part of the issue with ASCOM drivers is they are DLL’s that run in the SGP space. If the driver misbehaves, it can easily take SGP down with it. As I recall, SGP can timeout if the camera fails to finish, however, that can fail it the camera driver has screwed up SGP internally. So it is likely there is not one common cause for this issue but various problems depending the ASCOM driver that all manifest themselves as a failure to complete. So when you report this issue be sure the specific ASCOM driver and version you are using to see if a pattern an be identified.
Hi
As said before many reports have been made before about this and after many hours off looking into this with sx cameras and their as ascom man ( Mr Bret ) It seems that the data flow from the camera to the computer is getting interrupted causing the usb to crash .
I have always known that other software have minimised the amount off USB traffic during download I.E the camera should be asked nothing during this time and even traffic to other devices should be as little as poss as well , I do not know in depth if SGP is trying its best on this !
But as a start make sure that your guide camera is paused during image download ( IMO should be default )and try and keep the imaging camera on a single USB2 port if possible , definitely do not mix with a usb 3 port / device ( unless its a usb3 camera off course ).
there will be a new ascom driver for the H18 - 46 and 56 shortly , but do not think it will offer anything new for any other sx cameras and the ascom driver can do little to stop usb crashes
Thank you for those who weighed in on my frustration and help try to solve the problem.
I do have to push back some though. I’ve only gotten serious about AP in the last 18 months or so, but I’ve done it casually for about 15 years. So I do understand the balance that has to be achieved from a lot of different platforms working together. I also understand SGP, like everything else, is subject to interactions with other software. However, I still firmly believe the error handling could be more robust. Not once have I ever had to restart my computer because of a PHD2 failure, or a CdC failure. Furthermore, it isn’t as if I am changing things night-over-night. I am fortunate enough to have a permanent observatory, with a freshly built and dedicated computer, new cables all properly secured, etc., and yet one night it will run just fine, the next night SGP hangs continuously. At the very least I would think there could be a kill protocol which would kick the routine out of whatever is hanging it, without having to restart the software or computer, and therefore have to re-cool the camera, reconnect guiding, re-plate solve, etc., and end up losing 10 - 15 minutes of precious imaging time.
My frustration is likely causing me to be harsher than I normally would, but there are countless threads on this exact topic, for years now. If my car or kitchen stove only worked 90% of the time, after I tried reasonable fixes, I would get rid of it in a heartbeat. Why should this be different just because it is hobby software?
I was the original poster on this thread. I’ve only every had this stuck on image download happen once. But I do read and see where others have had it happen many times over. My comment was and is still the same, maybe after some period of time if SGP could not “simply” exit the download and do a do over?
I would like to comment on para 3 above - re guide camera pausing during image download. This is not happening with my setup. I was disturbed to see the guiding continue, with SGP (or was it PHD2) reporting that the guide camera couldn’t be stopped during download - which cannot be correct.
Keeping the main camera on its own USB port is possible for me; currently I use both cameras plugged into a USB3 hub (and then into a single USB2 laptop connection. Is this really essential? I had assumed that the controlling software would know when to instruct the cameras to download etc.
When using SX cameras this used to happen to me if I used the Ascom driver for both the main as well as the guide camera. I managed to resolve it by using the native SX driver in PHD2 instead of the Ascom one.
@mahaffm SGP does not know how to reliably stop and restart the camera. The ASCOM interface does not provide guidance about what happens if the camera fails. SPG can only guess what series of steps might clear the camera. I think SGP can detect a timeout situation in some cases but if the driver has gone off into the weeds all bets are off.
Hi
I presume you have the " pause guider box checked " in guider options , as for usb3 its been known for it not to get its timing right with usb2 devices and off course the max cable lenth with usb3 is only 3m , I struggle with the 5m on usb2 , I have switched it off on my laptop as well
As soon as I switched to USB3 cameras (Canon 7D Mark II first, then QHY163M) I experienced image download issues and not only with SGP/Windows (KStars on MacOS too). At first, I refused to consider a hardware issue and I blamed drivers/applications too. And I agree that those recommendation (one in particular, reboot the PC) can be overly simplistic.
Nonetheless, it turned out that my issues were to be found in places where I never thought to look at and they were not due to SGP or ASCOM drivers. It took me a couple of months reading the logs to track the problem.
To connect to my Orion Atlas I used a EQDirect Bluetooth dongle to save one USB port on my unpowered hub (which hosted the QHY163M, an Orion SSAG, a USB-focus v3 and the PoleMaster). It turned out that a misbehaving communication with the mount (serial over Bluetooth) caused EQMod to hang temporarily, which caused PHD2 (guiding through EQmod) to temporarily freeze. If that happened during an image download … R.I.P. SGP
Later, I switched to a cabled connection to the mount and changed the hub with a powered one (having 1A for ports 1-4 and 1A for ports 5-7, so I can feed cameras using two different sources). After that, no more hangs on image downloads, even though my “PC” is hardly a good choice for this task (it’s a MacBook running Windows and connecting to devices using a single USB3 port and the above mentioned hub).
This is just an example of how a seemingly unrelated piece of hardware can cause unexpected issues to other devices. That’s even more critical when hardware is pushed to the limits, as it happens when downloading a large imaged through USB3. The fact that each of us is using a different hardware configuration is the reason why it is exceedingly difficult to provide a general-purpose solution.
I just don’t want to say that SGP couldn’t handle those situation more gracefully (e.g. a timeout ?), however I’d recommend to perform a dry test, starting with one connected device only (e.g. only the camera) and gradually adding additional device until the issue is tracked.
Had the same problems myself,only thing i could see on the log was that it went into a super dangerous loop,posted a couple of problems about this bit no resolution
Mike, responding to this and my earlier post (5) - I have kept an old SX ASCOM driver v5.5.1.13082 which for me seems to work more reliably with PHD2 than the current one (in so much that I do not get as many download hangs with a lodestar x2). As you say Mike, the PHD2 driver seems better still.
In the past I have also had occasional problems with image download hangs, not serious but annoying. These have gone completely away since I removed the USB hub I had been using. And, by the way, I had tried 5 or 6 different brands of hubs. In order to do this I had to move my Windows 10 computer as close as possible to my mount. I placed it on a tall stand directly under the floor below the mount, which is on the second floor. This allows me to use USB cables no longer than 5m. The end result is there are no USB hubs in use, all USB connections go directly to a port on the computer. Well, actually I am using the 2 port USB hub on my ASI1600MM to connect the filter wheel.
The cameras I have been running are 2 ASI1600MMs plus a Lodestar X2 for guiding. No hangs for 10 months. The Lodestar driver I am using is the latest version of the Starlight Xpress SXV driver.
Being a software developer and having worked with PCs and networks for over 30 years, I had a hard time believing that USB hubs could be so problematic in this hobby. They do work perfectly for probably most of us. However, it seems they can be causing issues with some combinations of hardware.
I recently acquired a Paramount MEII and learned from reading the manuals that Software Bisque also strongly recommends avoiding USB hubs, if possible. They recommend a specific model for those who must use one.
One of my ASI1600mm cameras still would not download reliably after direct connection with 5m USB3.0 cable to the computer (would not work reliably with either of 2 that I have). What I did that fixed it perfectly was to replace the 5m USB3.0 cable with a USB2.0 5m powered extender cable, such as the Tripp Lite USB 2.0 Hi-Speed Active Extension Repeater Cable (M/F), USB Type-A, 5M (16 ft.).
I agree with jmacon. It is the hardware that matters, specifically the chip sets that are used in the devices are crucial: in the computer, in hubs and in peripheral devices like cameras, focusing controllers, mounts, etc. The problem with the USB bus is that there are specifications and the manufacturers of devices don’t pay attention to them. The bottom line is: there are combinations of devices that do not cooperate well.
I am using the following devices:
Notebook: Fujitsu Lifebook E 746 (Windows 7 Professional SP1)
4-port powered USB3 hub: EXSYS EX-1183HMVS (chip set: Genesys GL3520)
The notebook is connected via 5 m USB3 cable to the powered USB3 hub. The camera is connected to the USB3 hub via 3 m USB3 cable. The guiding camera is connected via 0.8 m USB2 cable to the USB2 hub of the ZWO ASI294. Focusing controller and USB2 -> serial converter are connected to the USB3 hub via 3 m USB2 cable. The mount is connected to the USB2 -> serial converter. I use USB3 cables from Delock. The USB2 cables are from different suppliers.
Under no circumstances I experienced a stuck data transfer on image download.
) It seems that the data flow from the camera to the computer is getting interrupted causing the usb to crash .
, I have switched it off on my laptop as well