Error on Centering has grown significantly

I’ve been seeing the same problem with my G-11 and Pinpoint for several months. Used to get within 5 pixels. Now can’t get closer than 900 or so (it solves OK). Does the accuracy of the pointing model in the mount have anything to do with this? I haven’t been adjusting that thinking that Center on Target takes care of all mount issues.

SGP knows there’s an error. But it just doesn’t move the mount to correct it. Haven’t tried yet with

We’d need logs to validate that. In most cases we’ve seen SGP issues the slew and the mount doesn’t move or can’t move to get there because of backlash.


In my case and I think others - the problem isn’t due to backlash but the fact that the mount doesn’t land at the ra/dec values it is told to - exactly. If the problem were only backlash, the final ra/dec values would match exactly - but the true pointing location would be off. In my case, and I believe others with non high-end mounts, the final ra/dec values are not exactly the intended ones - and there is no backlash issue at all because the mount does the final slew in the same direction always.

I will try centering with my cge-pro again - but I have already described this in detail. It isn’t trivial to get a mount to land at the exact ra/dec at the exact time - and there may be an inherent error of 1’ or so that has little impact on normal usage - but would make the sync/slew centering approach of sgp simply not work well at all. After one sync/slew it is about as close as it ever will be and it won’t get closer.

No backlash involved at all.

I have suggested two workarounds: nudging for the final centering, and having sgp keep track of the sync offset and correcting for it in sgp rather than syncing the mount. As long as the “miss” is repeatable, the latter should work well and has many advantages since it doesn’t alter the mount model.


From the logs above - I don’t see a log after the slew and before the sync - where you report where the mount thinks it is after the slew. That would be key diagnostic information - because otherwise you are just assuming it went to where it was told to go.

I will try this again when I have a chance, with cge-pro. But if that info isn’t in the logs - I recommend adding it. Otherwise the value will be stomped on by the sync. So I would need to do a separate test to tell the mount to go somewhere - and then query where it thinks it actually landed - based on its own ra/dec values. If those numbers are different - that is a fundamental limitation to accuracy of the sync/slew approach.


Hello there,

I’m back here with a few more attempts on this. Last year I would drag everything to my backyard on a JMI Wheeley Bar, fire SGP and go to bed and everything would work fine. Now I have an observatory, my mount is permanently set up, etc and absolutely nothing works. I am ready to throw the towel. Last week I got 1 night of successful attempts then last night when I was trying with a new telescope (and again with the other one that gave me successful attempts) everything went back to what it was, usually over a thousand px error when before I would never go over 5px and it would solve on the first attempt. I don’t know what is going on, I tried everything I could think of including uninstalling and installing everything and I still keep getting the same errors. I am attaching a couple of logs (I tried all night so I had many logs and I apologize if some settings are different, it’s all because I was trying all that I could think of). So here is what I noticed. I align my mount and tell it to go to a target (Andromeda for example), centered spot on, move the mount and tell it to Center on Andromeda again and I can see how off it is. I tried removing the hand controller like suggested, tried clearing my previous alignment, etc. Any help will be appreciated.

P.S.: How can I add log files and pictures?

Please see this post:


I would like to point out that I had the same issue with my CEM60. The problem was caused by iOptron changing their firmware so that it passes the mount alignment model between the mount and the any software connected to the ASCOM driver. The result was that the iOptron firmware was overwriting mount corrections being sent by SGP. Once I cleared the mount alignment model using the hand-controller, SGP was centering within 5 pixels every time.

I’m not sure if this is your problem, but if you are plate solving OK and the mount is not moving, this may be something to look into.


Hi Jared, finally had a clearing! Please see attached log.

SlewError.txt (50.1 KB)

I did not read trough the complete message thread …
But when I saw this it was related to pointing model being build, so best is that when SGP solves and sync, the mount software does not add it to it’s pointing model, this sounds counter intuitive but believe me, with plate solve you don’t want pointing model anymore …
If this is already been discussed sorry …
(I had this with eqmod, I could never reach accurate framing anymore, until I set the pointing model to manual and not automatic)

I have a Paramount MX - presently I’m using TPoint and not using centering, though I have in the past used the automatic centering without any issues - centering to within a few pixels in one iteration.
As soon as I get a clear night I will disable TPoint, disable sync inhibit in the ASCOM driver and try for myself. Since the driver and software are identical to the OP, it should highlight if there is underlying issue. I’ll tryi with Pinpoint 6 and Platesolve 2.

Thank you, Jared. I decided to wait until the next time I am out there getting the same error I am talking about. I have too many logs and I don’t want to get confused and send you the wrong one so I will wait to get better documentation of the error. Thanks for your help!

As I expected it looks like we issue a slew but the mount just doesn’t get there. As others have mentioned it could be the model, backlash, or something else. For the most part it looks like the mount just refuses to slew. The error is always pretty constant around 1245 pixels.

Maybe try just a single star alignment? Disabling any sync based model building and see what happens.


Hi Jared,

I don’t suspect mechanical (backlash) issues because I did get single digit
centering at one time. The mechanicals are unchanged.

I think it has to do something with the mount model as others have
mentioned. I will clear the model and try building a new one with just one
star. This will allow me to use the G11 hand controller to get reasonably
close to bright stars for focusing.

I’m curious how the mount model might affect the centering algorithm. I
assumed the overall algorithm is…

  1. Take a picture of where the scope is pointing now.
  2. Compare to the reference picture (produced from the stored reference RA
    and DEC).
  3. Calculate the differential to slew the scope.

I believe the mount model corrects an absolute RA/DEC coming in. But if
everything is done with differentials, I would suspect the mount model
correction would have no effect.

Ya, I would think the same. But I not knowing how the mount modelling is performed in the hardware and not knowing what they’re abstracting from us is the mystery.

With the Gemini you can likely try a couple different things:

  1. Turn on “Sync Performs Additional Align” with a model in place.
  2. Disable “Sync Performs Additional Align” and do a Cold Start to clear the model.

1 will essentially allow you to build and redefine the model as you go. 2 completely disregards the model.

Also it’s probably worth turning on the “Mount expects JNow” (can’t exactly recall what it is…but I believe it’s something like that. If I remember correctly the Gemini controller ALWAYS returns JNow but if that option is disabled then it will assume J2000 for the sync and slew. SGP will query the mount and ask what format it’s expecting…but ASCOM only allows for a single epoch and it seems that the Gemini can potentially allow 2 epochs (one for sending and one for receiving)


I am not sure how other manufacturers handle their mount model, but iOptron changed their handling of the model during their most recent firmware update for the CEM60. They placed the following note in their firmware update history file.

Alignment model will roam between the hand controller, RS-232 port connection and Wi-Fi connection now. If you want to use any pointing enhancement software, such as T-Point, make sure there is no alignment model in the system!

Prior to this update, I did not have any problems with SGP Centering with a one or two star model in the hand-controller. After the update, I had to delete the any alignment model in order to get the mount to respond to SGP centering moves.


Hi Jared,

Understood. Please see attached for the state of the G11 after performing a
“Reset Model”.

  1. I’m thinking if the model is affecting centering, then I should keep a
    “zero”’ model as shown in G11-3 and use SGP centering for everything. Or,
    just model one star and occasionally align and/or sync (?) to that same
    star when something moves.

  2. For #1 above, do not select “Sync perfoms Additional Align” in G11-2.
    This will help prevent updating the one-star model.

  3. In G11-2, do you recommend selecting “Gemini expects J2000 co-ordinates”

I think if you keep it like that and just do an initial “Blind Solve and Sync” (do this well away from the Pole FYI) then you should be good to go. I believe that will keep the model at “Zero”.

No, leave that off. When off it should talk JNow on both sides. Alternatively if you keep having about the same amount of error try enabling that :slight_smile:

Interested to hear your results. I never bother with a model on my G11 Gemini 1. At first I did when I setup my obs but I get so little time out there now I don’t even bother with a model. Just slew and go, Auto Center FTW!


As I have described before - having a mount remove backlash is easy and I expect all would. Certainly my cge-pro does. But having a mount go to a specific ra/dec value at a specific time - quickly - involves timing and dead reckoning - at least for some mounts.

I’m not talking about the true ra/dec values - but the ra/dec values of the mount’s encoders, or where it thinks it is. This is easy to check by telling a mount to go to a particular ra/dec value - and after the slew you ask the mount where it thinks it is. If there is any error there - it will also be there in the sync/slew process used by sgp. And it has nothing to do with backlash - and repeated syncs/slews will not improve anything.

Unfortunately right now I can’t test my mount but I will when I can. Anyone can check this with a mount. Use its handcontroller or something and tell it to go to a specific ra/dec value - probably not too far from the equator so there is no dec. issue. Once it gets there read the ra/dec value where it is. Any error there will be a problem for sync/slew centering.

That is why I suggested adding log info for where the mount thinks it lands after a slew - and before the sync is applied.

If you do see an error - the next question is if you can adjust the target ra/dec value by correcting for that error. Again - this is NOT backlash. As long as the error is repeatable, sgp could measure it and correct for it - without doing a sync at all. This should work for all mount models and for mounts that don’t land exactly where they are told to go.

Right now this is a big problem for me - and I am not alone in having the mount fail to reach a given centering tolerance because it just gets stuck some distance away - and stops converging. My only recourse is to make the tolerance large.


Just tried it on a PMX with TPoint disabled and synch inhibit disabled in the ASCOM driver - that is, similar to the OP’s MyT.
Was within a pixel in a single iteration. Tried slew and center and then center here, with equal excellent results using PinPoint.
With Platesolve 2 - a repeated experiment was within 7 pixels on one iteration.

(pixel scale 0.56"/pixel)

Hello Jared,

Having a “zero” model inside the mount completely fixes the problem. I am
now seeing centering to single-digit pixel error.

I’m guessing that any errors in a non-zero model add to the centering
error. This may explain why I saw centering error increase over time for an
old model. A “zero” mount model appears optimal for centering.

I did not try adding one star to the mount model. I agree with you that the
mount model is not needed with SGP’s centering algorithm. I simply add my
focus stars as targets and center on them. There’s no need to use the hand

Maybe someday this behavior can be explained. For now, I’m very happy to
learn that SGP’s centering algorithm is capable of single-digit pixel
errors when the mount model is cleared (zeroed).

Best regards,