SGP sometimes does not move scope using the Center Now

This is a really odd problem and has happened occasionally for a long time, so it’s not a current version issue nor is it related to PHD or PHD2 or Pinpoint (v6.0.4) as the issue is not about plate solving as such. Using SGP (v2.3.15.2568). The mount is a Skywatcher AZ EQ6 GT using EQMOD.

In the past when this happens I could sort it by either slewing to another place manually and Centering again, or if that did not work, a re-boot of the laptop is needed (Windows 7 64bit). But last night was different and it took many attempts over one and a half hours to get it to centre, and I have no idea why it worked then, but after that I could centre else where as well.

The problem is… The whole plates solve works and it finds it is say 1502 pixels off target (I have it set to get within 12 pixels in 8 attempts, which it normally does within one to three tries). So SGP issues a move and measures again, but the scope is not actually moved, it just thinks it has and then returns near as dammit the same distance off within a couple of pixels, i.e. possibly just the measurement error. It then repeats this till it reaches my limit of 8 and fails. Usually I have aborted long before that as I can see the scope it not being moved. The error remains the same for both RA and DEC. I can physically see the target in the view window well off centre and it stays there, I have also seen it move even further away after a manual slew to the object with Starry Night Pro7.

In the log you will also see some PHD errors, I think those occurred because I had either manually stopped PHD2 or I had at that point closed PHD to see if that helped.

The first SGP log from last night is here:

The problem starts at:
[30/12/2014 18:29:25] [DEBUG] [Telescope Thread] Center telescope message received…

I hope this is enough info, if not just ask. In case you wondering why I have not tried to sort this out before, it’s basically the sky is clear so little, I really don’t want to waste time under a clear sky. But last nights issue has forced me to act.



It appears that the scope is moving some (but not much), as it starts here:

[30/12/2014 18:29:45] [DEBUG] [Telescope Thread] Telescope: Syncing to RA: 1.51956693863717 Dec: 30.485767229583

Then SGP is requesting the slew:

[30/12/2014 18:29:45] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 1.56361111111111 Dec: 30.6613888888889

But it seems your scope is not getting there:

[30/12/2014 18:30:09] [DEBUG] [Telescope Thread] Telescope: Syncing to RA: 1.5182303608676 Dec: 30.8906194636753

There is another user seeing something similar, also with an EQMOD telescope. It looks like you’re using Pinpoint but he was using

I would make sure your mount is expecting coordinates in J2000 (what Pinpoint outputs) and try again. Other than that there may be some setting in your driver to allow small slews? I’m not sure. All I can tell is that SGP requested the scope to slew and it didn’t make it to where we requested. This could be happening because of a bad model or because the driver is detecting a small slew and not moving or because of precession.



Thanks for the quick reply. One thing you said made me remember that I did clear the pointing model and did a quick one point model and that was just before it then worked. Not sure what made me try that, but I was trying allsorts.

I thought that if a model was not accurate, each time you do a center action, SGP did a sync which would refine the model. I know that the syncs are taking place because after my one point model, and I did a successful center, there was a couple of extra points added to the model by the time I had imaged the two objects last night. So when you say a “bad model” do you mean the model could be corrupted?

I am sure all coordinates for all the software used are all in J2000, but I will double check.

I still have the older model saved so next time I am out I will try and center with that model and compare with a new one. I can’t do a quick check as the mount is permanently on a pier outside. I don’t ‘yet’ have an observatory, so testing this will have to wait for a clear night, it’s raining at the moment…

Thank you and I wish you a Happy New Year.


I had the same problem this summer. It was discussed on Cloudy Nights. I can’t find the thread now but the solution was clearing the pointing model. Like others, I just turned the pointing off. I haven’t had a problem since. I also use EQMOD.


Thank you for your input on this. I was able to do a short test tonight and using a fresh simple 2 point model I had no problem and SGP centred the object within 2 pixels after just 3 iterations.

So this certainly looks like the problem lay with the pointing model. I did not have time to load the older model which had about 25 points, as cloud came in. But I am reasonably convinced that the problem is sorted.

Now then, the question is what could be wrong with the model? Could it be a cone error issue? as I know the pointing is out by about half to one degree in RA. Could this be the problem when moving to the other side of the meridian?

I have only just got set up with a permanent pier with the mount staying on the pier. Before that I had to polar align for each session, so fine tuning cone error was never done. A full observatory will follow in the better weather.


Mike - When I had my problem, I had about 35 points mostly gathered before I got a pier/obs. You may be correct with it being a cone error. I discussed it with some others who had just decided to turn the pointing model off as they weren’t using it with SGP. All they were doing was using plate solving/centering. I realized that I was also just plate solving and and centering. With the pointing model turned off, my plate solving has been fine. So, I never followed it up further.

Just an update. I no longer have a problem as long as I create a new model each time I start a session. This is no problem as my pointing model just consists of one sync with a bright star in roughly the area I am imaging. Plate solves work fine and they automatically build the model as each plate solve syncs.