Axel Mellinger's profile

Thanks, Wolfgang! Starting with a fresh profile appears to have fixed the problem, at least according the limiting testing I have done with the telescope + mount set up in my basement. (Given the current Michigan weather forecast and my travel schedule, I may not be able to image again before the end of June.)

Here is what I found:

Whenever I am using the old profile, the meridian flip hour angle reverts back to 1° not just when I run a plate solve, but also when I take a single exposure in the focuser module. Also, when I start KStars, the hour angle always shows up as 1°.
With the new profile (all components and optical trains identical to the old profile), the HA no longer reverts to 1° after taking an exposure in the focuser module. And when I quit and re-start KStars, the HA now retains its previous setting.

It looks like something in the old profile did not transfer over properly when I recently upgraded from KStars 3.6.7 to 3.7.0.

Clear skies,

Axel

Read More...

Since updating to Kstars/Ekos 3.7.0 (on a Raspberry Pi 4 running Ubuntu MATE 22.04), I noticed a strange behavior: each time I plate solve in the Alignment module, the "Flip if HA > xx deg" parameter in the Mount module reverts to 1°. See attached movie clip. My mount is an EQ6-R Pro.
I tried purging the mount configuration, but this has no effect. Unfortunately this is more than a cosmetic defect, because such a small angle has caused failed meridian flips in the past.
Has anybody else observed this behavior?

Read More...

Anand, I checked my EQMod Mount settings, and indeed, "Reverse West/East" in the Motion Control tab was checked! No idea how that happened, but after I unchecked that setting, polar alignment works again. Problem solved! Many thanks for pointing me in the right direction.
Axel

Read More...

Same issue here. My equipment:

KStars Version 3.6.6 Stable (Build: 2023-08-01T13:00:35Z)
Raspberry PI 4 (4 GB) with Ubuntu Mate 22.04.3 LTS
Mount: EQ6-R Pro

The "First mount rotation remaining degrees" are increasing instead of decreasing:

[2023-08-19T21:19:56.517 EDT DEBG ][     org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 30
[2023-08-19T21:19:57.591 EDT DEBG ][     org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 30.2626
[2023-08-19T21:19:58.662 EDT DEBG ][     org.kde.kstars.ekos.align] - "First mount rotation remaining degrees:" 32.3222

Logs are attached.

As a work-around, I found that checking the "Manual slew" box and manually slewing to the new position (using Mount Control from the "Mount" tab) lets me complete the polar alignment process.

Clear skies,
Axel

Read More...

Yes, I do periodic backups of my SD card. This way, if a new KStars/Ekos version causes any problems, I can always go back to a working installation.

After inserting the SD card into a card reader, which is plugged into my Linux machine, I run

sudo dd if=/dev/sdX of=backup.img bs=1M status=progress

(replace the "X" in /dev/sdX with the actual drive letter that's shown by the dmesg command after you have inserted your SD card into a card reader.)

Optionally, compress the image with a file compression tool of your choice. (For best compression results, I first delete all FITS files from the SD card and run zerofree on the loopback-mounted SD-card image to fill unused file system blocks with zeros. This brings the backup image size down from an uncompressed 64 GBytes to around 6 GBytes.)

For other operating systems, see here for ways to back up SD cards .

Axel

Read More...

Jasem's PPA provides the latest versions of Kstars/Indi only for currently supported Ubuntu releases. 19.04 reached its end of life in January 2020.

Read More...

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:

Set the "Aborted Job Managment" delay to at least 5 minutes (must be larger than the daily change in astronomical twilight)
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...

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...

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...

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...

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

Basic Information

Gender

About me

Contact Information

State

Country