Using a nightly build in order to get access to a differential slewing fix I need.

I'm frustrated because plate solving via ASTAP or the internal solver isn't functioning. It can work, sometimes. My main problem is I can't translate the logs; talking with Toni Shreiber for the differential slewing issue; he says there is random inputs for sources but that isn't the source of my issues. He didn't elaborate from there.

Jasem, can you look at my logs and tell me what I'm doing wrong?

indilib.org/forum/ekos/14150-sudden-prob...html?start=120#99154

Link to the conversation over there.

Thanks,

Chris,

A good way to debug issue with the internal solver's plate solving is to use the FITS Viewer's solver.
See docs.kde.org/trunk5/en/kstars/kstars/kst...f#fits-viewer-solver in the handbook to describe how to use that.
Also, FYI if you look at the main "Configure KStars" menus, the bottom tab is called "Developer". If you go there and check/apply "Saved Failed Align Images", then fits files for failed alignment is saved (on Linus in the ~/.local/share/kstars/align/failed/ directory).

Given such a fits file, you can load the file into a fits viewer, and (after inspecting to make sure it is a reasonable image, e.g. in focus, "enough" stars) then see if you can get the fitsviewer solver to work, and report back.

BTW, often the issue is incorrect scale or position, so common advice is uncheck "use scale" and "use position". That's worth a try. However, sometimes with minimal stars or some-such you really need the scale. So, my advice is if you're sure of scale (and after trying unsuccessfully with both unchecked) try again with "use scale" checked, the correct scale (in arcseconds/pixel) entered in the box, and "arcseconds/pixel" chosen as the unit.

Hy

drive.google.com/file/d/1XuYre4_OPqZKjK9...EZy/view?usp=sharing


Some examples. I think I got the internal solver to work by adjusting the 'extraction params' for min star area from 10 to 2. I also adjusted min and max size in the middle block to 1 and 25. I turned off use scale and auto update... then adjusted those values for the image scale to what I know them to be (1.47). It seems to be plate solving reliably.

Now, with this particular build it is crashing every 5 pictures. I'll let you know if it's still doing that after this run...

Any idea when your differential fix will be pushed to a stable build?

[2024-02-23T21:38:39.318 CST INFO ][ org.kde.kstars.ekos.guide] - Starting non-guiding dither...
[2024-02-23T21:38:39.319 CST INFO ][ org.kde.kstars.ekos.guide] - Non-guiding dither successful.
[2024-02-23T21:38:39.321 CST FATL ][ default] - ASSERT failure in QList<T>::at: "index out of range", file /usr/include/aarch64-linux-gnu/qt5/QtCore/qlist.h, line 571

Here's the line from the code... it happens after 5 images are taken and it gives me an index out of range..

Yessss ! I finally could success in polar align, whereas that systematically failed before, whatever the method and settings I chose.
Never would have thought to uncheck those.
It is written in the manual, however I did not understand it since it is mentioned that that can happen because of poor alignment of the telescope. Which was not the case for me.

Jean Luc,

It is worth seeing if that now that you have the right scale, re-checking 'use scale' works. I assume it will work, and that it will significantly speed up your plate solves. Again, you should be able to do this debugging with the FITS Viewer's solver tool during the daytime, if you don't want to do it at night with the Align tab.

I'm not sure how scale originally gets screwed up though.
Hy

Also, Jean-Luc, can you please point me to the part of the handbook that was misleading?
Here's one section (in English) I found (and there are a few others too), please let me know if you have suggested changes.
Hy

Hello Hy,
I don't think the doc being faulty. Rather the CKI (Chair-keyboard interface = the user).
I did read (the french translation) many times and read the part about that, but I did not understand it until I read your reply in this post.
I know how difficult and time consuming is making a doc. Especially when the product evolves regularly.
In this case, there are two problems : mastering the hardware / software and the language frontier.
For translations, the translaters must master the hardware / software, the languages subtilities, and be precise enough for the beginners to understand but not too much for not boring neither them nor the experienced users.
Demanding this from volunteers would be quite unfair.
I intend to compare both the english and french docs, and try to find whether this was because of the docs themselves or (more probably) because of me.
It took me only 20 minutes yesterday to achieve polar alignment, modelise the mount bring M51 very near or the cetnre of the field and start aquiring with a very accurate tracking.
Before that, I would have spent (less than 2 minutes for visual polar align and) up to 2 hours to bring the target in the field.