SharpCap Forums

Hi Robin,
Wow, incredibly quick response, thanks so much!!!

So, what settings do you recommend in gs server and why?
Thanks again.

Hi,

the best option is setting GSServer to 'Local Topocentric', which is equivalent to JNOW - that avoids the issue in 4.1.11799 and will work fine. With this week's SharpCap update J2000 should work fine too. I don't recommend the other options.
.
SharpCap checks the configuration of the ASCOM driver and adjusts co-ordinates accordingly, so if you try to GOTO a target from the catalog, SharpCap knows the catalog co-ordinates are J2000 and if your GSServer is 'Local Topocentric' then SharpCap will adjust the co-ordinates to JNOW before sending them to GS Server. It's difficult to be sure what other applications do the same adjustments though, or what settings work best for them.

cheers,

Robin

Hi Robin here I am again, only yesterday due to bad weather I managed to test the new version of Sharpcap (4.1.11939).
As per your instructions I changed GSServer to 'Local Topocentric'.
Nothing else has changed.
Unfortunately he still can't get the target to the center on the first try. See figure 'Vega' ended up at the bottom right.
To bring it to the center I had to open the 'Deep Sky Annotation Results' window then select 'Vega' then click on 'center in view'... now it brought 'Vega' to the center of my target.
I have the impression that during the sequence started by 'Goto Catalog Target/Co-ordinates' when reaching the 'recent target' step the program exits this step too quickly without moving the target to the center.
The version (4.1.11757) actually did this last step and you could feel the mount moving to recenter the object.

I attach the log to you

Hi Carlo,

thanks for posting a comprehensive log - it will take me a while to filter through it and track down exactly what is going on, but once I work it out I will report back.

cheers,

Robin

Hi,

OK, I have it now... The problem is down to co-ordinate parsing of the sequence not being right when the decimal separator is set to comma. This line in the log shows the initial cause of the error
You can see that the co-ordinates, which are specified as text as 'RA=18:36:56,3,Dec=+38:47:01' are interpreted incorrectly for the RA co-ordinate. It turns out that the code trying to interpret the co-ordinates tries first with english number format (decimal separator is a dot and the number grouping character is a comma). This works, but with the wrong values - the minutes of RA comes back as 563 (56,3 without the comma).

The reason that it used to work is that SharpCap used to not worry about the fractions of a second of RA for the co-ordinates... That had the unfortunate effect that the RA was 15 times less accurate than the DEC (only 24 hours of RA in a circle, not 360 degrees). When I fixed that to include the decimal part of the seconds of RA, it broke for non-english languages.

I will fix this for next week's update. Thanks for testing this repeatedly for me!

Robin

Hi,

this should now be fixed in versin 4.1.11947 which is available on the downloads page.

cheers,

Robin