## QHY 294c

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

### Re: QHY 294c

Hi,

On lots of brands of camera, it's possible to ask whether the camera has finished the exposure and then fetch the new image once you know the exposure is complete. If you end up spending too long (much longer than expected) waiting for the exposure to complete you can take steps to reset the exposure or reset the camera and keep things going. Unfortunately this isn't possible with the current way that the qhy SDK works, since there is no way to ask if the current frame is complete yet. Hopefully there will be a new update to the SDK in the coming weeks or months that will enable me to add this sort of safety net for the qhy cameras which would mean that they would recover much more gracefully from an occasional failed frame.

Cheers, Robin

Stargazer101
Posts: 1
Joined: Sat Dec 07, 2019 10:49 pm

### Re: QHY 294c

I have same issue, Bought new QHy294c and have latest drivers and Sharp cap and I'm not getting a USB traffic adjustment slider. just the DDR buffer tab I,m only getting 0.4 fps at max frame rate.

gagaboul
Posts: 2
Joined: Sun Feb 09, 2020 5:36 pm

### Re: QHY 294c

Same here USB Traffic control is missing for my QHY294C.

Because the lack of control, I can't throttle download speed on my light computer in my observatory...

Capturing < 100ms will cause VNC connection to slow down or even halt and many frames are dropped. Settings DDR buffer helps a bit, sometimes, but seems like useless in this situation.

dghent
Posts: 5
Joined: Thu Mar 26, 2020 4:48 am

### Re: QHY 294c

Hey Robin, I've a QHY294C as well that never seems to get past the sensor analysis test. In the time since other posts in this thread, QHY has improved the SDK somewhat, and in the most recent combination of the USB and SDK, there is now USB speed control for this model, which Shapcap dutifully picks up on, so that's no problem.

I would really be interested in getting sensor analysis to grok the 294C, or at least understand the pathology behind it getting itself stuck right at the end of the sensor linearity tests. Dimmer light sources tend to get the test further, but no matter what, it seems that there is something about this camera that the test logic eventually just can't get past.

Log that contains 2 failed test runs is linked below. The first one was with my flat panel at about 20% illumination. It failed pretty early on. I cut the flat panel illumination down to 10% for 2nd run, and it got much farther along but eventually croaked with the same complaint.

https://gist.github.com/daleghent/ca24f ... d37937d8c9

dghent
Posts: 5
Joined: Thu Mar 26, 2020 4:48 am

### Re: QHY 294c

gagaboul wrote:
Sun Feb 09, 2020 5:54 pm
Same here USB Traffic control is missing for my QHY294C.

Because the lack of control, I can't throttle download speed on my light computer in my observatory...
USB Speed control was only recently added by QHY. To get it on the 294, you need both an updated SDK (which Sharpcap does have) but also an updated QHY USB driver. You can get that from here:

https://www.qhyccd.com/index.php?m=cont ... =141&id=62

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

### Re: QHY 294c

Hi,

Can you retry with the very latest version of SharpCap? In the latest version I have added an extra phase that does a rough measurement of the camera's gain response early in the measurement procedure to ensure that it doesn't try to measure to wide a gain range which can lead to all sorts of problems later on. I think the latest version should also give better guidance at choosing the right light level too.

Cheers, Robin

dghent
Posts: 5
Joined: Thu Mar 26, 2020 4:48 am

### Re: QHY 294c

Thanks, Robin. I updated and re-ran the test. It didn't succeed, but this time failed in determining the gain range. I dumped the log as an additional file in the above github gist link.

The thing I did notice, though, was that during the gain range test, it spun its wheels and croaked when gain = 1500. 1500 on this camera is where the sensor (IMX294) switches from low gain to high gain mode. If you have a DR or read noise graph for the ZWO analog of this camera, the ASI294MC-Pro, you'll see the tell-tale step in the DR and noise graphs where the sensor switches gain modes. The test doesn't seem to have an issue with the ZWO camera at that point, though... but the coincidence seems a little noteworthy.

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

### Re: QHY 294c

Hi,

Trimming the log down to the essentials, I found this which I think illustrates the problem with the camera.

Code: Select all

Adjusting exposure, current is 0.6043, target is 0.65+/-0.025 (pedestal = 0),  changing from 168.28ms to 174.64ms
Adjusting exposure, current is 0.6049, target is 0.65+/-0.025 (pedestal = 0),  changing from 174.64ms to 181.15ms
Adjusting exposure, current is 0.6043, target is 0.65+/-0.025 (pedestal = 0),  changing from 181.15ms to 188.00ms
Adjusting exposure, current is 0.8885, target is 0.65+/-0.025 (pedestal = 0),  changing from 188.00ms to 176.76ms

SharpCap is trying to adjust the exposure to get a histogram peak at about 0.65 (65%). You can see that the first two changes that SharpCap makes have no effect – increasing the exposure from 168.28ms up to 181.15 ms seems to do nothing to the brightness of the image, then the next increase to 188 ms has a massive effect and overshoots the target, so then SharpCap decides to reduce the exposure again to try and hit the target and the whole thing goes round in a loop.

My suspicion is that the exposure control doesn't run smoothly – in other words for at least some values of the exposure making a small change to the exposure has no effect on the image until you reach some threshold value when the image will jump in brightness. If this is the case then sensor analysis is probably almost impossible, as many of the calculation rely on the exposure being accurate.

A couple of things I can suggest to try – firstly if your camera has the option to force it into still mode, try changing that option to see if it affects how the exposure works. Secondly you can try testing to see if the exposure show steps manually by showing the histogram and gradually changing the exposure value and seeing if it responds smoothly or with jumps.

Cheers, Robin

dghent
Posts: 5
Joined: Thu Mar 26, 2020 4:48 am

### Re: QHY 294c

Interesting, it feels like we're getting somewhere.

I tried switching to single frame mode, but that causes SharpCap to crash in GetQHYCCDSingleFrame() with a memory violation. The crash uploader uploaded it as crash #97568

Your hunch about single frame vs. stream mode is a good one because I know behavior with other camera models, certainly in terms of which CONTROL_ features are available, differ between the modes and I've spotted mentions in SDK patch notes in the past which indicated fixes being applied to certain camera models because of inconsistent results across these modes. It's not unreasonable to think that exposure behavior could differ here, as well.

I did try stepping the exposure times up and down, mimicking the exposure times in the snippet of log that you pulled out. Starting at 168ms, I progressed to 174ms, then 181ms. I didn't discern any change in histogram across these three values. But when I went to 188ms, there was a large jump. I then tried this test at different gains. The behavior repeated itself regardless of the gain, with identical behavior at gain=800 and gain=1800 in addition to gain=1500.

I then searched out the range of exposure time values that this camera was stuck in. The problem begins at exposure time of 124ms, and ends at 184ms. At 185ms the histogram jumps, which explains why we saw the jump when going from 181ms to 188ms. So there is a range of 50ms where the exposure doesn't actually change. I guess the sensor test falls into this unexpected hole.

I made a screen capture video of the exercise here:

http://i.imgur.com/DKpNv8C.mp4