Incorrect/different sensor size on QHY-600M

[archer1960]

Here is a log file from 14155.

[admin]

Hi,

thanks - that log led me to work out that there was a second block of overscan handling code that I had forgotten about that wasn't obeying the new option. I've corrected that now, so that all the handling of overscan is done in a consistent way and that will be in next week's update.

cheers,

Robin

[archer1960]

Thank you!

[archer1960]

14165 still seems to be showing the issue.

[admin]

Hi,

OK, thanks for testing - the new log reveals that the camera is not advertising that it supports changing the overscan setting at any point (at least not at any point when SharpCap is asking about it). Because of that, SharpCap is not sending any overscan related commands to the camera. I looked back at the old code and that sent 'ignore overscan=on' regardless of support for it in some circumstances, but the outcome in terms of image size is still the same.

I will try to send you a test version of the QHY camera DLL from SharpCap that completely ignores whether the camera claims it does not support overscan control and we will see if that does anything, but I am not really too hopeful

cheers,

Robin

[archer1960]

Is the SDK supposed to advertise those capabilities? Should I contact QHY about this?

[admin]

Hi,

not really - the SDK only briefly documents the functions like those related to overscan, so even working out how they should work is trial and error.

However, I think we may have been sidetracked here by thinking about the overscan ignore in the SDK. I have looked again at the logs and I can see that SharpCap is able to recover both resolution possibilities for your camera, so maybe the problem is that I have misinterpreted the (meager) documentation for the SDK in this area. I have an idea that might resolve this (or maybe not).

cheers,

Robin

[admin]

Hi,

I was hoping that the 'EffectiveArea' that I get from the SDK might be the key to the mystery - on your camera it looks like this might specify the image excluding overscan area and the numbers in terms of size/position of the effective area match up with the full sensor area. So I tested with my QHY294PRO and the numbers that come back from effective area are either all zeros or make no sense (effective width + offset bigger than sensor width, etc)... Grrrr...

Still, I had another look at your log and noticed something interesting - when you go into still mode, it records the resolution as 9576x6388, but with non zero pan/tilt offsets. That hints that the full resolution in still mode is actually the 9600x6422, but that SharpCap is keeping the resolution 9576x6388 when changing from live to still mode as that is the resolution before switching to still mode. So, if you use the latest code and put the camera into still mode, can you then pick 9600x6422 from the resolutions list?

cheers,

Robin

[archer1960]

I am always in Still mode; I never use Live View (unless it starts in LV behind the scenes and then switches modes without telling me). When I drop down the image size box, I see the 9600x6422, but when I click on it, it still goes to 9576x6388, and 9600x6422 then disappears from the drop-down. And yes, 9600x6422 is the full sensor resolution, and is what I get when I shoot with Voyager, with the thin black edges at the left and bottom.

[admin]

Hi,

OK, I think I can see what might cause that and I can hopefully fix it. What I am concerned about is how that might interact binning, since I don't have a way to test how the SDK responds when doing those sorts of setup steps if binning is enabled. I think the QHY SDK is probably the most complex to work with as it has the addition of multiple read modes and the calibration area/resolution change between live and still to worry about. ZWO, PlayerOne, ToupTek, etc, hide a lot of that complexity from the software developer, which makes them easier to work with...

cheers,

Robin