×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Possible flat calibration issue...

  • Posts: 333
  • Thank you received: 24
Hi,

Is there a known issue with flat calibration and setting the time to infinity?

It is not clear why it happens.

Steps to recreate:

1. Set sub to Flat
2. Set ADU to 12000
3. Set exposure to 1 sec
3. Start capture

Some times the calibration works, sometimes now. Editing the exposure to reset the value and redoing until a value allows it to work, was the work around.

Once the sequence was created and saved, rerunning the sequence still resulted in 2 of the seven filters needing to have exposures played with.

Any ideas?
7 years 1 week ago #15390

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

  • Posts: 158
  • Thank you received: 32
I do not know what camera you use, but with my ASI1600 I had a similar issue where it couldn't figure out the right exposure time for the ADU I wanted. I set the exposure to start at 0.5 seconds and the problem never resurfaced.
7 years 1 week ago #15393

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

I added more debug logging for this feature in the next KStars release so hopeully we'll know what's going on. Basically, after the 2nd capture, it tries to do llsq/polynomial fitting for the data to get the optimal exposure, so something wrong went there. When we have the logs in the future we might know why and fix it.
7 years 1 week ago #15395

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

  • Posts: 333
  • Thank you received: 24
Please find the logs for the flat calibrations. There were at least two filters that went to infinity.
7 years 8 hours ago #15761
Attachments:

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

You attached log for ASI, not Ekos.
7 years 18 minutes ago #15787

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

  • Posts: 486
  • Thank you received: 87
I had those problems too. Yesterday I took flats set the count to 22000 and 0.5s and ekos failed to find the best exposure after some iterations.
I have set it to the lowest possible value (0.001s) and on the second try it worked. From what I have seen in my system, when the defined exposure (0.5s) is higher than the predicted exposure (in my case 0.027s) ekos has some kind of difficulty to find it. When it's lower than expected it works fine, it goes up until it finds the correct one.
In my case I was using an Atik 420M.
Last edit: 6 years 11 months ago by nMAC.
6 years 11 months ago #15794

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

I don't suppose there are Ekos logs around?
6 years 11 months ago #15795

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

  • Posts: 486
  • Thank you received: 87
Yes, I have logs but I don't have access to them right now but I will post them when possible.
Thanks.
6 years 11 months ago #15796

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

  • Posts: 486
  • Thank you received: 87
Well here are my logs on flats capture. You can see on the end of file when I made the capture there is a failure:

2017-03-29T00:19:12.094 - DEBG - Capture: next FLAT exposure is -4150.86
2017-03-29T00:19:12.094 - DEBG - Capture: "Unable to calculate optimal exposure settings, please capture the flats manually."

That's where I set the exposure to 0.001s. And no problems after this.
6 years 11 months ago #15855
Attachments:

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

  • Posts: 158
  • Thank you received: 32

Heh.. Looks like a math mistake. Glad to hear you got it working.
6 years 11 months ago #15860

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

Thanks for the log. This is why I stress on logs because now I identified the issue. General descriptions of the problem can sometimes be next to useless if not accompanied by log. Description + Log = FTW!

So the issue is that at 1 second, the flat image was already saturated and the code didn't deal with saturated case so it was including them in the calculations when it should not. I pushed the fix to Git and might make a release tomorrow in the PPA.
The following user(s) said Thank You: nMAC, Bill
6 years 11 months ago #15871

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

  • Posts: 486
  • Thank you received: 87
Great! Thanks Jasem.
That's why it worked at 0.001s, makes sense.
6 years 11 months ago #15873

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

Time to create page: 0.417 seconds