Axel Mellinger created a new topic ' Shutdown procedure and "Aborted Job Management" Gotcha' in the forum. 5 days ago

This morning I noticed an interesting behavior of the shutdown procedure. After a night of taking O-III and S-II frames, I was surprised to see that the sequence queue did not show the jobs as "completed", but as "Aborted" (O-III) and "Idle" (S-II). Yet, the images were there.



After going through the logs, I am beginning to understand what happened. After taking all 85 O-III frames and 80 out of 85 S-II frames, the scheduler reached astronomical twilight at 05:09 local time:
[2020-08-08T05:08:02.601 EDT INFO ][           org.kde.kstars.fits] - Loading FITS file  "/home/axel/astro/IC_1396/Light/SII/IC_1396_Light_SII_120_secs_122.fits"
[2020-08-08T05:08:02.603 EDT INFO ][   org.kde.kstars.ekos.capture] - "Received image 80 out of 85."
[2020-08-08T05:08:02.685 EDT INFO ][   org.kde.kstars.ekos.capture] - "Capturing 120.000-second SII image..."
[2020-08-08T05:08:02.786 EDT INFO ][           org.kde.kstars.indi] - ZWO CCD ASI1600MM Pro :  "[INFO] Taking a 120 seconds frame... "
[2020-08-08T05:09:02.815 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'IC 1396' is now approaching astronomical twilight rise limit at Sat Aug 8 05:09:00 2020 (0 minutes safety margin), marking idle."
[2020-08-08T05:09:02.824 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'IC 1396' is stopping guiding..."
[2020-08-08T05:09:02.825 EDT INFO ][   org.kde.kstars.ekos.capture] - "Autoguiding stopped. Aborting..."
Thus, the job was aborted. However, in the scheduler, the "Aborted Job Management" was set to "Queue" with a 0 s delay:

Thus, the job was immediately restarted. At that time, apparently, the astronomical twilight limit was re-calculated. Since it was a new day (the original job started before midnight), and since the nights are getting longer, the new twilight was 05:12. Thus, the scheduler thought it had 3 minutes left before dawn and re-started the job. At 05:12, job execution was aborted again, and this time the mount was properly parked:
[2020-08-08T05:10:16.279 EDT INFO ][   org.kde.kstars.ekos.capture] - "Job requires 120.000-second OIII images, has 0/85 frames captured and will be processed."
[2020-08-08T05:10:16.284 EDT INFO ][   org.kde.kstars.ekos.capture] - "Capturing 120.000-second OIII image..."
[2020-08-08T05:10:16.535 EDT INFO ][           org.kde.kstars.indi] - ZWO CCD ASI1600MM Pro :  "[INFO] Taking a 120 seconds frame... "
[2020-08-08T05:10:40.969 EDT INFO ][     org.kde.kstars.ekos.guide] - "Lost track of the guide star. Searching for guide stars..."
[2020-08-08T05:10:45.132 EDT INFO ][     org.kde.kstars.ekos.guide] - "Autoguiding started."
[2020-08-08T05:12:01.677 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'IC 1396' is now approaching astronomical twilight rise limit at Sat Aug 8 05:12:00 2020 (0 minutes safety margin), marking idle."
[2020-08-08T05:12:01.684 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'IC 1396' is stopping guiding..."
[2020-08-08T05:12:03.678 EDT INFO ][ org.kde.kstars.ekos.scheduler] - Starting shutdown process...
[2020-08-08T05:12:03.678 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Warming up CCD..."
[2020-08-08T05:12:03.727 EDT INFO ][   org.kde.kstars.ekos.capture] - "Cooler is off"

Looking at all the scheduler's settings, I think there are two that could have prevented this sequence of events:
  1. Set the "Aborted Job Managment" delay to at least 5 minutes (must be larger than the daily change in astronomical twilight)
  2. A few minutes of Pre-dawn time in the scheduler options (it was set to zero). I also should have turned on "Remember Job Progress", so that the sequence would continue with the aborted S-II sequence, rather than re-start O-III:

Am I on the right track? Any thoughts?

Axel

Read More...

Axel Mellinger replied to the topic 'Alignment / Sync failed Astroberry 2.0.2' in the forum. 1 month ago

Interesting. Your version seems to be similar to the one from the stable release , which (at least for me) did not have any alignment issues. (It did have an autofocus issue , which is why I switched to a more recent version).

I compiled KStars using the instructions on GitHub . If you change the install prefix in the cmake command from

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo ../kstars
to
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=RelWithDebInfo ../kstars
you should be able to have the new KStars version side by side with the one from Astroberry.

Axel

Read More...

Axel Mellinger replied to the topic 'Alignment / Sync failed Astroberry 2.0.2' in the forum. 1 month ago

I wonder if you are experiencing the same issue reported here and here . Do you know which KStars / INDI version Astroberry 2.0.2 uses? I fixed my problem by compiling the KStars code from GitHub (commit 446481d5fb485ec6437c43bb6bcc1c5b76adedfd).

Axel

Read More...

Axel Mellinger replied to the topic 'align fails to slew mount: latest git' in the forum. 1 month ago

I did one full night of imaging with the latest KStars from GitHub (commit 446481d5fb485ec6437c43bb6bcc1c5b76adedfd) and INDI 1.8.5 from the stable PPA. My EQ6-R mount slewed and aligned to four different targets without problems.
Axel

Read More...

Axel Mellinger replied to the topic 'align fails to slew mount: latest git' in the forum. 1 month ago

I have been following this thread, since I ran into the same problem. Here what I did tonight:

  • Compiled KStars from the latest github source (commit db1a82113a54b2e568ee4a259053b88d4473379e)
  • Left INDI at the last stable version (1.8.5) from the ppa

I then did a few "Capture & Solve" runs to different targets (Delta Cyg, M 13, M 57, M 27), and everything is working fine for now.
My system: Raspberry Pi 4 (4 GB) running Ubuntu 20.04 with Mate desktop. Log is attached.

Could this indicate that the issue may be with INDI rather than KStars?

Axel

Read More...

Axel Mellinger replied to the topic 'Warnings during Autofocus' in the forum. 2 months ago

I'm wondering the same thing. I recently had the issue that the automatic autofocus upon a filter change did not work , and my logs showed the message

Ignoring Received FITS CCD1 as it has the wrong capture mode 1

When I updated Kstars and INDI from the stable ppa:mutlaqja/ppa to the nightly builds ppa:mutlaqja/indinightly, I got the autofocus back. However, the logs still show the same message. This is with an ASI1600MM Pro camera and the ZWO EFW.

Read More...

A quick update in case anyone experienced similar problems: Updating Kstars from 6:3.4.2+202004251749~ubuntu19.10.1 to nightly build 6:3.4.3+202006171130~ubuntu19.10.1 (from ppa:mutlaqja/indinightly) solved the problem; autofocus upon a filter change works again.

Axel

Read More...

Hi,
I have been using Ekos on a Raspberry Pi 4 (running Ubuntu+Mate desktop) for about half a year. My cameras are an ASI1600MM Pro with electronic filter wheel and an ASI290 MM mini (guider). Recently I encountered a very annoying problem with the autofocus:

  • I am running the scheduler; the filters are set to "Auto Focus", i.e. autofocus runs each time the filter changes.
  • Upon a filter change, Ekos pretends to capture and download images as part of the focusing process. However, the image in the "Focuser" tab is not updated, and neither are the HFR readings. As a result, autofocusing eventually fails.
  • However, the autofocus process runs fine when started manually from the Focuser tab (by clicking the "Autofocus" button).
The log file says:
[2020-05-20T23:35:59.929 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'M108+Owl' guiding is in progress."
[2020-05-20T23:35:59.938 EDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'M108+Owl' capture is in progress..."
[2020-05-20T23:35:59.951 EDT INFO ][   org.kde.kstars.ekos.capture] - "Job requires 60.000-second Red images, has 0/30 frames captured and will be processed."
[2020-05-20T23:35:59.964 EDT INFO ][           org.kde.kstars.indi] - ASI EFW :  "[INFO] Setting current filter to slot 2 "
[2020-05-20T23:36:01.945 EDT INFO ][     org.kde.kstars.ekos.focus] - "Capturing image..."
[2020-05-20T23:36:05.905 EDT WARN ][   org.kde.kstars.ekos.capture] - Ignoring Received FITS CCD1 as it has the wrong capture mode 1
[2020-05-20T23:36:05.906 EDT INFO ][     org.kde.kstars.ekos.focus] - "Image received."
[2020-05-20T23:36:05.915 EDT INFO ][     org.kde.kstars.ekos.focus] - "Please wait until image capture is complete..."
[2020-05-20T23:36:05.918 EDT INFO ][     org.kde.kstars.ekos.guide] - "Guiding suspended."
[2020-05-20T23:36:05.921 EDT INFO ][     org.kde.kstars.ekos.focus] - "Focusing outward by 1,000 steps..."
[2020-05-20T23:36:06.003 EDT INFO ][           org.kde.kstars.indi] - MoonLite :  "[INFO] Focuser is moving to position 23383 "
[2020-05-20T23:36:07.631 EDT INFO ][     org.kde.kstars.ekos.focus] - "Focusing inward by 500 steps..."
[2020-05-20T23:36:07.636 EDT INFO ][           org.kde.kstars.indi] - MoonLite :  "[INFO] Focuser reached requested position. "
[2020-05-20T23:36:07.676 EDT INFO ][           org.kde.kstars.indi] - MoonLite :  "[INFO] Focuser is moving to position 22883 "
[2020-05-20T23:36:08.715 EDT INFO ][           org.kde.kstars.indi] - MoonLite :  "[INFO] Focuser reached requested position. "
[2020-05-20T23:36:10.623 EDT INFO ][     org.kde.kstars.ekos.focus] - "Capturing image..."
[2020-05-20T23:36:14.409 EDT WARN ][   org.kde.kstars.ekos.capture] - Ignoring Received FITS CCD1 as it has the wrong capture mode 1
[2020-05-20T23:36:14.410 EDT INFO ][     org.kde.kstars.ekos.focus] - "Image received."
(The full log file can be seen here .)

The relevant message appears to be "Ignoring Received FITS CCD1 as it has the wrong capture mode 1". Any idea what might be causing this?

Axel

Read More...