I’m having a problem with downloading images that seems to send SGP into a state where it is not frozen but something clearly isn’t right. A week ago SGP was waiting on a download during autofocus for 6hrs, causing a pier crash. Tonight was the next clear night, and the download problem happened again. This is with a QHY163M. LOG FILE
Here’s what I observe
Start sequence as normal.
SGP waits for image to download. I wait several minutes (should take 3 seconds). It would stay in this state all night long if I let it.
I abort the sequence.
SGP reports that the image has downloaded, but the box to Abort Sequence is now grayed out and resume is not clickable. At the same time, I can’t restart the sequence or take a frame and focus image, but other commands are available. It’s like SGP is still waiting on the image download even though it isn’t.
I have no idea what’s causing this, but I can’t leave it unattended like this. And I should note that I am dual scope/camera imaging and the second camera (also QHY) is downloading fine. It’s possible that the camera is the problem, but SGP should have some safeguards in place if it doesn’t finish downloading an exposure for an inordinate amount of time.
Last night after after the first image download problem I restarted SGP and began the sequence again. It ran fine for a few hours. Then the download problem happened again and this time SGP just closed without warning. The end of the LOG FILE simply shows:
[03/16/19 02:01:13.497][DEBUG] [Main Thread] Adding sequence level notification: (Lights_CFF135_F7_QHY163) Failure while integrating Abell 33; Event 1; Frame 58 for 300s. Image has not downloaded in alloted time period.
And that’s it. No proper shut down, no recovery etc. SGP just closed.
So I just figured out why I was having the download problem and it’s my own dumb fault. I’m using 2 QHY cameras, but was using the SAME driver for both of them, instead of the second driver that is available in the ASCOM settings.
Still, it’s concerning that SGP just either sat there for hours while waiting for the download, or SGP simply closed without warning when the download failed. Can there be some kind of recovery for situations like this?
Yes, I have now implemented the MountWatcher timer (thanks Andy!), which would have prevented what happened. I might make the WatchDog also, but that would require yet another piece of hardware…
I love Astro-Physics, but I kind of think it’s crazy that they don’t implement this most basic safeguard in the ASCOM driver and instead force you to pay hundreds of dollars for APCC to get it. That combined with the often touted claim that the motors can’t be burned up (obviously not true in my case) has left me a tiny bit dissatisfied. I was certainly very happy with AP service, who had the motor back to me in less than a week.
I agree about Astro-Physics mounts, Joel. This is a basic safety feature that should be built into the driver. I feel the same way about cars. Anti-lock brakes, airbags, and other safety technologies should not be optional.
Are you aware that the Astro-Physics V2 driver includes a free utility called “AP Timer” that allows you to stop or park the mount after a period of time?
No I wasn’t aware of this. If I understand it correctly I enter a number of h/m/s that acts as a countdown timer to either stop tracking or park the mount. I’m not sure that this would have been helpful in my case to prevent what happened. I’m not sure when the pier crash happened but I suspect it would have happened before I set this timer to stop tracking, since I would have set it for longer than my imaging plan that night.
I want to say too that I’m not trying to bad mouth AP or you in any way. I just think safety stops are a basic thing that should be included.
If the mount was still connected it might be that the timer could have stopped the forward tracking at the end of your session before the motor failed.
BTW, I have had several AP mounts going back almost 20 years now. Well before the new driver or APCC were even considered I would only tighten the RA clutch just enough to keep it in place. It was always loose enough that if the mount ever tracked the scope into the pier the clutch would allow slippage. If that happened just the RA coordinate would be off and could be approximately restored by going to a park position, moving RA back to about where it should be, then doing a RECAL the next time I used the scope.
My Paramount has a software tracking stop in TSX. I think the 10 Micron has something similar, with a hardware and software endpoint, both based on a physical position, so it should be entirely possible.
Another idea is to have a proximity reflective switch, as I use for my roof control. If it reached the position that reflected light, the relay would remove mount power?
Hi buzz, the Astro-Physics Command Center (APCC) has a feature that can set different limits for each declination because usually a scope can travel further past the meridian at certain declinations than at others. APCC also requires certain (later) versions of firmware so that it can use that firmware’s dead man timer feature, which will automatically stop the mount if the computer is disconnected or crashes for any reason.
I think one of Joel’s points was that this software is not included with the mount. Astro-Physics chose to make the software optional instead of including it with every mount and raising the price of every mount. For a Paramount I think the development cost of TheSky suite is probably built into the cost of the mount.
I can appreciate the decision Astro-Physics made to not include APCC with every mount and raise the price of every mount. Having said that, we don’t need the sophisticated smarts of APCC to base limits on certain declinations. All we need is a simple safety stop at one declination. It’s this basic safety feature that I feel should be included. Then if some people still want the more sophisticated features of APCC, including “smart safety stop at different declinations” they can buy it.
I also understand that there’s a lot more that goes into these decisions that I am aware of. I’m a very happy AP owner! Thanks for responding here Ray.
All we need is a simple safety stop at one declination.
It’s this basic safety feature that I feel should be included.
Many people use AP mounts for visual use and so for them APCC is not needed. If you are doing imaging then the standard version of APCC is something you should consider. It’s a small fraction of the price of your mount and provides the safety features you want.
That said, the feature in APCC to stop tracking at a limit is just an application feature, not a feature in the mount’s firmware. It would thus be relatively easy for another software application, including SGP, to define a software limit where tracking stops. APTimer, is an example of an external application stopping tracking or parking the mount.
Its not SGP. Its the camera. There is a faulty ribbon cable in QHY163M cameras. If you search the QHYCCD site, you will find topic in one of the forums. If you dismantle the camera, you will notice a small ribbon cable about 10 cm long and 3 cm wide. Push down on the connector and try a download. If it works, that is your problem. Tape the ribbon cable, tightly, down at the connector. It worked for others and me. Chilly nights tend to make the contact work lose. Clear Skies. ~John
I come across the ribbon cable problem earlier, but in my case the download was due to a driver conflict. I operate 2 QHY cameras at the same time and I had inadvertently chosen the same driver for both cameras. So that issue has been resolved.
But now there’s a new driver problem I have with the QHY163M. Below is a screenshot of an image I took with the 163 and another of the 183. Both were 5min narrowband images. For some reason the drivers I’m using are shifting the histogram further and further to the right with increasing exposure. In contrast, the 183 image histogram looks proper with the left side of the histogram where it should be.
The black and white slider markers are very different in both histograms. If you match the markers of bottom image with top image, the top image may look more correct.
Actually that’s not the case Peter as evidenced by the image attached here. Look carefully at the first image above (QHY163M). On the far left side of the histogram is a thin yellow line. That line is always present there no matter what the exposure length. The bulk of the histogram gets pushed further and further right with increasing exposure. At one point I had nothing but a full white image because the bulk histogram was so far to the right it didn’t even show on the histogram, while that thin yellow peak was still there to the left.
Contrast that with the second image above (QHY183M). No matter what the exposure, the left side of the histogram always stays in the same location, while the body of the histogram expands with longer exposure.
Something is up with the drivers and I’m working with QHY to get this resolved. I felt the need to update the drivers recently due to a different problem and that has basically ruined the QHY163 for the time being until the drivers can get sorted out. When it comes to QHY, NEVER UPDATE DRIVERS IF YOU ALREADY HAVE A WORKING CAMERA!!!
