I'm not sure what's the problem exactly... at any rate, I set setlocale(LC_NUMERIC,"C"); when saving FITS header values. Maybe that will help. But I don't have the sources for the ATIK driver, when do you set the exposure duration?

I'm setting it just in StartExposure(). I don't think it is a locale issue, then number is completely wrong. BTW, I believe that cfitsio uses "C" locale anyway, slovak locale uses "," instead of "." as well and I never noticed this problem before.

What is the difference between lights, darks and flats in Ekos? It seems that only flats are corrupted...

I take flats all the time with QSI without any issues. I have no idea what could be causing this.

Hi guys,

I'll try to take flats with different exposures & ADUs to narrow this issue.

Hi,
I just look into the code and noticed that ImageExtention is defined as a MAXINDIBLOBFMT sized array but in the SetImegeextention method, the strncpy uses MAXINDINAME as max size. Furthermore ImageExtention is defined just before the ImageExposure number vector in the header file. This suggests an overflow but I do not have looked at how ImageExtention is used.
Maybe this could be investigated.

Jean-Luc.

Hi Jean-Luc, both MAXINDIBLOBFMT and MAXINDINAME are defined as 64. So this is potential issue, but not this time. Peter

Hi,

here a few runs with different ADU/exposure times. Looks like the exposure time is divided by 10, than the number eventually becomes numericaly instable , sometimes even negative.

---

3x ADU20 5 sec exposure flats:

01 EXPTIME 5.
02 EXPTIME 0.5
03 EXPTIME 1.25

5x ADU20 10sec exposure flats:

01 EXPTIME 10.
02 EXPTIME 1.
03 EXPTIME 0.1
04 EXPTIME 0.009999999..
05 EXPTIME 0.027279999..

20x ADU33 15sec exposure flats:

01 EXPTIME 15.
02 EXPTIME 1.5
03 EXPTIME 0.150000005960464
04 EXPTIME 0.586045980453491
05 EXPTIME 0.290841996669769
06 EXPTIME 0.029084200039506
07 EXPTIME 15.
08 EXPTIME 1.5
09 EXPTIME 0.150000005960464
10 EXPTIME 0.0149999996647239
11 EXPTIME 0.00150000001303852
12 EXPTIME 0.000150000007124618
13 EXPTIME -1.58333337306976
14 EXPTIME -1.60000002384186
15 EXPTIME -1.61666667461395
16 EXPTIME -1.63333332538605
17 EXPTIME -1.64999997615814
18 EXPTIME -1.66666662693024
19 EXPTIME -1.68333327770233
20 EXPTIME -1.70000004768372

13x ADU40 15 sec exposure flats:

01 EXPTIME 15.
02 EXPTIME 1.5
03 EXPTIME 0.150000005960464
04 EXPTIME 0.68189400434494
05 EXPTIME 15.
06 EXPTIME 1.5
07 EXPTIME 0.150000005960464
08 EXPTIME 0.0149999996647239
09 EXPTIME 0.0413363017141819
10 EXPTIME 0.0239087007939816
11 EXPTIME 0.0238080993294716
12 EXPTIME 0.0236179996281862
13 EXPTIME 0.0235965996980667

hold on ... are you using Ekos ADU % to calculate optimal exposure time for a particular ADU %? If you see the ADU % to anything but 0, it will try to automatically figure out the exposure time required to get to that ADU. I think this could be causing it, let me investigate Ekos algorithm.

Ok, so it is the ADU flat algorithm, it was only tested on the simulator before. Can you send me a serious of 10 flats with different ADUs? That would help me a bit in the testing, thanks!

You mean something like this:

10 x flat with 20ADU
10 x flat with 30ADU
10 x flat with 40ADU etc ??

No,

1 Flat 5% ADU
1 Flat 10% ADU
...etc
1 Flat 95% ADU

Don't use Ekos ADU %, LEAVE it as ZERO, and experiment with exposure times until you get the desired ADU.

So I updated INDI::CCD to check for exposure limits, it was accepting negative value before!! Furthermore, I updated Ekos to fail if the calculation does not yield useful results. So don't send me anything yet, tomorrow both kstars-bleeding and INDI will be updated in the PPA. Please update and then start KStars from the console/terminal, and take flats again with a particular ADU % in Ekos, then send me the KStars log from the terminal, it should display the ADU & Exposure settings along with the calculated slope in each go. Send me the log and the captured fits so I can investigate further.