Ahh - interesting. It is almost as if extended full well mode is "super low conversion gain" mode.

I played around with EFW a bit last night, though without the benefit of your sensor analysis. I had set HCG + EFW and gain 100. With an f/6.5 scope on the Double Cluster, I tried various exposure times, up to 120s. At 120s I still had not saturated any pixels (max ADU ~58000). Of course I have no idea what the e/ADU is for the HCG/EFW combination.

I still get crash on x86-64 but only when using RGB (RAW 16 works fine). The crash happens somewhere in libtoupcam. Incidentally, if I compile directly on my PC, I don't get the RGB crash so it's puzzling. Maybe debian packaging affects some symbols.

Is it possible / a good idea saving temperature and heater status in camera configuration?

If to take image with short exposure (0.01 second) indiserver will instantly send about one hundred XML like thisI don't think this is good
PS: no such problem with long exposures

Good catch. Can you please report this in Touptek latest PR so they might take an action to resolve it?

Hi, do you mean simply write this as comment for PR?

Correct, or create an issue as well.

Hm... I tried to reproduce this with EKos with no success. So it looks like the problem is only when I take shot from my client.

Hi,

Update the recommendation for the best settings by the current version SDK.

Karas said he will later make a Python script that can run sensor analysis under LINUX. It can be used to validate this data set. And get finer discrete values. This data set can now be verified under linux using Pixinsight, and since I'm not a PI expert, if anyone is interested they can follow this tutorial: www.lightvortexastronomy.com/measuring-your-camera-sensor- parameters-automatically-with-pixinsight.html

The current Mode0 recommended settings are as follows.

HFW = On
LCG = On (By threshold AUTO)
LN = On
Gain 177
OFFSET = 700

Reasons Why and How to select：

Slightly less than 1e/ADU to obtain the best sampling, one electron converts one ADU.

Consider a limit capacity of 60ke for 16bit, and a full well of no more than that amount of RMS after deducting the noise component is available.

Consider the loss of dynamic range and keep it above 14.

Consider the noise distribution characteristics, the histogram should be closer to the Gaussian distribution.

Consider pre-addition of voltage to make all histogram values greater than 0.



2023 Jan Toup Ascom Driver （Same file with INDI 3rd）


QHY268M

I recently updated my system and Touptek INDI driver seems to be changed dramatically:
- Now it takes offset between 1 and 31 only
- If does not show parameter for switching between high and low gains
- gain parameter does not switch between low and high gain as it used to be
Looks like now I am supposed to switch between low and high gain using INDI control panel.
Is this expected?
I much prefer the old way of doing things because i was able to switch between low and high gain just by using the gain value.

I've also got the problem with offset being 31 max but I haven't tried gain adjustment yet

Hi everyone
I have the Omegon veTEC571. Connecting using the omegonpro driver, I don't see the offset issue and all the other stuff works too. I wonder if the Omegon and other Touptek re-badged models really do use the same code?
The libraries seem different. Here are the listings built from NOU's scripts for the current stable:

steve@steve-desktop:/usr/lib/x86_64-linux-gnu$ ls -l libtoup*
lrwxrwxrwx 1 root root 16 abr 5 18:45 libtoupcam.so -> libtoupcam.so.53
lrwxrwxrwx 1 root root 22 abr 5 18:45 libtoupcam.so.53 -> libtoupcam.so.53.22376
-rw-r--r-- 1 root root 44632232 may 5 14:19 libtoupcam.so.53.22376

steve@steve-desktop:/usr/lib/x86_64-linux-gnu$ ls -l libomegon*
lrwxrwxrwx 1 root root 21 abr 5 18:44 libomegonprocam.so -> libomegonprocam.so.53
lrwxrwxrwx 1 root root 27 abr 5 18:44 libomegonprocam.so.53 -> libomegonprocam.so.53.22376
-rw-r--r-- 1 root root 21501992 may 5 14:19 libomegonprocam.so.53.22376

Can anyone confirm?
Cheers and clear skies,
Steve