Resolved after I upgraded to this morning's release:
Unpacking kstars-bleeding (6:3.6.0+202208280917~ubuntu22.04.1) over (6:3.6.0+202208270719~ubuntu22.04.1) ...
Yes, I noticed. But your procedure did not fix the issue on my side.
I made the decision to perform a full install of my system with Ubuntu 22.
Now, it is even worse, kstars cannot even start:
Call to writableLocation without an application-based location.
Icon theme "elementary" not found.
org.kde.kstars: Welcome to KStars 3.6.0 Stable
org.kde.kstars: Build: 2022-08-27T07:19:13Z
org.kde.kstars: OS: "ubuntu"
org.kde.kstars: API: "x86_64-little_endian-lp64"
org.kde.kstars: Arch: "x86_64"
org.kde.kstars: Kernel Type: "linux"
org.kde.kstars: Kernel Version: "5.15.0-43-generic"
org.kde.kstars: Qt Version: 5.15.3
org.kde.kstars: Processing "unnamedstars.dat" , HTMesh Level 3
org.kde.kstars: Sky Mesh Size: 512
org.kde.kstars: Loaded DSO catalog file: "unnamedstars.dat"
org.kde.kstars: "Star HD20,794 not found."
org.kde.kstars: "Star HD98,230 not found."
org.kde.kstars: Loaded DSO catalogs.
org.kde.kstars: Loading asteroids
terminate called after throwing an instance of 'std::runtime_error'
what(): Could not open file.
Aborted (core dumped)
I tried with version 3.6.0: same result.
Here is the output of ekos debugger:
Thread 20 "ExtractorSolver" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffabfff700 (LWP 1856)] 0x00007ffff1479a8c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #0 0x00007ffff1479a8c in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #1 0x00007ffff38c72eb in InternalExtractorSolver::runSEPExtractor() () at /usr/lib/x86_64-linux-gnu/libstellarsolver.so.2 #2 0x00007ffff38c9107 in InternalExtractorSolver::run() () at /usr/lib/x86_64-linux-gnu/libstellarsolver.so.2 #3 0x00007ffff148217d in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00007ffff3ba76db in start_thread (arg=0x7fffabfff700) at pthread_create.c:463 #5 0x00007ffff01a361f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
I upgraded to the latest stable versions of indi/kstars.
Now, the app is crashing every time the Image viewer displays the incoming image.
I reproduce using the simulators.
kstars 3.5.9 stable Build: 2022-06-13T06:24:40Z
Aug 21 16:38:03 florian-U36SD kernel: ExtractorSolver: segfault at 7f23ac3e16c8 ip 00007f23abd45a8c sp 00007f23694c9ad0 error 7 in libQt5Core.so.5.9.5[7f23abca200c8 ip 00007f23abd45a8c sp 00007f23694c9ad0 error 7 in libQt5Core.so.5.9.5[7f23abca2000+53b000]
Thank you for any help
I have the same devices (WATEC + stk1160) and I can successfully open the stream in ekos using directly V4L2 CCD.
However, I cannot take single captures (my goal is to perform astrometry), even when selecting stack: Additive option.
It says: "Absolute exposure duration control is undefined and tacking is not supported".
Did you manage to make it work on your side?
Thank you and clear skies
I tried again tonight, and it seems in my case, it was just due to bad polar alignment.
Tonight I am getting the same weird behavior as you described.
The east calibration is using the wrong direction, using both st4 or direct pulses, using phd guiding or ekos internal guider.
Sending manual orders works fine.
I changed the gemini2 battery today because it was depleted.
Still have no clue on your side?
I connected Ekos to the AZ GTi mount successfully, but the goto actions seem irrelevant.
For example, when moving only in altitude, it also moves in azimuth (is it using equatorial mode?).
When connecting with the Android app, it does say Alt mode.
Thank you and clear skies!
On my side, I am using the notifications to launch a small java program playing a mp3 file.
This warns me when the sequence stopped, and I can snooze it by closing the app (which you cannot do if you run the sound directly).
However, I did not find the appropriate event to use.
For example, when I stop the sequence manually, the alarm is triggered.
dmsummers wrote: @Alex, If you use a Pegasus PowerBox, or V2, or any other sensor that reports temperature via "WEATHER_TEMPERATURE", (i.e. if you see temperature reported in the dome tab), then you will likely be able to use the autofocus delta-T feature that florian mentions.
If your focus issue is indeed due to the temperature, I think it could be solved by the feature I recently developed : trigger autofocus on temperature change. It uses the focuser probe, if available, to compare the last focus temperature to the current temperature, and triggers the autofocus in case it reaches the specified limit.
The feature should be delivered in the next release, but you can test it with the nightly.
How could it be possible to have drift if you are guiding?
I followed the instructions from here:
Here is the merge request: