Has anyone seen this problem before?

John

I can see that the first image set the binning at 2 while the second set at 1?

Regards,
Robin

Hi John,

It sounds like a power supply issue if plugging/unplugging fixed it and it would be good to check the voltage across the input to the camera. Before changing to a high-quality power-supply and higher gauge cables, I would frequently have the camera cooling go berserk. That said, I think it's also worthwhile to repeat the experiment using e.g., NINA or EZCAP that talk to the camera through the native interface.

Cheers,
Mo

For the QHY600M, I would suggest a test using the supplied QHY power supply and a known good USB cable directly to your computer 
Use the latest QHY all in one driver making sure qhy5III driver is checked as well as your imaging software so it can install the native drivers into the app

https://www.qhyccd.com/download/

Note SGP doesn’t use native camera drivers, just ASCOM. (Just one of the reasons I went to NINA)
Then use the QHY QT app to connect to the camera 
Besides seeing if if shows an image, it will update the camera with the latest firmware 

connecting with QT app, using supplied power supply and directly connected USB to computer, are usually the basic QHY test requirements before they accept a fault (from experience)

good luck

Thank you all for your feedback and thoughts.  As usual, when I did this post, it’s easy to forget things so I didn’t supply quite enough background on what I’ve tried and how I operate.  So, in no particular order, here is some additional background that will form a response to many of the good comments and suggestions here.

1). I’ve been running this scope in it’s current configuration every clear night for almost exactly one year.  In Chile, that translates to around 300 nights.  I always run the scope with SGP.

2). The power supply is one originally supplied by FLI for my FLI-ML16803.  Before the scope went to Chile, I carefully checked the voltage against the QHY supplied power brick and they were within a few 10s of milli-volts of each other.  The FLI power brick has more current capacity than the original QHY supply so it runs really cool.  As I said in the original post, I haven’t yet asked the guys at the observatory to put a DVM on the power cable, but I will.  It could be a supply problem but I personally put that as “low” likelihood.

3). One thing that I forgot to mention is that when this problem occurred, I homed the filter wheel and then defocused the scope to confirm that nothing was blocking the pupil.

4).  I tested the system using both 1x1 and 2x2 binning.  When I posted this data, I goofed and pulled up one of the 2x2 images to compare with a 1x1 image.  Binning makes no difference in the results and I apologize for the mistake.

5)  I normally power up my system each night and completely power it down in the morning.  That means that the power is normally off every day so that the systems does a “clean boot” every evening.

6) I tried EZCap to look at the camera output but for some reason, it won’t boot.  It complains about a missing DDL.  I don’t have patience to debug that kind of nonsense so I used Maxim DL to confirm what I was seeing with SGP.

7) I looked at the ASCOM driver setting to make sure that nothing had changed and the driver is set just as it always has been.

8) Two nights ago pulling the cables fixed the problem but last night nothing we did could bring the camera back to life.  I switched power to the camera on and off and completely rebooted the system.

9)  Because I use ONAG for autocovariance focusing and covariance guiding, neither NINA nor Voyager will work on my system.  I am wed to SGP and this does not appear to be a problem with the imaging software.  Remember that I have ~ 300 nights x ~8 hours under my belt operating with SGP.

10)  We have tried both the old USB3 cable that has been on the system and a brand new USB3 cable and the problem persists with both cables.  To be clear, these are active USB3 cables since the required run length exceeds the USB3 3 m standard.  I don’t see any USB bandwidth transmission errors that normally look like a wrap-around or synch error in the image data.

I’ll hit up QHY about this to see what they have to say.  The problem with this kind of problem at a remote observatory is that it can take literally months to get the camera pulled, sent back for service, get it returned, and get it remounted and aligned on the scope.  It is much faster to simply order a new camera and hand carry it to Chile.  That’s why I already have a spare guide camera at the observatory and why I may even bring a 3rd guide camera down there when I go.  I am extremely unimpressed with that ATIK camera so I’ll swap it with a ZWO camera. My old FLI cameras ran for years without a glitch so I’m not very impressed that this QHY camera only made it one year before going flaky.  We’ll see how QHY will deal with it.


John

Hi John,
I had a number of similar strange issues associated with low voltage until I put DC-DC power supplies on critical components like cameras and computers. My setups are completely solar powered, as you know, so I am more susceptible to those issues when tied directly to batteries, even with separate local batteries for computer-camera, mount, dome.

Dave

Michael & Jon Norman:
The missing DLL message and EZCAP not starting sounds like a telltale sign of a software configuration problem to me that might be at the root of your problems. Did EZCAP work previously?

I know it's a pain to mess with, but it's a lot less of a pain than having to make the trip to Chile.

Totally understand that swapping in a working camera is better / quicker than going through the warranty cycle. We've taken the same approach. 

M & J

The "missing DLL" message is only for EZCAP, which I don't use.  It has never worked and I have never needed it so it has nothing to do with the camera problem. Yeah, doing a factory repair is a very long cycle for a lot of reasons.  Having a scope sit useless through some of the best weather isn't worth simply replacing the camera ASAP and then having the broken one repaired on a parallel, non time critical path.

John

Rouz Astro:
Did you try changing modes, gain, and offsets?

Oh yeah, I tried everything without success.

John

So you didnt try a USB 2 cable?  Pretty painless to try that.  USB 3 is a terrible interface for astrocameras.  It can work for months or years to suddenly have intermittent failures.  Bill mentioned it earlier and you only replied that you are not seeing any transmission errors.   I'd still try it as it just might be the easiest solution to your problem.  I cant tell you how many times I have had issues with USB3, and the issues range from not being able to download, to corrupted frames, to just about any form of weirdness.  I've sent countless tech support messages to ZWO and QHY over the years trying to get USB3 to be reliable. 

I can tell you that I have had zero file issues with any of my cameras with respect to USB2.0.  Worth a try.

Michael & Jon Norman:

So you didnt try a USB 2 cable?  Pretty painless to try that.  USB 3 is a terrible interface for astrocameras.  It can work for months or years to suddenly have intermittent failures.  Bill mentioned it earlier and you only replied that you are not seeing any transmission errors.   I'd still try it as it just might be the easiest solution to your problem.  I cant tell you how many times I have had issues with USB3, and the issues range from not being able to download, to corrupted frames, to just about any form of weirdness.  I've sent countless tech support messages to ZWO and QHY over the years trying to get USB3 to be reliable. 

I can tell you that I have had zero file issues with any of my cameras with respect to USB2.0.  Worth a try.

The QHY 600M is a USB 3.0 device and requires a USB 3 cable ...

It can use USB2 cables just fine. That is how I run mine.

…or try to limit your usb3 speed to a lower range.

edit:
oh sorry, that of course only works if your camera is still available on your system.

I have some experience with the QHY600M (early bird edition).    Two of them were put into service several years ago.    The QHY camera USB3 connection first negotiates the connection with USB2 signaling.   This presents random problems with some USB3 hubs and amplified extension cables.   By the way, the Tripp Lite USB3 active extension cable seems to be the "least worst."    I'd reconnect the USB3 camera cable to a USB2 port on the PC.   Keeping the signaling USB2 may do the trick.   You will still be subject to the 5 m length limitation without an active repeater or powered hub in the middle.   The QHY thermal controllers have had issues which can cause a failure in the image capture circuitry.   I returned one camera to QHY for exactly that reason.     It does sound to me like the fault is likely in the camera which will require a factory return.   Last May I returned a QHY128 to the factory for repair.    I'm still waiting for a diagnosis and repair / replacement.   I did get a note a week or two ago indicating that they were starting to work on it…..    The QHY600 is an excellent camera but for a remote site where everything has to work all the time I'd choose something else.   I have three OTAs at Sierra Remote.   All  three use Moravian C3-61000EC PRO cameras which have performed perfectly every night.   And they do image every night.    

Just my .02,

John