Page 1 of 4

Issues with QHY168C

Posted: Wed Jan 30, 2019 5:47 pm
by lfhiii
I have 2 QHY cameras. A 163C whose temperature control works well. It remain steady at -13.7C for a set point of -15C. The 168C is another story.
For a set point of -15C it reaches -25C, which no doubt is its limit (this translates into 35C below ambient).

I can sometimes control temperature in non-auto mode by adjusting the power level manually.
Any thoughts would be appreciated. I am running the most recent version of SharpCap.

Stacking etc all seem to work ok.

Thanks,

Leonard

Re: Issues with QHY168C

Posted: Wed Jan 30, 2019 7:52 pm
by admin
Hi,

When you using the very latest version of SharpCap 3.2? I ask because there is a new version of the QHY SDK included in the latest version and it may be that that give you better results.

Cheers, Robin

Re: Issues with QHY168C

Posted: Wed Jan 30, 2019 11:35 pm
by lfhiii
Thanks, Robin.

I will check that out.

Leonard

Re: Issues with QHY168C

Posted: Fri Feb 01, 2019 7:32 pm
by bwells
Hi Robin

YOu may recall I worked with you last year to try and get my 165C working with SharpCap. I had two problems:
  • One was with the sensor analysis not working and
  • Two was strange behavior with the temperature settings.
You said at the time the problems were with the QHY software and not something you could address.

For the temperature problems I was having, I found that your software set the temperature to the max value every time the temperature was too low. So on start up, SharpCap would set the level to 255 and the QHY driver would shut off at 255. So I had to use the QHY EZCap_QT program to control the temperature.

Do you think this new QHY driver would make it more likley that your sensor analysis would work now? I thought I would check with you on any progress made to support QHY165C. I believe the 168C is identical to the 165C in almost every way, so if things work for the 168C, they should work for the 165C. But I also suspect if they do not work for 165C, they will not work for 168C.

For reference, the Thread I started at the time is here: viewtopic.php?f=28&t=1092

Thanks for your help!

Re: Issues with QHY168C

Posted: Fri Feb 01, 2019 7:45 pm
by admin
Hi,

I'm afraid I don't know for sure whether the new SDK will help with those particular issues, but it's certainly worth a try and I'd be very interested to hear your results. This is one of those difficult things where if I had a camera that was showing the problem to work with I might be able to design a workaround for whatever problem is occurring without that luxury I have to rely on the QHY team fixing whatever problem it is in the SDK.

Cheers, Robin

Re: Issues with QHY168C

Posted: Sat Feb 02, 2019 2:34 pm
by lfhiii
Hi Robin,

RE:QHY168C temperature control.

I reloaded both the ShapCap and the QHY drivers and the temperature control on the 168C is now working properly based on a short test.
Overall I think we can close out this issue.

Thanks for your help.

Leonard

Re: Issues with QHY168C

Posted: Sat Feb 02, 2019 6:52 pm
by admin
Hi,

Good to hear that it's now working well for you and thanks for the feedback.

Cheers, Robin

Re: Issues with QHY168C

Posted: Fri Mar 15, 2019 1:51 am
by iamhondo
I recently had trouble with a QHY168c and its thermal control. I'd like to add a few notes about that I found.

My camera worked fine with SC a few months ago, including temperature control. Then I recently brought it out of a cloud-induced coma to mount on my scope for real photography. Unfortunately, I had annoying cooling problems. I could set the target temperature. But if SC was in "auto" for cooling, the power level would show 255 while the temperature gradually rose above room temperature. If auto was turned off, the camera just applied the manually set cooling power. So the cooler was working, but the target seemed ignored by SC. At the same time, I saw other erratic cooling behavior with QHY's EZCAP_qt tool. I was sure the camera was broken but I hoped it was software issue and set the camera aside.

Much later I connected the camera to a different PC to review the problem. The failing auto-cooling repeated in SC. Then I tried using the latest EZ_CAP and this time it performed perfect automatic cooling. That was different than before. I returned to SC and tried controlling the camera through ASCOM. Sure enough, setting the setpoint with camera in ASCOM mode gave perfect cooling. It showed how the power level dropped as the temperature approached (or crossed) the setpoint. So the camera wasn't broken. I was only having cooling issues with SC and the native camera interface. Since SC is my main imaging tool I had to dig.

On this forum I found a mention of a QHY183 cooling problem that required getting a "better" qhyccd.dll. (Somehow, I missed this more relevant QHY163c/cooling thread.) So I searched my computer for qhyccd.dll files. I was surprised to see there were 10 of them, scattered in the Program Files folder for various software like PHD2, SharpCap, EZCAP_qt, and some other imaging products. Checking property details I found a jumble of versions -- sometimes none. Mostly the "Product version" adhered to the date modified: 17.12.21.0 for a 2017/12/21 date. The one in my SC 3.2 (current at 6.17.6.8292) folder had a 18.5.2.0 version. So since my EZCAP_qt instance was doing good temp control, I copied its qhyccd.dll file to the SC 3.2 folder. Bingo. Great cooling on three different computers. Problem apparently solved.

Curiously, I found that if you just rename or delete the qhyccd.dll in the SC folder and start SC, it somehow creates another one. AFAICT it comes from somewhere in the app or some of the SC-supplied file/folder. But it's no more current than the latest install/update of SC (I think).

I think what happened was that I had a matched set of native driver and SC's copy of qhyccd.dll at the very earliest testing -- all fine. Then later, my driver or SC didn't have proper coordination due to various updates. I updated the native driver just before the failed testing. That might have created the issue.

I feel that all those qhyccd.dll's floating around are potential problem areas for much more than cooling. It doesn't help matters that the developer of the dll uses virtually meaningless versioning in the dll file. Maybe there's something more shrewd inside the dll for identification. But that seems unlikely with all the problems associated with app mismatches with the qhyccd.dll's. I wonder how many times people are blaming hardware or an app when it's a dll issue.

One quibble that might have been raised before: When SC is using the autocooling, the power level shows 255 (max). It did that when cooling didn't work and also when it did work. Once the temperature hits the setpoint, you KNOW the cooler isn't at max cooling. With the ASCOM driver, SC reports the target temp, current temp and power level at all times. So I'd like to see SC report the correct cooling level in native auto mode (unless the driver is reporting the garbage value).

Sorry for the long post. It's a mix of adrenaline from saving a seemingly-broken camera, and basic nerd-related exercise. Joe

Re: Issues with QHY168C

Posted: Fri Mar 15, 2019 10:52 pm
by admin
Hi,

I understand that this has been a frustrating period for QHY camera owners. For a long period there were no updates to the camera SDK from QHY and then finally they have released a major update a couple of months ago. Since then minor updates have been appearing fairly regularly with long lists of bug fixes against each minor update. I think things are gradually improving but it's safe to say that the dust is still settling a bit from that major update.

I have just downloaded and installed a brand-new version of the software from QHY today and I hope to release a new version of SharpCap with that update in the next few days. Using the only cooled camera that I have from QHY (the 174M), I get correct auto cooling behaviour and the correct report of the cooler power level.

It's vital that each piece of software has its own version of the DLL as sometimes the DLL changes in a way that means that it would cause that failure or crash if you mixed a new version with the older software or the other way round. Usually there are minimal problems in mixing different DLL versions with different driver versions. Copying in a different version of the DLL may often work, but there is no guarantee. The reappearing DLL trick that you see is down to features in the Windows installer system which automatically repairs the application whenever the main program is started.

Cheers, Robin

Re: Issues with QHY168C

Posted: Sat Mar 16, 2019 9:43 am
by turfpit
For anyone copying dll’s around the system, it is advisable to rename the existing dll rather than just overwrite. In the event of things going wrong then a simple rename gives a regression path.

Dave