Plate Solve 2 has mysteriously stopped solving


I am back in the Arizona desert after a few months of no AP, and the first thing I did was update SGP, PhD2, ASCOM, etc. Now I am finding that Plate Solve 2, which normally works great, will not solve images, even those just taken by SGP. I have checked my time and location is correct, as is my pixel scale. It will try to solve for a very long time until it eventually fails, at which time takes over and has no problem solving the image blind. I have spent the last few days trying to sort this out with no luck. And suggestions? Anyone else having trouble after updating to the latest ASCOM version?
I am using Windows 10, a Canon 6D, FSQ106ED, and APCC with Astro-Physics mount.



Hi Dean,

Just thinking. . .

  1. Did you compare the plate solved coordinates to the mount. I’m wondering if the mount pointing reporting positing is too far away/different and that is causing PS2 to not solve. I’ve had that happen to me before.
  2. I found if I’m not in good focus sometimes PS2 will fail as well.

Just my thoughts

Kind Regards,


Hi Mark,
And thanks for the reply. My focus is excellent, but yes I am getting an error message that saying that the position is too far away to solve. But I don’t understand why that is. It gives me this error message even when it is right on the target. If my date, location, and pixel scale are correct, what else could be confusing Plate Solve2? I can’t help but wonder if it is related to the updates that I just did, because it was working fine before I did them.
It was a heavy blow to have this problem. I am in Arizona at a dark site with my RV, and have a week of clear, cloudless sky forecast. Fortunately I have installed locally, and while slower, it eventually gets me where I have to go. But it would be nice to have the usual speed and efficiency of Plate Solve 2 back.



Curious, is the default location within the PS2 params also correct? Maybe not getting updated from user profile?



Good point, and when I checked last night this was NOT set to my proper location and I thought I had found the problem. Alas, changing it did no good.
What is strange is that I can solve and sync blind no problem using So once the telescope has been freshly solved and synced blind with and knows its location, I then try to “center on” my target. As usual, an image is taken to determine my present location for the beginning of the upcoming slew to target. And Plate Solve 2 cannot solve that image. Even though SGP just took it, and even though the scope has just been solved and synced and should know exactly where it is.



Mmm, yea, it sounds like you have covered the bases. How about a log? It would be interesting to see what is being reported during the solve.


Hi Stephen,
Here is a log. I just used an image taken with SGP last night, and it can’t solve it. I aborted the attempt manually after a few minutes, and then blind solved it no problem.




The log appears, to me at least, to indicate that for whatever reason, PS2 is being passed hints that are way off from reality.

Look here :

[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] ************* SOLVE HINTS ****************
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] SOLVER: PlateSolve2
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] BLIND: False
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] METHOD: Max Regions
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] RA: 5.62231666666667
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] DEC: -2.92184444444444
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] SCALE: 2.54860049770286
[11-07-18 16:07:41.357][DEBUG] [Image Plate Solve Thread] ******************************************

Most of that info comes from the FITs header, presumably placed there by whatever application created the FIT file (I presume SGP)

[11-07-18 16:07:41.399][DEBUG] [Image Plate Solve Thread] FitsFileHeaderData: Angle - 359.488148458041
[11-07-18 16:07:41.399][DEBUG] [Image Plate Solve Thread] FitsFileHeaderData: Scale - 2.54860049770286
[11-07-18 16:07:41.399][DEBUG] [Image Plate Solve Thread] FitsFileHeaderData: RA - 5.62231695647545
[11-07-18 16:07:41.399][DEBUG] [Image Plate Solve Thread] FitsFileHeaderData: DEC - -2.92184309597401

The same hints were passed later to Astrometry.

Now, look at Astrometry’s solve results :

[11-07-18 16:10:50.915][DEBUG] [Unknown] Astrometry.NET returned: {“epoch”:“J2000”,“ra”:84.314409099,“pixscale”:11.6726548855629,“radius”:0,“dec”:-2.62303405004,“orientation”:179.771298953234,“parity”:1}
[11-07-18 16:10:50.924][DEBUG] [Unknown] ------------ Begin CalibrationResponse -------------
[11-07-18 16:10:50.924][DEBUG] [Unknown] dec -2.62303405004
[11-07-18 16:10:50.924][DEBUG] [Unknown] ra 84.314409099
[11-07-18 16:10:50.924][DEBUG] [Unknown] radius 0
[11-07-18 16:10:50.924][DEBUG] [Unknown] orientation 179.771298953234
[11-07-18 16:10:50.924][DEBUG] [Unknown] pixscale 11.6726548855629
[11-07-18 16:10:50.924][DEBUG] [Unknown] epoch J2000
[11-07-18 16:10:50.924][DEBUG] [Unknown] time NULL
[11-07-18 16:10:50.924][DEBUG] [Unknown] parity 11.6726548855629
[11-07-18 16:10:50.924][DEBUG] [Unknown] ------------ End CalibrationResponse ---------------

I’m not sure why the file header data is SO wildly off…but I’m as certain as can be that’s why PS2 can’t solve it. It was given an RA, Scale, and Rotation wildly different than what Astrometry reported.

EDIT : Actually, now that I think about it…could Astrometry’s response be in degrees, while the hint is in RA Hours? If so, 5.62 Hr would be darn close to 84.31 degrees…so my whole theory above may be way off base there…though the scale is still quite different as well.


Well that is really strange. Now as soon as I did the updates to SGP, PhD2, and ASCOM, I found that the scope started getting lost. I did a process to “rehome” the AP Mach 1 by loosening the clutches, then using APCC to tell it to park at park position 4. I retightened the clutches after manually setting the scope into proper orientation on both axis in position 4, then sent it home to its usual park position of position 3. It found it no problem, though it has randomly gotten lost a few more times since. It doesn’t usually do this, so I think it may have something to do with updating ASCOM? Maybe a conflict with APCC?




What versions of APCC and the AP V2 driver are you using? Also, are you seeing the mount get lost during an imaging session?



Ok now we are getting somewhere. This screenshot shows the FITS header from the image, and it shows my location as near my home in Quebec!

Now the question is where it is getting this info from, as I thought I had changed all locations in ASCOM, telescope setup, etc. to where I am in Arizona. Time to check again. I obviously missed something, somewhere.




The mount’s time can only be changed when initialized. If the Lat/Long is changed after it is first initialized the mount will get lost. APCC and the driver won’t let you do that, but other applications might (e.g. TheSky)



Hello Ray,
And thank you for responding. I have the latest APCC, but was using an older driver. After updating ASCOM and the AP driver I was getting an error message when I tried to open APCC that let me send a report to Astro-Physics, which I did. I then went back to an older driver and I was then able to open APCC.
The mount got lost during slews after plate solves with Plate Solve 2. It appears that the program was getting wrong location data.
The obvious next step now is to update the AP driver, as I see you have just released a new version. I am in the middle of an imaging session right now, and by using as a plate solver I am able to get by. I don’t want to risk changing anything right now for fear of losing imaging time if something goes wrong. So as soon as the moon is back, I will update the driver and see if that helps. Thanks again for the reply Ray.



Hi Dean
This happened to me very around 1 month ago. It started failing on 2 of my computers.
I reinstalled the latest ASCOM service pack, and simply reinstalled SGP over the top of my existing installation (no removal) and everything is running hunky Dory once more.