Hi
Have you tried ASTAP? No fuss, it uses just a single catalogue file, works with the default settings (or any other settings for that matter), is fast and solves every time.
Cheers and clear skies,
Steve

Steve,

I have downloaded all the index files and will test again once dark enough.

If it continues to fail I will try using ASTAP.

It used to be an option to select but now all I get is stellarsolver.

Paul

Okay, I now have both the 2Mass and Tycho2/Gaia index Catalogues and it continues to fail.

The symptom is that it solves the first time, almost instantly, but never again until I restart kstars.

I installed ASTAP, as suggested, and it does the same thing,as seen below.

I loaded a FITS file and it solved it quickly, but a second attempt always fails.

2023-01-01T13:56:06 Solver Failed.
2023-01-01T13:56:00 Solving with blind image position...
2023-01-01T13:55:47 Solver aborted after 0.65 seconds.
2023-01-01T13:55:47 Capturing image...
2023-01-01T13:55:46 Solving with blind image scale...
2023-01-01T13:55:46 Image received.
2023-01-01T13:55:41 Capturing image...
2023-01-01T13:55:40 Image received.
2023-01-01T13:55:35 Capturing image...
2023-01-01T13:55:21 Slewing to target coordinates: RA (18h 09m 39s) DEC (-43° 43' 14").
2023-01-01T13:55:21 Solution coordinates: RA (18h 09m 39s) DEC (-43° 43' 14") Telescope Coordinates: RA (01h 17m 55s) DEC (-90° 00' 00") Target Coordinates: RA (23h 56m 00s) DEC ( 180° 00' 00")
2023-01-01T13:55:21 WCS information updated. Images captured from this point forward shall have valid WCS.
2023-01-01T13:55:21 Solver RA (272.00722) DEC (-43.72376) Orientation (269.32476) Pixel Scale (1.58864) Parity (neg)
2023-01-01T13:55:21 Solver completed after 2.15 seconds.
2023-01-01T13:54:39 World Coordinate System (WCS) is enabled.

It is entirely possible that something is not set up correctly, but it was working until I did a new build about two months ago.

I have noticed that the telescope details have been moved from the profile to the alignment page, under Train: Optical Trains - kstars and this may have something to do with it. After more investigation I found that the wrong telescope configuration has been selected and even though there is a Field of View difference it is not major.

Two things seem to be common, it frequently wants to do a blind solve and it always works the first time.

I am going to try this again when I next get a clear night.

Paul

Hi Paul,

I was playing with this using scope and ccd simulator and 10sec 'exposures'
I found that if the number of stars found was too few it would not solve, would go into blind solve
Now 'number of stars' was controlled by changing the FOV with ccd pixel resolution X/Y values.

For astrometry stellar-solver I only had index-4206 loaded even though in the config it says 'required' for 4207/4208/4209 also.

Gene

Gene,

There are two things to consider here

1) The first time it always solves correctly
2) I use the same settings on a year old version and it works flawlessly

Paul

Hi Paul,

Which two versions?

Could you share a FIT's that exhibits this?

Gene

Gene,

I don't have a FITS file and the logs don't seem to show up anything, but I don't have them all enabled.

I also didn't have any issues until a build in November, but I cannot recall the date, but it has been happening with all builds since.

It is under Raspberry Pi OS 64 bit 2022-12-31.

The working version is a build on Raspbery Pi OS 32 bit 2022-02-04.

I may be wrong, but It appears to be a programming issue since there were no configuration changes when it first failed, although I have tried lots of changes since.

The problem is that it doesn;t get to astronomical darkness until about 10:30pm and so there is little time to test it as I want to actually collect data, before I swap over to the working version.

Paul

HI Paul,

For the version, Kstars main screen->Help->About Kstars
The Version is at top and BuildDate is below "Desktop Planetarium"

Is INDI the same on both or also build versions different?
indiserver -V

You have the same astrometry files on both the good and bad versions?
/usr/share/astrometry

Yes, I have seen where it works first time and fails on subsequent, always with the 'blind solve' messages.

Gene

Gene,

The version dates were both obtained from the About Kstars window; ignoring the time.

I have both running Local ASTAP with H18.

The problem happens with internal solver and ASTAP.

INDI is different on each version - it was the version available at the time I did the builds - which are now 10 months apart.

On the assumption this would be fixed, I have done rebuilds about half a dozen times over the last two months, some with a complete build and others incremental.

I have also gone through all the alignment settings and found the only one that is defferent is Align - Align Options Profile Editor - Conv FWHM which is 2 on the older 32bit working version but 1 on the current 64bit failing version.

There are a few new settings Thresh Multiple - 2, Thresh Offset - 0 and Conv Filter - Guassian.

indiserver -V
32 bit
2023-01-03T02:10:21: startup: indiserver -V
Usage: indiserver [options] driver [driver ...]
Purpose: server for local and remote INDI drivers
INDI Library: 1.9.5
Code v1.9.4-17-g7df8ca6d0. Protocol 1.7.

64 bit
2023-01-03T03:02:24: startup: indiserver -V
Usage: indiserver [options] driver [driver ...]
Purpose: server for local and remote INDI drivers
INDI Library: 1.9.9
Code v1.9.9-35-g307881967. Protocol 1.7.



Paul

Hi Paul,

In the directory /usr/share/astrometry, do you have the same files on both systems? What index's are loaded there?

Sorry if I seem to be pedantic about the version but on the Kstars 'About' I see a 'Version'


The Kstars GIT shows these update dates:
invent.kde.org/education/kstars/-/blob/master/ChangeLog

You are listing 12/31 as a build date for Kstar's?
It is under Raspberry Pi OS 64 bit 2022-12-31.

The working version is a build on Raspbery Pi OS 32 bit 2022-02-04.

Your 2/4/22 date would have source from
3.5.7

I am running 3.6.0 with last change
3.6.0 (Contact):
5764593a0 2022-07-28 Yuri Chornoivan

I do agree something is broken.

Hi Paul,

You mentioned the FWHM setting is different from the working to the non-working.

I played with most of the settings and can get it to fail or not fail based on individual or combination settings for:
BINing on capture page
MIN-area
CONV-fwhm
R-min

Next I took the /tmp FIT's file generated and fed it manually into stellar-solver, no problems solving
solve-field --overwrite --scale-low 1 --scale-high 3 --scale-units arcsecperpix --ra 252 --dec 45.4 --radius 20 --objs 160 --no-plots --use-sextractor --scale-low 1 --scale-high 3 ./solver75b2eb09713047d589f5dbaf2b38601a.fits

log-odds ratio 131.147 (9.04427e+56), 23 match, 0 conflict, 4 distractors, 64 index.
RA,Dec = (252.544,45.4208), pixel scale 1.19321 arcsec/pix.
Hit/miss: Hit/miss: ++++++-+++++++++++++++-+--+(best)++++
Field 1: solved with index index-4204-10.fits.

Gene

Gene,

I am not running a stable version in either case, that is why I keep many versions to allow me to keep working when things fail.

So, the version is whatever was available from the repository at the date of the build.

I have also noticed that a new Option has appeared under StellarSolver Options - Automatic and Manual rotator control.

This was selected even though I did not do it and even though I have no rotator, and I have now deselected it to see if it has any impact.

Paul