As 1 deg = 60', 1.7 x 1.2 deg is actually equal to 102' x 60'. If the size of the sensor is w x h and the focal length of the scope is f, then the FOV is given by

FOV = 2*atan(w/2/f) [horizontal] ; 2*atan(h/2/f) [vertical]

And by entering the figures given by @gbeaton we get a FOV of 1.698 x 1.273 deg, which is in line with values reported by Ekos and by online calculators. Now, this value may be a little bit different compared to solved images due to the fact that actual focal length may be slightly different from nominal focal length, see also @kbahey post.

Some questions for @gbeaton:

1. Are you using real hardware or simulators in your test?
2. Did you tried Online solver mode? Do you get the same results (failure)?
3. If you use Load & Slew with a real image instead of Capture & Solve, does anything change?
4. If you manually upload your captured images to astrometry.net, do you get a solution?

@alessio.beltrame, this hobby is going to kill me I guess I was too tired to see that the FOVs were the same. I'll try your suggestions when I get a chance. Weather here is bad and it doesn't get properly dark until after 10pm. I thought solving would help me speed up polar alignment but in fact I have to wait a long time before there is enough contrast in the sky to use it. If I could accurately polar align with it in a few minutes, then its worth it.

@kbahey, unchecking use position seems like it will hinder the solver. What exactly is this option doing?

Here is a tip: If you are not sure about the final focal length, go to Astrometry.net settings and turn Verbose on, then go to Solver Settings and uncheck "Use Scale",. Ekos would not send the calculated scales from the FOV to the solver. After an image solves correctly, you can find the FOV as measured by the solver. From this value, you can calculate your effective focal length that you need to use.

In theory, disabling the two options will hinder the solver. In reality, it does not hinder it much though, provider you are on a regular Intel laptop (I have not tried this with a Raspberry Pi, with a slower CPU).

You can also try uploading the image manually to nova.astrometry.net/upload without any hints or options. After a minute or two, you will have a solution. It is very consistent, and never failed for me.

Disabling the imaging options and position options will force a blind solve (just like you do with the web site above). This is useful if the scope points to the wrong part of the sky for some reason.

So, in summary: do a blind solve, either from the command line, or by disabling Imaging and Position Options. Once you get a focal length from the solver, then enter that under the Mount tab in Ekos, as well as in INDI, then re-enable the Imaging Options, and a FOV will be calculated for you, and you are good to go.

Online capture&solve is working but not polar align. So is WCS required? Because its not enabled in solver options, nor on CCD options, yet the solver complains its missing or not enabled. Turned on WCS and got this - also have position checked and previously correctly guider FL to 176mm: some error certainly due to unaligned guide cam.

2017-07-06T22:59:15 Solution coordinates: RA (15h 14m 41s) DEC (-7° 32' 01") Telescope Coordinates: RA (15h 17m 57s) DEC (-9° 26' 42")
2017-07-06T22:59:15 WCS information updated. Images captured from this point forward shall have valid WCS.
2017-07-06T22:59:15 Solver completed in 61 seconds.

Cool! Now I see the FOV box on the Kstars sky chart.


Then tried Polar align:

2017-07-06T23:09:24 Error parsing parity.
2017-07-06T23:09:21 Uploading file...
2017-07-06T23:09:21 Image received.
2017-07-06T23:09:20 Capturing image...
2017-07-06T23:09:20 Solver timed out
2017-07-06T23:06:23 Upload complete. Waiting for astrometry.net solver to complete...
2017-07-06T23:06:20 Uploading file...
2017-07-06T23:06:20 Image received.
2017-07-06T23:06:19 Capturing image...
2017-07-06T23:06:19 Solver timed out
2017-07-06T23:03:23 Upload complete. Waiting for astrometry.net solver to complete...
2017-07-06T23:03:19 Uploading file...
2017-07-06T23:03:19 Image received.
2017-07-06T23:03:17 Capturing image...
2017-07-06T23:02:29 Clearing mount Alignment Model...

When I went back to the capture&solve, it worked again so something wrong with polar align.

Whoa!!! Offline solver only took 4 seconds!!!:

2017-07-06T23:16:23 Solution coordinates: RA (15h 14m 39s) DEC (-7° 35' 44") Telescope Coordinates: RA (15h 17m 57s) DEC (-9° 26' 42")
2017-07-06T23:16:23 Solver completed in 4 seconds.
2017-07-06T23:16:19 Starting solver...
2017-07-06T23:16:19 Index file index-4204 is missing. Astrometry.net would not be able to adequately solve plates until you install the missing index files. Download the index files from www.astrometry.net
2017-07-06T23:16:19 Image received.
2017-07-06T23:16:18 Capturing image...


But offline polar align does not work either:

2017-07-06T23:21:51 Solver aborted after 52 seconds
2017-07-06T23:20:59 Starting solver...
2017-07-06T23:20:59 Image received.
2017-07-06T23:20:58 Capturing image...
2017-07-06T23:20:58 Solver timed out
2017-07-06T23:17:58 Starting solver...
2017-07-06T23:17:58 Image received.
2017-07-06T23:17:56 Capturing image...
2017-07-06T23:17:50 Clearing mount Alignment Model...

Is Ekos solver using astrometry engine (same as AstroTortilla) ? Because I see a couple of switches that AstroTortilla uses that are not used in Ekos

For exemple :

--sigma 1 : defines the noise tolerance in analysing your captured image for plate solving

-r : sort the stars in order of brightest first, therefore allowing to optimise the plate solving process as it starts with the brightest stars in your image

--objs 100 : to use a maximum of 100 stars for the plate solving (the developers generally recommend between 100 and 200 stars)

Also I noticed that -O and --no-plots are not checked in the "edit solver options" window but appear in the line [Options] under the "Solver Options" section is this by design ?

I can answer a couple of these questions.

Gbeaton, i dont know about any issues with the polar align function, since I use my polar scope, but i can say that sometimes there can be problems plate solving near the pole. It can help to try a couple of locations a little farther from the pole.

Also gbeaton, yes offline solver is often much faster and more reliable than the online one but requires tweaking. Once you get its settings configured well for your system, it can often solve in even less time than the 4 seconds you stated.

Vox45, ekos uses the astrometry.net software which i do think is what astrotortilla uses. As for the missing options, you could try them out and see if they help. Astrometry.net has lots of capabilities and options, no Ekos does not have all of them built in as checkboxes but they can still be used in ekos by typing them in the options line in or tested by running it from the command line.

The -O option is required in Ekos since the -o option overwrites the previous solution files and if that were not included, it would fail to solve the next image since it cannot overwrite. And the noplots option is required since ekos does not use the plots produced and they just take more time to produce.

Thank you for your answer.

(1) "The -O option is required in Ekos since the -o option overwrites the previous solution files and if that were not included"

-> what I meant is that when I open the "edit solver options" the checkbox for the -O is not cheked, yet the option appears in the option line. This is odd and I was wondering if this is to be expected, maybe some kind of refresh needs to happen ?

(2) "Astrometry.net has lots of capabilities and options, no Ekos does not have all of them built in as checkboxes but they can still be used"

-> that is nice to know While I was poking around I noticed that the infobox on the "custom" field in the Solver options says : "additional optional astrometry.net options" so that settles it

I have to say that the more I learn about Ekos/Kstars the more impressed I am ... I think I am a bit of pain in the b**t by asking so many pointed questions but I need to know a lot of the details as I will train some club members on it in a couple of weeks and I'm sure I will be bombarded with the same kind of questions...

Thank you for taking the time to reply !

@gbeaton, @rlancaste

I am also seeing that PAA never completes. It takes the 3rd image, completes the solve, then just hangs there with the 'Capture' button greyed out. Or the entire KStars will crash sometimes. I see this with the CCD simulator and telescope simulator, so not a driver issue.

I reported this here .

Meanwhile, the regular Capture and Solve works fine, with the Sync action, all that works fine.

PAA was working fine until around the 4th of July or so.

Also, I see the same thing regarding WCS: if I disable WCS in the solver options and in INDI, but still the code tries to do it, and the code crashes in a method called loadWCS, which points to where the issue may lie.

The -O option is supposed to be a disabled checkbox that is permanently checked. That one and the noplots option. Is it not that way on your system? I can take a look and see if that was changed recently. You should not be able to uncheck it.

Yes, Jasem made a change to wcs so that it does not always load when an image is loaded, but instead is loaded when needed. This also broke a couple of the methods that I had written, but I have since corrected them. I dont have much experience with the polar alignment helper, maybe Jasem can help.