RA pixel error does not reduce after first plate solve when using ‘Slew and Centre” in SGP

[AMcD]

I have also posted this query on the SGP forum but wondered if any one here on SGL has encountered this problem.

I am attempting to use ‘Slew and Centre’ in SGP with Plate Solve 2 on an older Losmandy G11 mount with Gemini I as part of my imaging sequence.

The problem is that after the first Plate Solve the Dec px error reduces to within an acceptable pixel tolerance but, whilst the RA px error also reduces on the first plate solve, all further plate solves make no difference to the RA px error.  The result is that centring ultimately fails and the sequence aborts.

I have read that this might be the result of SGP fighting the pointing model in the Gemini I.  In any event, is there a solution / set of settings that will resolve this issue, for example by eradicating the Gemini’s pointing model?

[Jonk]

In EQMOD, if you have the software set to sync on solve, i.e. after a platesolve, sync the mount, then once the 1st platesolve is complete, the mount syncs to it. The 2nd platesolve is off by xx pixels, and the mount is instructed to move xx pixels as expected. However, the mount then syncs to it, so you end up with a never ending cycle.

I turned mount syncing off in EQMOD, because if you're platesolving, then having the mount use multiple sync points to improve accuracy isn't actually needed and may cause the problem you describe.

[AMcD]

1 hour ago, Jonk said:

In EQMOD, if you have the software set to sync on solve, i.e. after a platesolve, sync the mount, then once the 1st platesolve is complete, the mount syncs to it. The 2nd platesolve is off by xx pixels, and the mount is instructed to move xx pixels as expected. However, the mount then syncs to it, so you end up with a never ending cycle.

I turned mount syncing off in EQMOD, because if you're platesolving, then having the mount use multiple sync points to improve accuracy isn't actually needed and may cause the problem you describe.

Many thanks for this.  I suspect the equivalent in the Gemini to turning off syncing in EQMOD is to cold start the Gemini each time it is powered up, forego the initial alignment star routine and uncheck "Sync performs additional align".  This should ensure that Gemini does not build an alignment model with the attendant sync points and therefore does not fight the plate solver.  I will give this a try.  Many thanks again.

[Jonk]

Sounds like it is a very similar thing, yes.

You can but try!

[AMcD]

On 05/02/2021 at 23:19, Jonk said:

Sounds like it is a very similar thing, yes.

You can but try!

Indeed!

Based on a reply in the SGP forum another possible problem I have identified is that I had the Gemini set to expect J2000 co-ordinates. 

SGP uses J2000 but converts them to JNOW before sending them to the G11.  Therefore the “Gemini expects J2000 co-ordinates” box must be unchecked in the Gemini.net interface.  Otherwise the G11 will think it has been sent J2000 co-ordinates by SGP and centres at what it thinks is the correct J2000 position.  When the second plate-solve happens it will see that the G11 is still off by reference to JNOW and send the same JNOW solution co-ordinates again.  The G11 however, will again read them as J2000 and think it has already moved to those co-ordinates and will not move again.  In short, unless the “Gemini expects J2000 co-ordinates” box is unchecked, after the first plate-solve SGP keeps saying “move” and the G11 keeps replying “why, I am already there.”

I suspect it is possible that this is the same problem that can occur if the G11 has a detailed pointing model active.  SGP will send the G11 co-ordinates based on the first plate-solve and the G11 will move having regard to its active pointing model.  If the model cannot match the accuracy of a plate-solve (as it generally will not) then when the second plate-solve happens it will see that the G11 is still off (by reason of defects in it’s pointing model) and send the same solution co-ordinates again.  The G11 however, will, by reference to its pointing model, think it has already moved to those co-ordinates and will not move again.  Once more, in short the presence of the detailed Pointing model means that after the first plate-solve SGP keeps saying “move” and the G11 keeps replying “why, I am already there.”

When these interminable clouds clear I will try the solutions of (a) unchecking the “Gemini expects J2000 co-ordinates” box and (b) not using a pointing model and post the results.