Let’s suppose we have a mount with a very simple ASCOM driver. This Mount understands two commands:
GoToCoordinates(RA, DEC) – the mount computes the difference between the actual coordinates and the goto coordinates and issues the necessary stepping commands for the RA and DEC motors in order to cover the computed distance. After the slew, the mount knows its actual coordinates are RA and DEC. This knowledge might be (and normally is) more or less wrong.
SYNC (RA, DEC) – this tells the mount to replace the actual coordinates it thinks it is pointing to with the new coordinates and nothing more.
This mount should work perfectly with the SGP centering algorithm.
Now, the most interesting thing is that we have no way to know if the mount assumes a perfectly linear relationship between RA/DEC coordinates and motor steps (this would be a “zero” pointing model) or if a complex net of anchor points is used to compensate for system nonlinearities. In other words, the existence and functionality of a pointing model is completely transparent.
If the SGP centering algorithm only works reliably when no pointing model is active, then we have a problem. Either:
- The pointing model is defective and is not transparent.
- The SGP centering is defective and uses information from the mount or makes assumptions about the mount which are dependent on the workings of the pointing model.
- The mount has an unexpected implementation for the GoToCoordinates and/or SYNC commands. They react differently when the pointing model is active.
I do not like the idea that SGP centering works only when the pointing model is disabled. This should not be the case. The pointing model should do nothing more than increasing the pointing precision of the mount and should not interfere with the centering (it should actually accelerate it). A "delta slew" algorithm should not be necessary and, if implemented, it would just cover the real problem. The system (SGP + Mount software) is flawed.
Regards,
Horia