Scope centering examples and problems - simple fix

A number of people have reported problems with centering, and I think everything would be fine if there is a follow up fix to the original implementation of “Scope Offset” centering.

For context here is a thread that describes the motivation for the different centering/syncing modes

And here is a follow up showing continued problems:

To show how simple this is, here is a worked example with my cge-pro - where I just use pencil and paper to calculate where the scope should slew to - to correct for errors in the position. There is no syncing involved and no fancy algorithm or code - just me looking at the move I just requested - and where it actually ended up according to a solve.

I created a target with nice clean coordinates of 23h 00 00 -50 00 00 and told SGP to slew there. I then did a plate solve without sync and it was at 23 00 03, -49 54 43.

So I did the math to compensate for the error and told it to slew to 22 59 57, -50 05 17. The new solved position ended up 22 59 59, -49 59 56 - or only a few arc-seconds off after one iteration. And that is great.

Subsequent iterations were well behaved and ended up 0 off in RA and 2" off in dec - after 4 iterations.

In contrast, when I tried the auto-center routine with different sync options, I got errors in Ra, Dec (pixels at 0.8"/pixel) that behaved like:

Center with Scope Offset:
-49 -1038
-40 -1030
-28 -1133
So this mode wasn’t converging at all and I have no idea what it is doing. That’s 800" error in dec and it isn’t changing.

Center with target offset:
-2 -5 (was very close on first attempt - I assume by coincidence)
73 -8 (farther on second try)
66 -7
67 4
59 -5
This mode ended up stuck in RA and did not converge. The error isn’t terrible at about 50" - but with a small field of view it is a real problem for good framing.

Center with sync:
-13 -1349
63 -82
62 -1
70 -4
This again ended up stuck

So my guess is that Center with Scope offset just isn’t doing what was intended - and all it needs to do is the simple math I show above - where you look at where you just told it to slew - and what the plate solve was - and you adjust the previous slew target so it will be closer next time. It doesn’t matter what the cause of the error is - as long as the moves are repeatable.

If the moves aren’t repeatable then it’s hard for anything to work - but if they are repeatable - and on the order of arc-seconds - then the centering routine should be able to work well.

I know this affects celestron mounts - but at the same time I think it would work well for other mounts - and it doesn’t require a sync.

So please take another look at this issue and the way it was implemented. It looks like it isn’t doing what was intended - and a fix would benefit many of us who find centering is just ‘stuck’ and doesn’t converge.



Just to clarify-

It looks like Center with Target Offset is identical to “Center with Sync” - except Target Offset works without actually syncing the mount. They both miss in a similar way for Celestron mounts and get “stuck” some distance away.

So for some mounts that don’t like syncing, Center with Target Offset may work ok - as long as you don’t see it getting stuck. And since it doesn’t sync, it shouldn’t mess with the mount model.

But I doubt that Center with Scope Offset is currently working for any mounts - since it is so far off in my case. So it is there in the code and could do what I show above in terms of calculating the next slew based on the prior solve - but it appears to be in the same condition it was when I first tested it last December.

Right now this centering issue is critical for me to upgrade the version 3. The cost isn’t really an issue - but I do need core functionality to work well or I just can’t use it except for single target sequences where I frame the object manually.