×

INDI Library v1.9.1 Released (26 Jun 2021)

Bi-monthly INDI Library v1.9.1 is released bringing a few new drivers and improvements to existing drivers.

Should alternate read modes work on QHY294M Pro with indi-qhy?

  • Posts: 6
  • Thank you received: 0
I have a new QHY294M-Pro which I am trying to connect through KStars/ECOS (v3.5.1 Stable, Build from Jan 8th 21) with the the latest Indi compiled from the GIT master repository and QHYSDK version 20-12-11-15. Connectivity and general camera control all work well. But the image resolutions that I am getting from the Indi-qhy driver look odd which is what I would like to share here in this forum and hear from others if they might have had similar observations:

For one, I can't seem to get the alternative read mode for the higher pixel resolution supported by the camera to work through Indi and for the other, it isn't clear to me how the overscan areas of the sensor are meant to be supported.

The driver options do let me toggle between the two different read modes. When the camera is switched to the "47M" read mode (read mode = 1) the SDK does seem to report the higher read mode resolution of 8336x5648 px out to the driver. However then it seems that the SDK/driver scales the image resolution back to what seems to be the effective image region of the "11M" (read mode = 0) resolution which is 4164x2795 px. That is then also the resolution I am getting for the downloaded FITS image. The log also indicates this:

2021-02-02T04:04:08: [INFO] GetQHYCCDReadModeResolution in this ReadMode: imageW: 4164 imageH: 2795
2021-02-02T04:04:08: [INFO] GetQHYCCDReadModeResolution in this ReadMode: [ imageW: 8336 > imageEAW: 4164 ] / [ imageH: 5648 > imageEAH: 2795 ]
2021-02-02T04:04:08: [INFO] Read mode updated to 1
2021-02-02T04:04:08: [INFO] GetQHYCCDEffectiveArea: subX :36 subY: 28 subW: 4164 subH: 2795

This seems to be the frame area without overscan area and without optic black area.

In the 11M read mode the resulting image has a final resolution of 4164x2822 px and thus does seem to include the overscan area to the bottom of the frame.

2021-02-02T04:06:59: [INFO] GetQHYCCDReadModeResolution in this ReadMode: imageW: 4164 imageH: 2822
2021-02-02T04:06:59: [INFO] Read mode updated to 0

to compare against recording frames with the different read modes through EZCAP the image resolution I am getting (here by choosing to not ignore the overscan area) for the 11M mode is 4212x2822 px. Thus this includes the overscan area at the bottom of the frame and the optic black area at the left side of the frame. In the 47M mode the frame has a resolution of 8432x5648 px, thus also including overscan and optic black areas.

My thoughts are that this should also be the correct behavior for the indi-qhy driver... Perhaps with an additional driver option to include or ignore the overscan areas?

Another point that caught my eye is that the driver/SDK does not seem to support the amp glow reduction mode which the camera should be able to turn on and off according to the manual for the 294M from the QHY website. This sounds more like a question for the QHY support though.
5 months 4 weeks ago #66837

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 17
Can you enter the read mode 1 and enter the resolution manually to see if it works that way?
5 months 3 weeks ago #66920

Please Log in or Create an account to join the conversation.

  • Posts: 6
  • Thank you received: 0
Yes, I had thought about that, too. But then the SDK will reply with an error.

I believe that this is what you were having in mind:

a) Select read mode = 1



b) Set frame size to some values that should be valid in the extended mode, like this



c) Take a photo



The error which I am getting seems to be coming from the SDK when it tries to set the ROI for the exposure.I'm starting to think that this all is more of an SDK problem and not so much the Indi driver. For what it's worth the SDK comes with this little test application that will connect to the camera directly and take a single frame. It's coming with the source code so it's compilable and I looked at that, too. And that runs into the same problem when I code it to run the camera in read mode = 1 and take a frame bigger than the maximum frame size of read mode = 0. I will ask in the QHY forum.

I did just notice from the screen shots that the driver thinks that my frame offset is at (36,28) where according to my inputs I have it at (0,0). That does more or less looks like a smaller problem within the Indi-qhy code.
5 months 3 weeks ago #66927
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 6
  • Thank you received: 0
OK, it looks like this might be a problem with the driver code rather than with the SDK and it should be possible to fix it in /indi-3rdparty/indi-qhy/qhy_ccd.cpp.

One problem which the QHY support pointed out to me and which I already confirmed in my smoke test is that after a read mode change the camera needs to be re-initialized by calling InitQHYCCD(). In my test I was able switch the camera to 47M mode and acquire the larger frames. The other problem I see is that in order to pass it's sanity check on the user defined resolution the code may need to update the effective frame area (GetQHYCCDEffectiveArea()) after the read mode change and camera re-init instead of doing this first.



I am guessing that the code has to probably more look like this:



Since I already have the code open and the camera connected I will try to update and test the code in ECOS and see if I can get it to work.
5 months 3 weeks ago #66948
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 6
  • Thank you received: 0
Time to create page: 0.939 seconds