Norman replied to the topic 'Focus Introduction YouTube video' in the forum. 7 months ago

Hi John, awesome! Thats exactly what I was looking for. Stood away from adaptive so far and haven't noticed this yet.
I will try that tonight :)

Many thanks, Norman

Read More...

Norman replied to the topic 'Focus Introduction YouTube video' in the forum. 7 months ago

Extremely helpful and a superb presentation, many many thanks!

I am struggling a lot at the moment with a new RASA 11" and its 4 micron CFZ on my rig.
With your detailed explanations I can eliminate a lot of guesswork and optimize my current approach.

Looking forward to upcoming videos!

Read More...

Norman replied to the topic 'disable Optical Train popup window?' in the forum. 7 months ago

Ok cool, I think that helped. It pops up only once now after connecting to the server :)
Many thanks!

Read More...

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

Read More...

Norman created a new topic ' disable Optical Train popup window?' in the forum. 7 months ago

Hi!

Every time I connect to the indiserver with kstars I get several popup windows from the optical train menu.
This is extremely annoying as they appear with delays and steal window focus.
Is there any way to disable this automatic popup or am I doing anything wrong so that the window pops up over and over again?

Many thanks, Norman

Read More...

Hi!

I nailed this further down a bit after a few hours testing.
For all my tests I kept the inidlib 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

Read More...

Hi Kirill,

on my system it looks exactly the same:

apt list libcfitsio-dev libgps-dev 2>&1 | grep installed
libcfitsio-dev/oldstable,now 3.490-3 arm64 [installed]
libgps-dev/oldstable,now 3.22-4 arm64 [installed]

I don't think its a problem with those libraries.
The scope INDI::FITSRecord is not found. Looks like this definition is missing in the headers that your build process found.

Did you check your cmake output for possible errors? Like in this:
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Release ~/src/indi-3rdparty/libqhy

Maybe the build process is not pulling the right headers from the newly built indilib.
Before I did my build I completely removed all packages for INDI from my system so that I don't get any collisions with older stuff.
I would also recommend to install into /usr/local/ e.g. to prevent future problems with installed packages.

Best regards, Norman

Read More...

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 :)

Read More...

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

Read More...

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.

Read More...

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 635 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

Read More...