Hello,

since I switched to libqhy SDK 23.7.16 I see the following problem in my images:




Its not related to readmode or compression or file format.
It also does not appear in SDK 22.7.23.

The affected pixel rows are 6355 to 6388 (starting from 1) and span exactly 34 pixel rows. so I suspect its a problem with handling the overscan area which is 34 pixel rows wide.
Strange thing is, the pixels are "dimmed" and not zero.

Has anyone else seen this problem yet?

Many thanks, Norman

I just want to add that these black pixel rows are not the overscan area.
Its part of the regular image area within the standard 9576 x 6388 resolution.

I think it's best to send this information to QHY directly. We can only update SDK but we can't make any changes or fixes to it, it has to be done by QHY.

Hi Jasem,

I am already in contact with Baader and they talked to QHY.
Can you tell me the version of the source code you built the SDK 23.7.16 with?
I remember the version number 23.7.16 comes from your build date and is not related to QHY.
So we have kind of a reference they can work with.

Many thanks, Norman

This is getting strange,

I built all SDK version back to v23.02.18 and see the same problem everytime.

Everything earlier than this commit-ID will not build against indilib-203 without errors:

commit 37e72a8c586a0e154b40f064e98c8b0231667e65
Author: Jasem Mutlaq <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Sat Feb 18 21:40:33 2023 +0300

QHY SDK v23.02.18

I first need to find the matching indilib commit to match the 3rd-party commit above to be able to build a reference where this problem above presumably does not appear. I only checked against my old astroberry repo with SDK 22.7.23 so far.

Until I can't proove that 22.7.23 build from source doesn't show this overscan problem I cannot exclude possible other reasons.

Its also hard to believe that noone else seems to have this problem reported for over a year.
So I guess theres someting else going on.

But clear sky tonight after a long time, so its imaging time now

INDI QHY SDK is built directly from master, not a released version. So the released SDK is indeed the snapshot of the SDK source at at day.

Hi!

I nailed this further down a bit after a few hours testing.
For all my tests I kept the indilib and indi_qhy_ccd driver at these current git versions:

indi-qhy version origin/master:
commit 84b47a8d1b2766c9015ff54cb2404ce60ea14693
Author: Jasem Mutlaq <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Tue Jul 18 12:34:07 2023 +0300

indilib version origin/master:
commit f90db4e8cf87e3d990cb2b85900eeaab2e3fc428
Author: Jasem Mutlaq <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Thu Aug 31 12:33:16 2023 +0300

I only had to relink indi_qhy_ccd for the different major version numbers 20, 21, 22,23 of libqhy.
This was the only change in the test environment while I iterated through the libqhy-SDK versions.

The firmware image in the QHY600 camera was always on 23.7.16 for all my tests.
I can pretty much say that the problem described was not introduced by the camera firmware but by the SDK Libraries.
On the client side I had kstars-3.6.6 with indilib-2.0.3. I tested also XISF versus FITS compessed and uncompressed without any differences.

This is the latest error free SDK Version I have tested:
libqhy 22.11.9 git commit id: 995dd8bb21ee719ab85faed38e1dc1817c5d4d62 from Wed Nov 9 17:54:08 2022 +0300

The next version with libqhy 23.02.18 and git commit id: 37e72a8c586a0e154b40f064e98c8b0231667e65 from Sat Feb 18 21:40:33 2023 +0300
introduced the problem with the darkened pixel rows as described above.

As from my understanding and what Jasem told, the directory indi-3rdparty/libqhy contains only data from QHY and its not touched during linking the libraries.
But I don't know if this is enough to approach QHY now with this problem.
It could also be that QHY introduced changes between SDK 22.11.9 and 23.02.18 which must be reflected in driver code.
But I dont have access to release-notes or similar information.

If thats not the case I would say its on QHYs part now to analyze this deeper.
Any opinions are very welcome.

Best regards, Norman

I have seen this in my system as well. I traced it down to a USB3 issue where I was running an ASI guide camera.

I moved the ASI from the USB3 bus to the USB2.0 bus and the issue went away.

At least on my system.

Thanks for the feedback!
Thats a very good point. I will do some more tests with different bandwidth settings and different USB ports.

Best regards, Norman