Issues with QHY168C

A place to report problems and bugs in SharpCap
Forum rules

Please include the following details in any bug report:

* Version of SharpCap
* Camera and other hardware being user
* Operating system version
* Contents of the SharpCap log after the problem has occurred.
[If SharpCap crashes, please send the bug report when prompted instead of including the log]
Posts: 2861
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Issues with QHY168C

Hi,

Glad to hear that the camera is now operational and that the cooling works properly with this version of the SDK I will keep and I out for the issues you are noticing when changing resolution colour space (there is yet another version of the SDK that has been released by qhy in the last few days so maybe that will bring more improvements when I get some time to include that).

Cheers, Robin

iamhondo
Posts: 14
Joined: Thu Oct 05, 2017 11:27 pm

Re: Issues with QHY168C

I spent about 90 minutes with the camera and SharpCap 3.2 build 5967 this afternoon. The previous camera cooler issue seems 100% resolved. But I encountered problems with switching color spaces between RAW16, RAW8 and RGB24.

The problem shows up in different ways depending on exposure length.

Here's what happened with very short (.2 second) exposures:
1) Most color space switches worked fine.
2) About 20-30% of color space switches started showing all black images (ABI). I watched as many as 200 ABIs. It seems perpetual.
3) The anomaly can be fixed by a different tricks such as "Close camera" then select QHY168c. But "Reconnect camera" did not fix the problem.

Here's what happened with longer exposures (7 seconds):
1) Almost all color space switches triggered a problem. (Maybe 100%?)
2) The frame progress bar in the lower right rolled past the target 7s exposure. The count-up value was >7 and the count-down value eventually went negative. They respectively climbed and dropped -- apparently indefinitely.
3) The frame count/period data just showed 0 frames while the progress numbers continued to change.
4) The screen image freezes with the most recently displayed image.
5) The only recourse is to cycle the camera connection or exit and restart the app.

The odd frame progress bar overrun also occurs when the camera is initially connected (if 7s was the previous exposure length). However, at app startup, SC seems to "catch" the overrun and then resets itself at about 13s. That results in normal images and rational progress numbers. When there's a color space change, SC seems to miss the overrun.

I didn't see any other functions and settings cause problems. I did Live Stacks, snapshots, ROI changes, and switch on/off the debayering. Those actions were normal.

If you never change the color space, the setup could be used for photography. But the color space switching is troubling.

I'm open to other tests or trying a new build whenever it's ready.

Also, my PC specs are attached. It's a mini-pc but the cpu loads were never an issue and otherwise it's no weaker than the average laptop.
Attachments
Annotation 2019-03-24 153137 K1 specs.png (27.25 KiB) Viewed 468 times

Posts: 2861
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Issues with QHY168C

Hi,

I've seen similar problems in the past with qhy and other brand cameras and they are caused by trying to push the USB settings too far. For some reason the problem often occurs with longer exposures than were shorter exposures. I would suggest the normal tricks for troubleshooting USB issues to see if any of those help – particularly turning up the USB speed control to maximum for your camera (the qhy oddly that sets the minimum frame rate), trying different USB ports, eliminating any cable extensions or hubs, and finally using a USB 2 cable in place a USB 3 cable.

I can't guarantee that these will help but I have seen the sort of changes resolve this type of issue many times in the past.

Cheers, Robin

eseavey
Posts: 51
Joined: Thu Jan 18, 2018 3:39 pm

Re: Issues with QHY168C

I am used to seeing the counter go one full exposure before the new frame goes through. So for example, if I set the exposure to 30 seconds and change the gain from 3 to 6, I will have to wait out the remaining number of seconds of the exposure plus 30 seconds before it updates the new frame. During that time the countdown goes negative -30 before the new frame updates. However, now I have been seeing this go on much longer and seems to be stuck when I use ROI, and this is new. Restarting sharpcap and/or unplugging the camera got the camera running again, as I mentioned in my other post. I notified Bruce Morrell here in the US, and he notified Dr. Qui about all these problems.
Hopefully the issues will be resolved soon... before the new moon...

iamhondo
Posts: 14
Joined: Thu Oct 05, 2017 11:27 pm

Re: Issues with QHY168C

I saw the new build, 5973, so I thought I'd go back to some testing with my QHY168c. From my tests I don't see a change or improvement from the previously tested build. ROI changes, color space changes, and shutter exposure changes cause the same problems. In one demonstrative session, I started up the camera in SC, then switched the color space from RAW8 to RAW16 and the system locked into the "perpetual exposure" mode. In earlier sessions I had debayering turned on and sometimes used RGB24 as a destination color space. But for today's session I preferred to eliminate RGB24 and forced debayering as potential issues. Unfortunately, that provided no respite.

I also tested using USB2 as was suggested but the faults were consistent regardless of USB2 or USB3.

Two things notably perplexed me: As eseavey reported, control changes that force a new exposure seem to trigger an overly long exposure before they "reset" properly to the newest value. Why the exposure countdown timer ever goes negative mystifies me. Shouldn't a negative countdown timer always suggest a logic error?

The second item is an entry in the log from the above mentioned demonstrative session. The log reports:

Code: Select all

.....StartPreview() :: Starting Preview on QHY168C, 4952x3288, Bayer_RGGB, 16bits
But as I mentioned, I have forced debayering turned off and only used RAW8 and RAW16 color spaces. The display is monochrome with the telltale debayer crosshatch, but as I read that long entry, it looks like the preview is starting with some form of debayer support. (Or maybe I'm over-interpreting the log entry.)

Joe

Posts: 2861
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Issues with QHY168C

Hi Joe,

You are reading too much into the log file entry – SharpCap is just logging that it knows that the camera is a colour camera with a Bayer matrix, and that information is important because it will eventually get saved in the output file when you capture something. Whether you tell SharpCap to perform the debayering operation before displaying the images is a separate thing.

The negative countdown timer implies that the frame is overdue – for instance if you set a frame time of 10 seconds and it is now being 15 seconds since the frame with requested then the timer will display -5.

Unfortunately without a similar model of camera to test on its difficult to be sure what the cause of the extended exposure times is. I think I may need to add more logging to the area of the application concerned with fetching frames from the qhy camera to see if I get enough information to understand what is going on.

Cheers, Robin

iamhondo
Posts: 14
Joined: Thu Oct 05, 2017 11:27 pm

Re: Issues with QHY168C

I should have a little more "astronomy fiddling" time over the next week to 10 days after this weekend. If you want to post a log-heavy version of SC, I'll be able to exercise it and pass you the log. (Are there startup flags to influence/control the log density?)

Also, I looked for a script option to add a log entry. If it's there, I missed it. It would be nice via a script or with a user-built button to add a long entry to explain what the user was trying to do, or what the user saw, etc.

Clear skies,
Joe

Posts: 2861
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Issues with QHY168C

Hi Joe,

There is an option at the bottom of the first page of the options that increases the amount of logging which is useful if you are having problems. Probably best not to leave it on permanently but for trying to track down an issue it is handy.

There is currently not a way to log from scripting, but is such a simple thing that I will add it in the next release of SharpCap.

Cheers, Robin

iamhondo
Posts: 14
Joined: Thu Oct 05, 2017 11:27 pm

Re: Issues with QHY168C

I found the 5986 build. Earlier, I found and installed a newer 168c driver from QHY. The filename suggests a 2019-03-27 origin date. (The latest QHY drivers don't report any version information in the Programs and Features cpl. The installer file details show a 0.0.0.0 version. So only the installer filename leaks any information about the driver vintage.)

I cranked up my camera and rumbled around. The same nuisances are present: Runaway exposures with changes to ROI, color space, and debayering.

I attached a basic log of a session with a trivial color space switch from RAW16 to RGB24 (with some embedded annotations). I can record a log with the "extra information" setting if you think that would help. I presume that the ROI and debayer runaway exposures follow the same pattern as the color space switch. But if you think individual logs (regular or supersized) are useful, I can create those. I don't want to flood you with unhelpful logs, so your guidance is welcome.

Regards,
Joe
Attachments
Log_2019-04-04T16_29_42-11260.log

Posts: 2861
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Issues with QHY168C

Hi Joe,

One thing that has occurred to me is that there is an option on the qhy cameras to force them to use still image mode rather than video mode when capturing frames (not all camera support this, but I suspect yours will). It may be worth trying this option to see if it helps counteract the problem of runaway frames.

Cheers, Robin

Who is online

Users browsing this forum: No registered users and 1 guest