Could you try clicking on the sync button in the Celestron telescope control window that watalota showed? That may force the mount to pick up the coordinates that it moved to.
In addition to Nou's suggestion, you may want to try with alternative star selection definitions that exclude more small stars. I have had a problem in the past when I was too far off focus to begin with due to rapid cooling, and my larger out of focus stars were being interpreted as smaller multiple stars. With this situation it doesn't do well as there is no trend.
I also find that with the hyperbola fitting the weighting option helps.
Hm, lot's of possibilities for this. I use a Nikon Z7 dslr and currently don't have problems. Things you've probably already checked:
1) The black frame is weird. Sounds like there's a mismatch between what the camera is set to capture and Kstars. Perhaps KStars is set to record an image that is larger than what the camera captures in its current mode?
2) If you do a straight capture using the camera using fits rather than native, does it return an expected image with stars and the correct dimensions?
3) I have never tried using the camera's native format for storage/transfer. Seems that there is definitely something different going on as you have experienced. I would tend to trust the fits format as being the "normal" way.
3) High enough ISO and long enough exposure to get stars using the dslr? I had an issue for a while when focusing where as the solver approached perfect focus it couldn't find any stars and would give up.
With the release of the updated libASICamera2 from ZWO, I'm going to mark this topic as solved.
Thank you all!
I get the same thing with Kstars 3.6.0 stable on Monterey 12.5 on a MacStudio.
Thread 1:: com.apple.rosetta.exceptionserver 0 runtime 0x7ff7ffc2a944 0x7ff7ffc26000 + 18756 1 runtime 0x7ff7ffc383e0 0x7ff7ffc26000 + 74720 2 runtime 0x7ff7ffc39e58 0x7ff7ffc26000 + 81496 Thread 2:: com.apple.CFSocket.private 0 ??? 0x7ff8a4bfe940 ??? 1 libsystem_kernel.dylib 0x7ff814734d5a __select + 10 2 CoreFoundation 0x7ff8148562db __CFSocketManager + 643 3 libsystem_pthread.dylib 0x7ff8147694e1 _pthread_start + 125 4 libsystem_pthread.dylib 0x7ff814764f6b thread_start + 15 Thread 3:: QDBusConnectionManager 0 ??? 0x7ff8a4bfe940 ??? 1 libsystem_kernel.dylib 0x7ff8147330aa poll + 10 2 QtCore 0x113dba00e qt_safe_poll(pollfd*, unsigned int, timespec const*) + 94 3 QtCore 0x113dbb85c QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 812 4 QtCore 0x113d58d17 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 471 5 QtCore 0x113b972fc QThread::exec() + 140 6 QtDBus 0x10fd3bf93 QDBusConnectionManager::run() + 19 7 QtCore 0x113b9820a QThreadPrivate::start(void*) + 330 8 libsystem_pthread.dylib 0x7ff8147694e1 _pthread_start + 125 9 libsystem_pthread.dylib 0x7ff814764f6b thread_start + 15 etc.
Also in identifying possible differences, this MacStudio has 64 G RAM.
Hi, I just tried. binary-factory.kde.org/job/KStars_Release_macos/ and it launches and runs the simulators OK for me on my M1 MacStudio.
I did give KStars full disk access, but I'm not sure that was a pre-requisite.
Those options are now accessed via a button on the right half of the window, towards the bottom. I don't have it open to provide the exact name
I get Value 0x8010203.
on Ubuntu 20.04.4 LTS
Linux 4.9.312-125 aarch64. arm64
For me, with a fresh github download of everything from the nightly (assuming I did this correctly), It still crashes and restarts continuously this morning.
As I had things configured yesterday, it was working (off of the old library), so I assume I'm running the new ASI library.
How exactly do I check the version of that I'm using?
OK, so with yesterday's code base I'm still crashing on the Oroid N2 Ubuntu 20.04.4 LTS aarch64 arm64
Here are the ekosdebugger kstars and indl logs, in case someone can make sense of them
p.s. I can workaround this crash if I use Phd2 for guiding and don't load the ZWO driver in kstars.
Gilles is correct I'm on an Odroid N2 as well (ARM RPi4 compatible).