All Platesolve Methods have started failing with Paramount MX+

(Log attached.)

PS2 with ANSVR faillover has worked fine for years, but the last few sessions it’s been failing frequently. I installed ASTAP, but no better luck with that. The weirdest thing is that this morning I ran a platesolve on the platesolve image that failed last night (and ended the session) with ANSVR, and it blindsolved just fine with ANSVR this morning. Same image!

Failure last night was at 00:15:51, and success this morning (twice) began with ASTAP failing at 09:27:58 and then success blindsolving with ANSVR. Any idea what’s gone wrong?

BTW, I’m still on version 3, but I’ll switch over to v4 now. I’m totally happy to support Ken and Jared. I’ve just been too lazy to figure out how it all works. :slight_smile:


Aprox time of issue: 00:15:51

Link to Logs

Useful Info

OS: Microsoft Windows 10 Home
.NET: 4.8

Check the image and the stars on it. Maybe tracking was lost or mount wasn’t stable after slewing.

The platesolve image is fine. It platesolved without trouble in the morning when I ran it, but not during the session.

Unfortunately I’m not really seeing anything in the logs that points to what the failure was. May be worth at least upgrading to 3.2 as there were some issues fixed in platesolving in earlier 3.2 versions.


Thanks Jared. I upgraded to 3.2 last night, and still had the same problems. I’ve noticed that it often solves after the initial slew - it’s the subsequent small nudge that fails. Does that help at all?

The log is here:

Hm, might be an issue in Offset sync. Can you try using “Sync” or “None” depending on what you need.


I’ll try None, but my experience is that Sync doesn’t work for Paramounts because it changes the TPoint model, maybe because of some conflict between TSX and the driver. I found that I have to use Target Offset, because otherwise my Paramount won’t nudge onto target.

Jared, can you explain what the sync behavior settings actually do? I have to confess that despite using SGP for - what, ten years now? - I don’t actually know what is being synced to what. Since this setting has caused some trouble for me before, understanding it better might help me solve multiple problems.

  • Sync Behavior: Specifies how syncs will be sent to the telescope
    • Sync: Syncs the mount whenever a sync is requested. This is the default value and should be used for the majority of mounts
    • Offset: Syncs the mount for Solve and Sync but for Auto Center and Center Here an Offset will be computed to more accurately slew the scope. This is useful for some mounts that do not like syncs to be very close together.
    • None: Mount will not be synced under any condition.


Astrovienna, it has been the case to use Target Offset as the best practice for years since a TSX change in (2017?). The sync setting in the ASCOM driver have to be set to disable too. I get within a few pixels on one iteration with my MX and MyT.

Hi Chris,

Yes, you helped me solve this problem back in 2017 when I first got my Paramount! But I still have it set that way, so I’m not sure what’s changed.

If my TPoint model somehow got corrupted, could that explain this behavior? I suppose it’s possible that I pressed “solve and sync” when trying to reinstall ANSVR recently. Would that corrupt the model? In any case, I’ll rebuild the model the next clear night and see if that fixes it.


If you did that from within SGP with the Sync set to “Target Offset” then it should have just applied the offset and not actually sent a Sync to the mount. So it should be safe from TPoint’s perspective.


Thanks. I was thinking that might override the Target Offset setting, but good to know that it doesn’t. I’ll try to rebuild my TPoint model next clear night and see if that solves the problem.


I also just had a platesolve problem with my AP1200/gtocp4. It may have been related to the time change. I finally overcame it by re-initializing the mount. The blind failovers also were not working.

Peter Bresler

For info - these issues pop up regularly on this forum and so I did a video to share the settings I use to make Paramount and SGP to work together.

Chris, thanks for posting this. This certainly will save some people a few hours of frustration.


happening to me last night and a friend who hasnt used his set up in months and not touched it - same

Lots of reason why that could be. For instance, if you updated ASCOM in the meantime, it blanks the profile store settings and without the right options in the TSX ASCOM driver, frustration is guaranteed.
The other thing is that the ASCOM driver settings are dynamic, in so much that if you are trying to do many things with the mount at the same time, it throws an exception, which then disables the ‘offending’ option in the driver. You only realize when you open up the driver and scratch your head… 'I’m sure I enabled that?"

I redid my TPoint model last night, and now it’s platesolving pretty well. ASTAP did fail to platesolve at 4am this morning - and I’m not sure why - but the real problem was that after that the failover to remote was unable to login, probably because my internet connection was down at the time. (I forgot to switch my failover back to local ANSVR, but I’ve fixed that now.)

So the relevant issue here seems to be that the TPoint model somehow went bad, and that messed up platesolving. My TPoint model seems to last only a few months, presumably because with my moving-mirror SCT it was never very accurate to begin with.

I should have two more nights of clear skies, and I’ll report back if I still have problems. Thanks for all the help on this.

Hmmm. Looking a bit more closely, I really can’t explain why ASTAP failed at 4am. The mount slewed to the target, ASTAP solved once, SGP nudged it a bit to get on target, ASTAP solved again, SGP nudged a bit more, and ASTAP failed to solve.

Any idea why? Solving and centering worked fine on 4 targets earlier in the night. The log is here (big multi-night log - the problematic slew/solve begins at 03/20/21 04:03:41.256):


I’m continuing to have trouble tonight. The ASTAP platesolve failures are all occuring on high-declination targets, while targets closer to the equator are solving without trouble. Does that provide any clue to the problem?