×

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

Bi-monthly release with minor bug fixes and improvements

Imaging during partly cloudy nights

  • Posts: 15
  • Thank you received: 1
Thanks , clear explanation .
This post should be add to the documentation :)
2 years 7 months ago #74640

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

  • Posts: 225
  • Thank you received: 16
Wolfgang,

I was able to take some pictures last night and run KStars under the debugger (see attached log). The conditions were poor and I imaged too close to the moon, but it gave me a chance to try your settings.  There was no KStars crash.  I don't know if those changes helped... but generally pleased.  Here are some observations:
  • Everything started up fine, but I noticed that capturing starts immediately once guiding starts, ignoring RMS limitations, settle constraints, etc.  This only happens on the first capture.  Not a big deal because as soon as the guiding RMS records a larger number (which it did until it settled down), it aborted capture.
  • The parameters suggested by you worked well!  They should be a "best practice".  My only surprise is that the guiding RMS capture limitations are measure for each individual guide capture... not the accumulated RMS reported in the guide tab.
  • The auto focus at 120 minutes was successful!  This had been a problem earlier.
  • My only big problem was during the meridian flip.  The system successfully flipped the mount, but was unable to plate solve.  The images it was taking have a problem.  I attached a screen print.  I don't understand what's happening, as it worked fine on the original solve, focus, etc.  Anyway, the solver aborted.  The scheduler continued to work.  Unfortunately, the OTA was pointed incorrectly and off the object... so won't stack.
  • The object went behind trees around 2:17 am, but the system handled it fine and shut down/parked once the Alt hit the minimum.

So... the solver issue was the only big problem.  Hopefully, the logs/image will help solve the issue.  I sent all of this to Jasem on StellarMate support, but wanted tol also post this information on this forum to provide some feedback to others.

Thank you,

Ron Clanton
  

File Attachment:

File Name: kstars_log...0-01.zip
File Size:5,382 KB

 
Last edit: 2 years 7 months ago by Ron Clanton.
2 years 7 months ago #74641
Attachments:

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

  • Posts: 1185
  • Thank you received: 370
Hi Ron,
the log does not show any details why aligning failed, it simply ran into a timeout. In your screenshot, there is a big black stripe in your image. I wouldn't be surprised if that is the reason. And maybe you should increase the exposure time to 3-5 sec and the gain to 100 to increase the lightness of stars.

Regarding capture start: there is an additional option so that you can set the guiding limit that needs to be kept for capture start. But generally, why shouldn't capturing start immediately when guiding is running? If there is a guiding deviation, it could abort and wait for a better guiding.
2 years 7 months ago #74656

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

  • Posts: 225
  • Thank you received: 16
Yes, the big stripe is likely the reason. However, that is strange as I've never encountered any problems with those settings over the last few months. In fact, those were the settings for the first alignment that worked. I also got the strip on the autofocus that happened a few minutes before the meridian flip. So something change during the session. It almost looks like a connection problem... weird.

I do have the guide limit for the capture start. However, it starts capturing before the first guiding correction is calculated. It's not a big deal. I had a lot of aborts in the beginning until guiding settled down.

The only thing I didn't see is where the guiding failed five times, the scheduled job should have shut down... then restarted after the time set in the scheduler. Did you see any signs of that happening? It should have happened after 2:17 am when the target went behind the trees.

Thanks again for the setting recommendations... game changer!

Ron
2 years 7 months ago #74657

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

  • Posts: 1185
  • Thank you received: 370
Hi Ron,
there are plenty of lost star events in the log, but re-acquiring was always so fast that guiding never aborted. Typically, re-acquiring succeeded after a couple of seconds and did not reach the star lost timeout.
Wolfgang
2 years 7 months ago #74660

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

  • Posts: 225
  • Thank you received: 16
Wolfgang,

After about 2:17 the object went behind some trees and there was no guiding for a couple of hours until shutdown. However, the job never aborted (that I can tell). I wonder if I'm missing a setting?

Thanks,

Ron
2 years 7 months ago #74667

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

  • Posts: 1185
  • Thank you received: 370
No idea how massive your trees are, but the last guiding entry is:
[2021-08-19T04:25:23.517 EDT DEBG ][   org.kde.kstars.ekos.capture] - Guiding state changed from "Reacquiring" to "Guiding"

That means, the last time that the guiding module recognized a guiding star is in the same second when the Scheduler aborted the job and started the shutdown.
The following user(s) said Thank You: Ron Clanton
2 years 7 months ago #74670

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

  • Posts: 225
  • Thank you received: 16
Very interesting. The trees are massive and I think only two images were captured during that time (space between a couple of trees?). But doesn't that mean that it was trying to find a star prior to this message? So why didn't it abort the job and continue to retry based on the settings?

My only concern is that if that didn't cause a job abort, then would a mere passing cloud? What I really want in this case is for the job to abort, then restart and realign, which will solve the problem of drifting from the target.

I'll keep trying!

Thanks,

Ron
2 years 7 months ago #74671

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

  • Posts: 1185
  • Thank you received: 370
As I said above, it happens quite frequently starting at 02:20:10.166 EDT that the guiding star is lost and a couple of seconds later some (maybe other) star is recognized. This happens too fast, it never takes that long that the star lost timeout intervenes.
2 years 7 months ago #74672

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

  • Posts: 225
  • Thank you received: 16
Must be a hot pixel... because there's no way that you can see the sky through that forest.

Maybe I'll try being awake next time to see what's going on... yuck! LOL!

Ron
2 years 7 months ago #74673

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

  • Posts: 183
  • Thank you received: 23
Thanks Wolfgang - this is a great solution to a problem that's been bugging me. I have to admit I've started testing Voyager recently because I needed a solution that was more robust in how it handled pausing and restarting due to weather (wind, rain and clouds).

Is there a mechanism by which Ekos could be made to only pause versus exit when it encounters certain conditions? (perhaps it can do this but I cant se how)
Last edit: 2 years 7 months ago by Paul Muller.
2 years 7 months ago #74728

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

  • Posts: 1185
  • Thank you received: 370
Good point, Ron, there were discussions about this here in the past. The conclusion was to leave this better outside in the INDI watchdog and have only basic support in EKOS. The main point was robustness so that the observatory will react even if Kstars runs into trouble or even crashed.
2 years 7 months ago #74735

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

Time to create page: 0.516 seconds