The setting in Kstars are correct. Again, no idea what is causing it to constantly fail solves.

Turn on verbose logging and check "Alignment" in the logs. What does it say?

I'm having a similar issue. No matter what I set scales to, the command run by ekos when doing an off-line plate solve uses the wrong scales. If I run the same command manually in a shell but with the correct scales, the solve works fine. The "options" shown under "solver options" are the correct options, but ekos still runs the command with the wrong scale (according to the long). Not even the units are the same as set in options (I choose aw, log says -u app).
This is with the CCD and telescope simulators, btw.

logs?

I agree, the user should be able to just override these settings if they know the scale.

Krno:

I haven't had a chance to setup again. I'm trying to do a load & solve using the CCD simulator with the same setting as my DSLR. I'll see if I can get it to work.

Interestingly, using the simulators and "upload and solve" the images that were not solving night before last are now solving, sorta.

The positions are off, by over 1.5 arcmin in RA and DEC.

Attached is a screenshot showing the nova.astrometry.net solve, the All sky plate solver solve (astrometry.net) vs Kstars solve.

The pixel scale is also still off in Kstars.

I'm guessing this may have been an issue with the mount location being off. I don't think it was 30 degrees off. Not possible.

A few weeks ago I unticked Use Scale and ever since plate solving has been working very well. I had some plate solving issues where the wrong scale was used with a DSLR and that led to solving problems that could be solved with disabling Use Scale. I now have disabled this always, even with my ASI1600MM for which solving works fine when Use Scale is enabled as well.


HTH, Wouter

Turning off 'Use scale' seems for me to be the only way to prevent it from using the wrong '-L' and '-H' argument to 'solve_field'. Even when the two scales say '0', some other values are used when running 'solve_field'. So turning off 'Use scale' also seems to work here in a few test cases. Running from the command line with the correct scales seems to be faster, though. ~400s in ekos without "use scale" and ~100s from the command line with the correct scales.

Another odd thing.... If I run solve_field from the command line simultaneous with a solve in ekos and press 'Stop' in ekos, it will stop both the one in ekos AND the one in the command line. Does the stop button use some kind of killall or something? That may lead to odd things in some cases...

Ok, so for clarification (and I just changed the GUI to reflect that). Everything you see is in JNow, not J2000.

There is something odd about your image, your FOV is showing as 0x0.. did you switch telescopes perhaps and didn't solve that one?

Aren't there advantages to having coordinates in J2000 for consistency across platforms that do the conversion internally? Can we get either both at once or a choice?

Here is what is happening in my case: kstars uses the scale information found in the fits file to generate the options, over writing anything I manually set in the options dialogue. It seems to be done in Align::startSolving in align.cpp where getSolverOptionsFromFITS is called. The scaled reported in the log matches exactly 0.9 and 1.1 time the pixel scale in the fits header and clearing FOCALLEN and SCALE in the fits header results in a correct solve (but without any scale information...). Maybe there should be an options to either use the fits header (if available) or always use the user set options? My fits header was containing (slightly) wrong information leading to the (slightly) wrong image scale being used and there seems to be no way to manually overwrite this from ekos....

Everything is in JNow because that what most mounts report, so when you compare mount and solution coordinates, you need to be looking at the same epoch.