Plate Solve Issue with CGEM DX

Hello,
Am new to the forum, have been trying to lookup a solution to my issue - apologies if this has already been resolved.
My setup: Camera: Nikon D7100, Mount: Celestron CGEM DX.
Steps:
a. Polar aligned using PoleMaster, focused on M33 outside of SGP. Started SGP, opened the Framing and Mosaic wizard and set my scale to 0.8" / px.
b. Started the sequence by clicking ‘Run Sequence’ - the plate solve failed, it went through the retries (4). Each time it gave an error that the pixel error in RA and DEC combined were higher than my tolerance set (50PX). This even failed when I increased the tolerance.

Looking at my logs though, it seems like SGP was giving a set of sync coordinates (RA/DEC) to my mount. After the Sync / Center, SGP was reading off the values - and there was a difference…so, the mount wouldn’t slew exactly where it was asked to. Likely because the mount mechanics may cause it to miss the new target.

Is there an EQMOD or SGP setting that I’m missing?

My logs are here

Appreciate any response / pointers.

Nav2000

@nav2000

If you would like to use EQMOD, please ensure that you follow this guide prior to running. Nine times out of ten, EQMOD users have difficulty with centering because SGPro is fighting with EQMOD’s pointing model. This will help clear that up.

http://www.mainsequencesoftware.com/Content/SGPHelp/UsingEQMODwithSGPro.html

Ken
Thanks for the reply, am using ASCOM drivers for my CGEM DX. Also, am using a local Astrometry.net engine for plate solving

Naveen

Ken
Thanks for the reply, am using ASCOM drivers for my Celestron CGEM DX.

Celestron mounts have a known issue that the slew does not land exactly where intended. The sync is fine and the mount is capable of very accurate centering with plate solving and no synching, but I guess it is not yet implemented in SGP.

The current beta instructions describe synchless centering as something needed for mounts that don’t like to be synch’d - but there are also mounts like the cgem that can synch just fine, but the slew does not happen exactly as sgp wants it to, and that limits the centering accuracy when using the sync/slew approach.

The problem is with the slew - not the sync.

So - for cgem and other celestron mounts - sync is fine and the mount’s model is fine and the goto accuracy is good - but the sgp centering routine will not converge and will fail in the manner you describe - until syncless centering is implemented for it.

Frank

1 Like

Frank
Thanks for the response. Am new to SGP and Plate Solving. My current workflow is:
a. Polar Align and basic focus
b. Do a quick align on my CGEM DX Mount
c. Connect SGP and pull up my target
d. Click on ‘Run Sequence’ - this attempts a plate solve

How do you recommend I change this workflow for best results?

Thank you!

Naveen

Hi. I believe your issue isn’t plate solving. It is that centering does not converge and it gives up. This is expected with a celestron mount when using sync to center.

So what you are doing seems fine but you will need to increase the tolerance for centering and tell it not to try more than twice.

If syncless centering is implemented it should allow tighter tolerances and better centering. But I don’t think it is implemented yet.

Frank

I thought latest Beta took care of sync/no sync:

Sync behavior: Added functionality to the telescope tab to define “sync behavior”. This also affects the process by which SGPro centers on a target. Choosing “Sync” will cause SGPro to function like it normally does. This is what you should continue to use for this beta. Choosing “Offset” will use a sort of “Syncless” centering algorithm and should be used with mounts that really don’t want external applications trying to sync the mount’s position. This option is complete, but has not been tested AT ALL. Use at your own risk… DO NOT USE THIS OPTION UNATTENDED!

Peter

No, but it is coming soon. Just need some more time for testing before we turn it on.

Sounds good. I’ll be happy to try it when it’s ready. And when I have clear skies.

Frank

Thank you Ken! Am looking forward to using it…