Plate Solve doesn't work SC4 (yes, I used the search function already)

[GoFraRo]

Hi Robin,
my post went into Nirwana again and I don't know why. Try it again...

https://nova.astrometry.net/user_images ... #annotated

Don't be confused about the position. But this was my last attempt and the mount already in park position.
I tried every combination of settings related to exp, gain, offset, resolution, format, binning etc. No success.
As you can see from the link above, nova.astrometry was able to solve it.

Digging into the installation and looking deeper into the logfile I can see, that SC is calling local astrometry directly, rather than using the solver interface of ASPS, AstroTortilla, etc. I assume, those one are used only as front end interface for standalone solving and as index-file manager. Isn't it ?
This means, from my understanding, that communication is directly between SC and (local)astrometry.

And yes, the test button works.

Do you think a reinstallation of ASPS, or of a different solver would fix it ?

Regards

Gottfried

[GoFraRo]

Hi Robin,

I forgot to attach the files from my (successful) attempt with ASPS.
I used Fitswork just to save the png file in fits-format ( no further processing).

I figured out that despite the given FL of 120mm of the scope, astrometry calculates a FL of 128mm. Because I have set the FL in SC to 120, I made another test with both FLs, using the very helpful Folder Monitor Cam and the previous fits-file. And yes, in both cases, plate solve was successful.
Because the fits-file is slightly brighter, around 700 sources has been detected.
Then I tried the original png-file, and with detected 61 sources, the solve was surprisingly successfully completed.
What seems strange, when using the original png-file as input to ASPS or nova.astrometry, 530 sources will be detected, while after a recapture with the FMCam, only 61 sources remain. I have attached both pics with the attending txt file for comparising.

My conclusion, there is something during a regular session, that influences the plate solving. To circle it in, I have to wait for cs and the sky doesn't look very promising for the next coming days/nights.

Regards
Gottfried

[admin]

Hi,

thanks for posting the logs and the images - one thing that worries me is that the command being used for plate solving in your first log is

Code: Select all

solve-field -b /etc/astrometry/backend.cfg  --sigma 20 -r --objs 100 --no-plots -N none -L 1,83322067260742 -H 2,74983100891113 -u degwidth -D /tmp/dd432315-845e-49ef-898d-00f09acd5118 /tmp/dd432315-845e-49ef-898d-00f09acd5118/frame.png

Note that the -L and -H options are formatted with a ',' for the decimal separator. I have no idea if that use of the ',' in place of the '.' is properly supported by the plate solving engine scripts. If not, the field of view may be incorrect, leading to some of the problems. The documentation I can find indicates that it *should* be OK as it is, but it is still a possibility.

As you noted, SharpCap talks direct to the astrometry.net local backend (and as shown above, you can find the commands used in the log). This gives you the chance to capture the image that SharpCap saves to the cygwin temp directory and the command used and then try out different variations (sigma, scale, etc) on the same image to work out what the key parameters are to getting things to work - I would be keen to hear any results that you have.

As to the different number of stars, that could be down to the image being 8 bit or 16 bit - I have seen reduced star counts in 8 bit images as low brightness detail (or noise) is lost in the conversion to 8 bit.

I will have a play with your uploaded file to see if I can get any useful information out of trying to plate solve it.

cheers,

Robin

[admin]

Hmm,

so if I run the solve-field command on your image with the ',' changed to '.' then I get 61 sources found and it works quickly. If I leave the ',' or use -L 1 -H 2, which I think is the result if the decimal separator is not handled correctly, then I get a failure to solve.

Can you run a Cygwin command prompt and show the output you get from running the 'locale' command - I get

Code: Select all

$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_ALL=

cheers,

Robin

[GoFraRo]

Just checked the SC-log of my successful recapture-attempt from this morning.

Code: Select all

Astrotortilla plate solve command is: solve-field -b /etc/astrometry/backend.cfg  --sigma 20 -r --objs 100 --no-plots -N none -L 0,1 -H 20 -u degwidth -D /tmp/6e516401-b41e-4090-8f7f-ad4d35844080 /tmp/6e516401-b41e-4090-8f7f-ad4d35844080/frame.png

The locale command shows

Code: Select all

C:\USERS\PC\APPDATA\LOCAL\ASTROM~1\BIN>locale
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

Thx a lot for your effort
Gottfried

[admin]

Hi,

Okay, so it does look like it may be the confusion of ',' and '.' for the decimal separator that is causing the problem.

The successful plate solving run was without a focal length set up, so SharpCap specified '-L 0,1 -H 20' as the range of scales. This will be interpreted as from zero to 20 (the ',1' bit of 0,1 will be ignored).

Also, the locale set is the 'C' locale which is a default US english like locale that uses '.' for the decimal separator, etc.

I will try changing SharpCap to ignore the country settings of your PC when formatting the scale limits - hopefully that will fix the problem.

cheers,

Robin

[GoFraRo]

Hi Robin,

I'm digging deeper into the subject by performing some tests.

- the decimal delimiter "." is only used in GB and US
- I changed the delimiter in the Win settings from "," to ".". the -L and -H are now separated by "." as I can see in the SC log-file after running the virtual cam and initiating plate solve.
- I changed to "locale" settings of cygwin by overwriting the .profile .bash.... etc. files. This doesn't have an influence.
- Depending on the Win settings, SC uses "," or ".".
- Unfortunately I cannot perform a livetest due to massive clouds, all tests done so far with the virtual cam.
- If it works, this might be a workaround (at least for me). I'm using the WinPad for camera and mount control only.

I wish a nice and relaxing weekend
Gottfried

[admin]

Hi Gottfried,

my assumption is right now that by default cygwin uses a US locale ('.') even if your machine is set to use ','. I have made a change to the code to always use the '.' in the commands to the plate solving engine - lets see if that helps. It will be in Monday's update (unfortunately, I cannot include any clear skies in the update, sorry!)

cheers,

Robin

[GoFraRo]

Hi Robin,

you were on the right track. I could test it with setting the delimiter to "." in Windows and it works as expected. Not only with the ASI120MC-s on the guidescope, but also with my main scope and the attached Neptune-C. Curiously, I do not have any problems any longer with the brightness. In todays test, I had an FWHM of 4.7 and had no issues with gain or exp.
Thanks a lot for (not only literally) moving the clouds aside.
This is a great start in a new week.

Regards
Gottfried

As soon as I have installed the new release, I will test it as well. But so far, there is a workaround.

[admin]

Hi,

thanks for confirming - the change to always use the '.' character in the parameters sent to the plate solving engine is in the update I uploaded yesterday, so if you update you should be able to change your windows settings back

cheers,

Robin