Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Erratic behavior of QHY camera in NINA

  • Please log in to reply
28 replies to this topic

#1 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 11 August 2020 - 01:22 AM

Hi everyone, 

I'm running a fairly straight-forward imaging system with a Skywatcher AZEQ6, Explore Scientific 127ED, and a 50mm guide scope. The QHY 163C camera and QHY 5LII mono guide camera are connected through a 12V powered USB hub on the main scope. The hub and mount are each directly connected to a brand new ASUS Windows 10 pro laptop via their own USB cables (EQDIR in the case of the mount). I'm controlling everything with NINA 1.10, the latest build. 12.8 volts of regulated DC power are supplied by an Alinco dm-340 switching power supply. I have been using NINA with this set-up for about 6 months, mostly very happily, getting it to successfully plate solve, focus, and execute sequences on targets. It has been a joy to use until the past week or two.

 

Over the past three imaging sessions I have been getting a persistent cluster of issues in NINA which I think may be all related. I dearly hope someone here can help me determine the cause.

1. My main imaging camera seems to work properly for between 5 and 10 minutes or so (starts to cool to reach its set-point for imaging, will collect images for plate solving and auto focusing which NINA displays) but then appears to begin a series of random wild temperature and power swings, with temperature readings of 6000C, all of this displayed on the NINA camera panel. It stops delivering images either from a sequence or from a snapshot command. The camera appears to be maintaining its connection to the laptop via USB, but according to NINA, is seriously misbehaving. 

2. PHD stalls out. The program opens initially on cue from NINA, connects the camera, picks a guide star, and loops patiently waiting for the command from NINA to start guiding, but at the same time the imaging camera goes nuts, PHD stops responding. The image loop stops and freezes and is unresponsive, or upon hitting the stop button, stalls out saying "Waiting for devices...". 

 

In trying to address this, I have updated the camera drivers; changed out the EQDIR and main USB2 cable from the hub; changed the power cable to the imaging camera.  I've tried most things I could think of but problem persists. This is additionally perplexing because I have no idea what might cause this stuff to happen, whether it is one problem or several working in tandem. 

 

Any clues or suggestions?  

 

I'm thinking I should try a different power supply or battery power to eliminate the Alinco as a possibility, and different control software like APT or SGP to manage the integration and sequencing. 

 

Thanks in advance,

Dave


Edited by siriusarcher, 11 August 2020 - 01:27 AM.


#2 Mert

Mert

    Fly Me to the Moon

  • *****
  • Posts: 7,055
  • Joined: 31 Aug 2005
  • Loc: Spain, Pamplona

Posted 11 August 2020 - 01:48 AM

Have you checed the conection menu in PHD and see which camera it wants

to connect to?

Sometimes windows messes up with its internal USBdevice tables.

Make sure/check PHD selects and connects to the guiding camera.

If still failing, you might use USBDeview and uninstall all USB devices

ad reconnect 1 by 1 your usb devices so windows sets up a new table.

Just my 2 penny.gif worth shrug.gif

 

Mert


Edited by Mert, 11 August 2020 - 01:49 AM.

  • H-Alfa and siriusarcher like this

#3 Dwight J

Dwight J

    Soyuz

  • *****
  • Posts: 3,586
  • Joined: 14 May 2009
  • Loc: Lethbridge, Alberta, Canada

Posted 11 August 2020 - 02:09 AM

In the camera panel do not touch “Duration” as this can cause the odd cooling behavior.  The PhD thing I would not hazard a guess.  Running it separately would work but setting dithering up is a process.


  • siriusarcher likes this

#4 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 11 August 2020 - 07:50 AM

To add a little more information, here's what I see in NINA:

IMG_1952.jpeg

IMG_1951.jpeg



#5 sn2006gy

sn2006gy

    Viking 1

  • ****-
  • Posts: 789
  • Joined: 04 May 2020
  • Loc: Austin, TX

Posted 11 August 2020 - 10:11 AM

Are you using the native QHY drivers in NINA or are you using the ASCOM drivers?  Updating the platform drivers would only change the ASCOM side of NINA.

 

I think there will be a small 1.10 update here soon that will include latest QHY drivers internally tooo.



#6 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 11 August 2020 - 01:18 PM

Byron,

I must admit I'm confused about the driver situation. I was aware NINA had built-in support for some devices but wasn't sure how the software sorted out who would be controlling those devices: if NINA did it independently with its built-in support, or if NINA routed commands through downloaded QHY ASCOM-compliant drivers. Is there a "best practice" with respect to the use of downloaded proprietary drivers that I should observe? My current practice is to assume they are needed, dump them into my system, and cross my fingers in hopes that they work. Not very smart, I know.

 

Thanks for the reply, BTW.

 

Dave



#7 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 11 August 2020 - 09:34 PM

Dwight, yes I guess this qualifies as odd cooling behavior. When you say "duration" do you mean for the cool-down, or the warm-up? 



#8 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 11 August 2020 - 10:50 PM

Hi, author of the QHY driver in NINA here.

 

First, if you're selecting the "QHY163C" camera under the QHYCCD category in the camera selection drop-down, you are accessing the camera via the native driver, not the ASCOM driver. The ASCOM drivers are listed near the bottom under the ASCOM category.

 

Second, the temperature going awry and PHD2 dropping out because (presumably) your guide camera dropped out is likely because of systemic USB issues. Unpowered USB hub, an iffy port on your computer, cables too long or of low quality that could contribute to these kind of drop-outs. I also suggest ensuring that you've updated to the latest driver package that is available on QHY's downloads page. Recent versions introduce some improved USB error recovery.

 

Third, I suggest that you bring your support issues and questions to the NINA Discord server where you will get a more prompt response. I glance at these forums at best once a day or every other day, and no in depth so I might not notice these kinds of threads.


  • siriusarcher, leviathan and OldManSky like this

#9 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 12 August 2020 - 10:46 AM

To Dghent, thanks for responding and addressing the question of how NINA manages drivers. I had set this in the equipment profile, and have not looked at that profile in a while. Whenever the possibility exists to "set it and forget it", I bias heavily towards the "forget it" part. :-) And by all means, I'll check with the discord next time if the problem involves NINA.

 

As for USB, I'm using a high-quality powered USB hub but it is entirely possible I have a cable or port issue, and this can be easily checked. I have wanted greater distance between the laptop and the pier and needed a longer cable to accommodate that. Something to test. A previous responder also suggested clearing Windows' USB tables and rebuilding them.

 

Except for this brief interruption caused by my own lack of attention to detail, NINA has worked very well and has been fun to learn and use. I've gotten many hours of great imaging from it where I really only had to think about what object I wanted to image and what settings would best to use. I expect a quick return to the fun part of AP with the help of this amazing package, and will update this thread when I've got it sorted out.



#10 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 12 August 2020 - 11:44 AM

There was a recent change in Windows that has perhaps had a curious effect on USB devices. This is the USB Selective Suspend setting under power management. You can try turning that off to see if that changes the calculus

 

Right click Start > Power Options > Additional Power Settings > Change Plan Settings (for the active plan) > Change advanced power settings > USB settings > USB selective suspend setting > set to Disabled


  • siriusarcher likes this

#11 Whichwayisnorth

Whichwayisnorth

    Gemini

  • *****
  • Posts: 3,165
  • Joined: 04 Jul 2011
  • Loc: Southern California

Posted 12 August 2020 - 05:07 PM

Have had the same issue.  This happens to me when I unplug the camera and plug it back in again while NINA is running.  The fix is to close down nina and restart it.

 

Also make sure you have good usb cables and that they are short and providing enough amps for USB 3.0 connection. Bus powered is not good enough.  Use a powered hub if you can.


  • siriusarcher likes this

#12 tomb18

tomb18

    Mariner 2

  • -----
  • Posts: 257
  • Joined: 13 Oct 2015

Posted 12 August 2020 - 05:38 PM

The USB selective suspend is almost always reset by windows updates (major) to enabled.  When one is operating with software like NINA where you have a long running automation session, there is no  human interaction with the computer.  Windows then assumes that it can put the USB device into a low power state. I see this all the time with my commercial amateur radio software. This is most likely what is happening here.

73 Tom


  • siriusarcher likes this

#13 stryker66

stryker66

    Mariner 2

  • *****
  • Posts: 297
  • Joined: 31 Jul 2018

Posted 20 August 2020 - 04:42 PM

I had this issue with QHY drivers way back that is why I intend to avoid QHY, however if you download the 1.5.11(I think) it is the first 1.5x driver from qhy and all my issues disappeared..No hardware change whatsoever.



#14 sn2006gy

sn2006gy

    Viking 1

  • ****-
  • Posts: 789
  • Joined: 04 May 2020
  • Loc: Austin, TX

Posted 20 August 2020 - 04:51 PM

I had this issue with QHY drivers way back that is why I intend to avoid QHY, however if you download the 1.5.11(I think) it is the first 1.5x driver from qhy and all my issues disappeared..No hardware change whatsoever.

Edit:

 

sorry... this was QHY driver related, i was thinking NINA... 1.10 HF1 does have newer drivers for its native driver support.

 

You want to download Version 1.10 HF1 RC001 - this includes the latest QHY SDK - and it also fixes the problem with ZWO cameras where the native driver was color shifted to blue.


Edited by sn2006gy, 21 August 2020 - 03:13 PM.


#15 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 21 August 2020 - 02:36 PM

I had this issue with QHY drivers way back that is why I intend to avoid QHY, however if you download the 1.5.11(I think) it is the first 1.5x driver from qhy and all my issues disappeared..No hardware change whatsoever.

QHY has incorporated a lot of low-level USB error recovery code into the recent releases of their camera SDK, which is in turn used by their ASCOM driver as well as apps which implement their own native drivers for QHY cameras. Cheap USB cables with 28 AWG data line conductors and unpowered USB hubs will still conspire to derail people and often do no matter who the camera vendor is. But given decent-tier cables and hubs, QHY cameras are as reliable as anyone else's these days.


Edited by dghent, 21 August 2020 - 02:38 PM.


#16 stryker66

stryker66

    Mariner 2

  • *****
  • Posts: 297
  • Joined: 31 Jul 2018

Posted 21 August 2020 - 04:14 PM

QHY has incorporated a lot of low-level USB error recovery code into the recent releases of their camera SDK, which is in turn used by their ASCOM driver as well as apps which implement their own native drivers for QHY cameras. Cheap USB cables with 28 AWG data line conductors and unpowered USB hubs will still conspire to derail people and often do no matter who the camera vendor is. But given decent-tier cables and hubs, QHY cameras are as reliable as anyone else's these days.

ZWO has the best drivers and most stable. I use the same hardware and ZWO will never fail me. QHY drivers are a mess. The QHY174MM Cooled that I have only download 4MB of file while ZWO1600MM is 16MB let alone I have 3 of them active on the same cable and it still downloads fine.



#17 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 21 August 2020 - 08:59 PM

ZWO has the best drivers and most stable. I use the same hardware and ZWO will never fail me. QHY drivers are a mess. The QHY174MM Cooled that I have only download 4MB of file while ZWO1600MM is 16MB let alone I have 3 of them active on the same cable and it still downloads fine.

IDK man, I have a bunch of QHY and ZWO cameras of different types and generations and my QHY cameras run just as well as my ZWO ones... and I tend to run all of these cameras across 3 different compute environments (desktop, laptop, mini-PC) and USB configurations, so it's not just one "blessed" system that could be biasing my results with a rosy picture. Your assertion might be based on dated software or a problematic USB setup of some sort, which isn't hard to end up with given the wildly varying quality of cables and hubs out there.

 

Can you describe your setup a little more detail and the problem you're running into? Have you updated your QHY drivers (USB system driver, ASCOM driver, etc) using the new all-in-one driver installation package that QHY now provides, which ensures you're getting the latest of all the critical components? 



#18 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 27 August 2020 - 12:14 PM

Update: I should have mentioned another observation that accompanied the strange temperature readings and connectivity failure: high-pitched beeps from my laptop that only stopped when I disconnected the camera in software, or disconnected it physically. My solution was to simply power down and restart everything, re-acquire the target and resume imaging.

 

I now think (with some indirect evidence) that the erratic behavior I saw has to do with USB, as some contributors to this thread have suggested. Nothing at all to do with NINA. NINA simply gave me a screen to show me the connectivity issue I was seeing with the camera.

 

I had a glorious almost failure-free week last week imaging at a remote site with perfect performance from NINA which included completed sequences and successful automated meridian flips. I think it helped that I shortened all my USB 2 cables, by-passed the hub and direct-connected the camera and computer and updated all the camera drivers. I would say that this result by itself is not sufficient evidence that the problem was solved because I still do not know exactly what was causing it.

 

I ordered and received a new powered USB 3.0 hub and will test that out shortly. The goal is to eliminate any possible bottlenecks in the data connections. I'll update this thread again when I've had a chance to test the new hub. Thank you all for the ideas and discussion. It has been hugely instructive!



#19 siriusarcher

siriusarcher

    Messenger

  • *****
  • topic starter
  • Posts: 411
  • Joined: 25 Feb 2008
  • Loc: Canada

Posted 27 August 2020 - 12:22 PM

One further observation about my set-up: The QHY163C seems not to have built-in step-up or step-down of the cooler. I had a chance to compare it to a similar ZWO camera last week. If I did not set a cool-down time, upon connection in NINA the cooler power jumped immediately to 100% and the sensor temperature immediately began to drip precipitously, reaching the target temperature in well under  minute. In comparison, the ZWO running under APT had a very smooth ramp-down to its target temperature and ramp-up after the sequence quit. To avoid thermal shock to the chip, I set a cool-down time of 2 minutes. Cooler power still jumped to 100% initially, but dropped quickly as the camera approached its operating temperature of -10C.

 

The pop-up dialogue when you hover over the cooldown settings in NINA says that "most cameras" have built-in thermal management. The QHY 163 does not seem to have that.

 

Dave



#20 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 27 August 2020 - 07:40 PM

QHY temperature control is a trained PID algorithm executed by the camera SDK and firmware. The thermal shock myth is probably one of the biggest urban legends of the astrophotography scene. If thermal shock were a real problem, these forums would be filled by people upset over their broken cameras after the power failed or they switched things off suddenly.


  • Whichwayisnorth likes this

#21 stryker66

stryker66

    Mariner 2

  • *****
  • Posts: 297
  • Joined: 31 Jul 2018

Posted 28 August 2020 - 09:10 AM

IDK man, I have a bunch of QHY and ZWO cameras of different types and generations and my QHY cameras run just as well as my ZWO ones... and I tend to run all of these cameras across 3 different compute environments (desktop, laptop, mini-PC) and USB configurations, so it's not just one "blessed" system that could be biasing my results with a rosy picture. Your assertion might be based on dated software or a problematic USB setup of some sort, which isn't hard to end up with given the wildly varying quality of cables and hubs out there.

 

Can you describe your setup a little more detail and the problem you're running into? Have you updated your QHY drivers (USB system driver, ASCOM driver, etc) using the new all-in-one driver installation package that QHY now provides, which ensures you're getting the latest of all the critical components? 

QHY174MM cooled when connected will throw hard lines to my lodestar X2 which is impossible to guide. Once I unhook the camera the phd2 lodestar camera becomes clean. Now I use this same setup connected to 3 ZWO1600MM on the same laptop and there is no issue. Remember this is the same cable and the same laptop. I can replicate this to my QHY174MC and QHY174MM cooled cameras. I also observe this on my previouos cameras that I sold. So this means that the electonics inside are the same and the driver is nowhere near the stability of the ZWO

Edit:
For testing purposes, I replace it with three same length of cable "16ft" USB3 superspeed and all of them have issues. all 3 of these cables are connected to an active USB cable with powered bus. The only solution I have is to use a non powered straight cable 25ft USB2 since I only need this for DSO and not live video. But it sucks
BTW - the latest driver will make it even worse where APT will just say waiting for images, so the USB Bus is not sending a proper ack that the image is done. The older driver works and no issue of this is observed


Edited by stryker66, 28 August 2020 - 09:18 AM.


#22 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 28 August 2020 - 01:07 PM

A 5 meter USB3 cable is asking for trouble, and you have to understand the highly variable results that you can and will get when operating any equipment at such extreme lengths.

 

The USB 3 specification does not define a specific maximum cable length between host and devices or hubs, so the USB controller chips on your computer and the chips that terminate the USB connection inside peripheral devices will have their own demands and tolerances in this regard. It's generally understood that anywhere from 3 to 5 meters is considered to be the absolute maximum extent and quality of the cable used, in addition to the signaling and magnetics characteristics of the electronics at both ends of the physical connection, play an outsized role in determining how far past the magic 3 meters that you'll be able to push things. The speeds which USB3 signaling is capable of requires a high level of signal integrity, which is why going to USB2 cables tends to iron things out albeit at lower speeds.

 

These variances in tolerance cannot be nailed down at just a broad by-manufacturer level, either. My ASI1600MM-Pro would be just fine with a 3 meter cable, but when I switched to solar photography and used one of my ASI174's with the same cable, SharpCap would start dropping frames like it was its job and the camera would intermittently go missing on the USB bus, requiring me to physically reconnect it. A 2 meter cable worked out fine. This is just the reality of USB3. If a high bandwidth device works at 5 meters, it's more out of sheer luck than by design.

 

Given all that, I did what many people are now doing and moved to putting a mini PC on my mount where my longest USB cable is now 1 meter and I don't have to worry about these things. Instead of crossing my fingers with a long USB cable with a cable snaking across the yard or through a window, I just remote desktop into the mini PC from the comfort of my office PC or ipad.

 

So in your case, a shorter cable is, at a minimum, what is required here. Preferably one that is shorter and has larger gauge conducting wires inside.  Optimally, you would dispense with the long cables and put the computer close to the telescope and use short cables.



#23 stryker66

stryker66

    Mariner 2

  • *****
  • Posts: 297
  • Joined: 31 Jul 2018

Posted 28 August 2020 - 02:01 PM

A 5 meter USB3 cable is asking for trouble, and you have to understand the highly variable results that you can and will get when operating any equipment at such extreme lengths.

 

The USB 3 specification does not define a specific maximum cable length between host and devices or hubs, so the USB controller chips on your computer and the chips that terminate the USB connection inside peripheral devices will have their own demands and tolerances in this regard. It's generally understood that anywhere from 3 to 5 meters is considered to be the absolute maximum extent and quality of the cable used, in addition to the signaling and magnetics characteristics of the electronics at both ends of the physical connection, play an outsized role in determining how far past the magic 3 meters that you'll be able to push things. The speeds which USB3 signaling is capable of requires a high level of signal integrity, which is why going to USB2 cables tends to iron things out albeit at lower speeds.

 

These variances in tolerance cannot be nailed down at just a broad by-manufacturer level, either. My ASI1600MM-Pro would be just fine with a 3 meter cable, but when I switched to solar photography and used one of my ASI174's with the same cable, SharpCap would start dropping frames like it was its job and the camera would intermittently go missing on the USB bus, requiring me to physically reconnect it. A 2 meter cable worked out fine. This is just the reality of USB3. If a high bandwidth device works at 5 meters, it's more out of sheer luck than by design.

 

Given all that, I did what many people are now doing and moved to putting a mini PC on my mount where my longest USB cable is now 1 meter and I don't have to worry about these things. Instead of crossing my fingers with a long USB cable with a cable snaking across the yard or through a window, I just remote desktop into the mini PC from the comfort of my office PC or ipad.

 

So in your case, a shorter cable is, at a minimum, what is required here. Preferably one that is shorter and has larger gauge conducting wires inside.  Optimally, you would dispense with the long cables and put the computer close to the telescope and use short cables.

Believe me I know all the limitations I am not contesting that, but answer me this, why 3 ZWO ASI1600MM attached "at the same time" plus mount and guide cam do not have an issue? If you have doubts look at my setup. QHY only have a mediocre 4MB file and a lodestar camera without even a mount and cant even download from camera because ascom is not communicating well with the device, it is the driver. I have no questions to ask if you can explain that



#24 stryker66

stryker66

    Mariner 2

  • *****
  • Posts: 297
  • Joined: 31 Jul 2018

Posted 28 August 2020 - 02:19 PM

Here is an excerpt of another user I helped when he purchased my QHY last year..Which proves QHY ascom drivers are poorly written.

 

Attached Thumbnails

  • Annotation 2020-08-28 151700.png


#25 dghent

dghent

    Viking 1

  • *****
  • Vendors
  • Posts: 670
  • Joined: 10 Jun 2007

Posted 28 August 2020 - 02:29 PM

I think you missed the point. 5 meter cable length is undefined territory where a high bandwidth device of any sort is not expected to be 100% reliable at USB3 speeds, and a device that does not operate at such an extent isn't necessarily a bad device. As for the behavior in your specific setup, no one can know the answer to that because you're talking about communication over a wide range of discrete components in a configuration that pushes, if not exceeds, any reasonable expectation.

 

To give you an idea about how impossible it would be for anyone to give you a 100% accurate and detailed answer, let me explain something. Electrical characteristics of the devices on a USB bus also effect each other in certain ways, and this is not limited to just USB, but any bus that shares electrical connections between components - ethernet, PCIe, i2c... anything where components are not electrically isolated from each other. There can be a noise issue with one device that affects another, even though the noise characteristics of both are within acceptable limits - but the hub that connects them does not sufficiently filter the noise and the resulting interaction causes one device to reset its connection or miss sending data because it has to retrain its link at some level. When you then introduce a configuration that stresses these tolerances, such as using exceedingly long or low-quality cables, these problems that would normally be with tolerances now cause problems. It's a complex arrangement and set of circumstances that belies its seemingly simple "insert tab A into slot B" look.

 

You must also consider usage patterns of the devices. I'll go out on a limb here and bet that you're imaging with the QHY174 at continuous high frame rates for planetary, lunar, or solar work, and you're using the ASI1600s for comparatively languid DSO imaging where each camera will spit a frame onto the wire only every few minutes or so. If you're looping your Lodestar for guiding in PHD2 and driving your QHY174 at high frame rates for solar system work, then your bus will be far more contended for than it is even with 3x ASI1600s. Again, this is where high stress in the form of bus contention and borderline electrical characteristics will push things beyond their tolerances.

 

Now, that said, QHY has put some more low-level USB error recovery into their drivers over the past several months. You will not benefit from this if you're not running these current drivers. But if your usage patterns aren't appropriate for your configuration that involves a 5 meter cable, you will run into problems... use shorter cables or move the computer closer to the source of the data if you want 100% reliability.




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics