Ah, I was looking at the screenshot at the top left for the last successful solve and the solution parameters. I assume it must have solved at some point or that would be blank.

KStars will tell astrometry do a partly blind solve to start. The first time it runs, the scale is set to zero, so that makes it ignore the scale. After that, it should use the previous solve to refine the scale so it takes less time to solve subsequent images. So yes, if it had a good solve, that updated those boxes, and I do think those solves were accurate based on the comparison you showed.. That should have also update the settings in the astrometry options. Yes I believe they are calculated from the pixel size, focal length etc. I'm pretty sure that the astrometry solution factors into that calculation, but it could also be largely based on other entries in KStars as well. That might be worth investigating if those aren't right. If you want to, you can uncheck the boxes, and take the scale out of the parameters it uses to solve, then see if it solves. Also I saw you were using bpp for the units, I don't have experience with that setting. I usually use aw, or arc second width. Did you try that? Astrometry.net takes a little bit to configure but it is incredibly powerful and once you get it configured well, it works like a charm. There are reasons for why it is used as the engine behind a wide range of plate solving front ends. It works well and works on many systems.

What are the options sent to astrometry.net? I only see a portion of them. Paste the complete generated options.

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?