telescope control

[malc-c]

Just wondering how the software / drivers work when a SW synscan unit is used to control a telescope.

When you click on a star or object in the astronomy program, does it send the positioning co-ordinates to the synscan unit as in "goto RA DEC" or does it keep sending commands and receives feedback until it "knows" where the scope is pointing?

I'm just curious as I seem to get better goto accuracy with the hand controller than when I use CdC with EQMOD.

Don't get me wrong, I'm not having a bash at EQMod or Cdc, just trying to understand (in simple terms) how these things work and why these strange things are occuring.

[chrisshillito]

A planetatrim commanding the mount via ASCOM or in-built celestron nexstar protocol will simply say goto RA/DEC. When the handcontroller receives this command it calculates how much to movement is required of the mounts RA/DEC stepper motors and instructs the mount to move the motors accordingly. To do this the handcontroller has to take into account its alignment model, current time, site location etc.

Chris.

[malc-c]

Chris, as ever I'm indebted to your knowledge on this. So in theory, the ASCOM driver sends the chosen RA and DEC to the synscan unit, this then works out the number of steps should be applied to each motor based on where it's starting point is and, in the case of EQMOD, what data has been entered for the observatory location a the system time. If so then that rules out the astronomy program / pc timing causing the mis-alignment issue.

[chrisshillito]

Yes. When using ASCOM the planetarium uses an ASCOM slew command which pases the target RA / DEC coordinates to the driver. In the case of the Celestron ASCOM driver a nexstar type command is then sent to the handcontroller (using RA/DEC coords) which in turn sends low level motor commands to the mount. In the case of the EQMOD the EQASCOM driver sends low level motor commands to the mount and there is no "nexstar layer" needed.

Both Synscan and EQMOD need the same data to calculate where to move the motors to for a given RA/DEC target i.e. current time, location, starting position. The target motor positions are then adjusted to take into account the effect of any alignment model. The alignment model aims to measure and correct the pointing error that represents the combination of:

home position error

polar alignment error

system time error

cone error

optical distortions

It is in the implementation and application of the alignment model that EQMOD and Synscan will most likely differ the most and alignment strategies that work well for one may not represent the best for the other.

[malc-c]

It is in the implementation and application of the alignment model that EQMOD and Synscan will most likely differ the most and alignment strategies that work well for one may not represent the best for the other.

So in effect EQMOD has to learn these errors and correct it's mistakes through multiple point alignment etc, where as the hand controller is more likely to have these pre-programmed.

Thanks for your detailed explanation in lay-man terms.

[chrisshillito]

No, the handcontroller has to learn and compensate for exactly the same errors via its own alignment routines. However, the way you create and apply alignment models are different between the hand controller (1, 2 and 3 star alignment with restricted star lists) and EQMOD (unrestricted N-Point using three point and/or nearest point transforms).

Chris.