Is Syncing needed when using Center Now?

I have been using the framing and mosaic wizard successfully with my AVX/Starsense mount with the exception of auto meridian flips. I have submitted logs to Celestron and they are working on a fix. Recently I watched the video tutorial on this site again and realized that it recommended a Sync with the scope before using the Center Now command. I was just loading the image from FMW, using Slew Now command and then the Center Now command without doing a Sync first and again everything seemed to work just fine with the exception of the Flip. Now I’m wondering if that could be the cause of my meridian flip problems.

So my long winded question is, do I need to do a separate Sync first or does using the Slew Now or Center Now command automatically sync the scope?



Slew to target - no sync
Center on target - yes sync

Slew to target just tells the mount to go to the target coordinates and no more. Centering a target will sync the mount after each plate solve.

BTW, if you check the two options on the target “Center on when target starts” and “Slew to when target starts” then SGP will take care of everything for you when you start the sequence so you do not need to manually press the Slew Now or Center Now buttons.


Thanks Andy. In a way, I’m slightly disappointed. I was hoping that syncing might have solved the auto flip issue.



What problems are you having with meridian flip? I haven’t seen your thread. Can you post your logs? Have you tried running it during the day so you can isolate the problem?

I never had issues with my CGEM (same software/firmware) that weren’t user created. Do a reset, make sure your time/data is correct… the basics.



I’m using SGP on an AVX using the Starsense HC. I’m getting an Ascom error when it tries to flip. Here is Chris Rowland’s (the ascom author) response to my inquiry on TeamCelestron about the issue after viewing the log.

"What’s happening is that before this happens SGP is sending a sync command and that seems to cause the mount to report that it’s on the other side of the pier, even though it isn’t. The Axis position is also changed.

This looks like something to do with the way the SSA sync command is implemented, I’ll check with Derik what seems the best way to resolve this."

Huh, I never saw that behavior… but I didn’t have a star sense either.

I hope they can get it fixed!


I’m curious, why do you have both options selected:
Center on when target starts
Slew To when target starts

Doesn’t Center On take care of Slew To? Or am I missing some behavior that is beneficial to doing it this way?

Turning “Centre” off on in the pier flip may help because Centre seems to cause a plate solve and sync to be done before the pier flip. The sync before the flip, but after the meridian has been crossed, is what is causing the problem.

This needs fixing in the StarSense code and I believe the developer knows of it. It’s easy to reproduce once you know how.

All the same it would be nice if SGP was a little less enthusiastic with sync. I’m not sure what is gained by doing a sync before the pier flip when I expect another sync will be done afterwards.

BTW what happens if sync is not implemented in the driver? Sync is optional; will a system which can’t do a sync still do a centre?

Do we know that for sure? Haven’t had a chance to try it yet. Under Meridian Flip Options, Auto Center After Meridian Flip, the pop-up dialogue indicates checking it will perform a Solve and Sync prior to the meridian flip which is a little counterintuitive, at least to me. Also the option to pause before auto center is greyed out eliminating the option to adjust the counterweights to east heavy before an Auto Center is performed.

If you have both Slew To and Center options checked, what happens? Just thinking about it, it would make sense if the mount slewed first, then plate solve the location. I have always just used Center On Target and not have Slew checked, but that first plate solve seems superfluous when it’s still tracking from a previous target (not a big deal, though).

We need to know where we’re going after the flip. The only way to do this accurately is to plate solve. We also sync the mount every time we solve a frame from the camera as it is beguine with a properly working driver. We can’t be held responsible for bad behavior in a driver that implements sync poorly.

Good question and to be 100% honest I’m not completely sure. Although I’ve never seen a telescope driver that didn’t implement sync and we haven’t come across one from our users either. Generally if it doesn’t implement sync, it probably doesn’t implement slew either, in which case it’s probably not going to be a good choice for automated imaging :slight_smile:

Yes, after the meridian flip the mount will be synced during the verification process of the Centering. 100% sure.

If you have auto center checked then you should be able to pause before or after the meridian flip. It sounds like the issue you’re having with the mount is that it doesn’t like to be synced when it’s past the meridian. I would recommend flipping prior to the meridian and telling SGP to wait for the flip. Something like this:

This will make SGP flip very close to 1 degree prior to the meridian which should still be safe for your mount to sync. Then after the flip it will pause allowing you to adjust your counterweights. Finally after you click “continue” it will auto center and resume with the sequence. You’ll probably want to wait a couple of minutes prior to proceeding so that your mount tracks through the meridian.

Yes, the mount will slew first and then center. I always use slew and center on my first target as my G11 will “lose its mind” if it’s synced so close to the pole. however there’s certainly no harm in having slew and center checked on all targets. It’s probably better to go that route as your centering should take a minimum number of iterations to get within your pixel allowance.


Yes that was my initial plan. Unfortunately the SSA will not allow a flip until you are past the meridian.

Hi Joel,

I have a bad horizon and image targets over several nights, sometimes spanning weeks. As the weeks go by, my target end time may end up following the target into the trees.

Since centering the next target always starts with a plate solve, I could end up trying to plate solve while pointing in the trees and aborting the whole sequence. By enabling “Slew to target” I always get the scope to the vicinity of the next target before attempting the plate solve.

This raises a possible feature request that I think has come up before but I’m not sure if it is on K.&J.'s list: It would be nice if I could give my target start and end times as Hour Angle values. That way my targets would never fall below the tree line (they would start/stop at different local times though.) There may be other ways of accomplishing this, like being able to tell SGP about my horizons. Or having an API that I could use to adjust my target times programatically.


Something similar is on the list. Not hour angle per say but altitude. So you can enter time or altitude and one will drive the other with the altitude being the “value of record”. So say night 1 you enter a start altitude of 45 degrees and that will give you a start time of 20:45. Then night 2 you open the same sequence and the start altitude is still 45 degrees but the star time is now 20:58. However if you change the time it will drive the altitude but the altitude will be the value that is ultimately saved for future runs.

We’ve discussed how to allow you to set an entire circular horizon but first we need to change the time based system over to altitude.


One driver/mount that can slew but not sync is the ThsSky driver. This has an option to inhibit sync so that it doesn’t upset a TPoint model.

While somewhat correct it still exposes Sync and just ignores it…so as far as the software is concerned the sync happened just fine.

I’ve never really understood why they inhibit sync here though. Can’t/Shouldn’t the TPoint model be updated just like any other model? If the mount is not pointed where TPoint thinks it’s pointed it seems like it would still be worthwhile to actually process the sync and update the model.


[quote=“Jared, post:16, topic:698”]
While somewhat correct it still exposes Sync and just ignores it…so as far as the software is concerned the sync happened just fine.
[/quote]The driver source code doesn’t show this. If Inhibit sync is active the drivers return False for CanSync and if a Sync methods is called the old driver throws the ASCOM.PropertyNotImplemented exception and the new driver the ASCOM.InvalidOperationException.

Maybe your code is using the CanSync property to avoid calling Sync.

As for using Sync to modify the TPoint model I’ll leave you to sort that out with Patrick Wallace!

Can’t/Shouldn’t the TPoint model be updated just like any other model? If the mount is not pointed where TPoint thinks it’s pointed it seems like it would still be worthwhile to actually process the sync and update the model.

My understanding of it was that when you sync, it changes the base line for every other data point and thus invalidates it.

You’re right though, the Gemini-2 does something to what you’re talking about. You build a model and then use sync to update it.

I get that. It just seems like it you know you’re not pointing in the right place you would want to adjust for it. Anyways, it matters not. That’s their product so how they want to handle this is up to them. I’m sure they have perfectly valid reasons for disabling it.