Title:        Autostar / Motor protocol description

Version:   2

Date:        17 Aug 2005


This document describes the protocol used between the autostar (#494 ,#497) controllers and the RA and DEC motors.

This document doesn't cover the protocol used between the Autostar and devices that plug into the accessory socket as I don't have any of these accessories.

This document is not complete (there are some commands whose purpose I haven't discovered), but it should be sufficiently complete for many purposes.


The information in this document is derived from US patent #6,304,376 (held by Meade), and observation of the interactions between the Autostar controllers and the DH series motors.

The information in this document was not derived via disassembly of the Autostar or motor processor firmware.

Care must be taken to not violate the claims of the aforementioned patent in applying this information.

Any consequences of the use of this information is the sole responsibility of the user.

Interface signals:

Each motor is connected to the autostar using two signals (plus a common ground). These clock and data signals allow the implementation of a bidirectional serial protocol.

The clock signal for each motor is always driven by the Autostar, which determines the transfer timing. The frequency of the clock signal is Autostar dependent with a frequency of around 5.5 kHz.

The data signal is driven either the Autostar or the motor and appears to only be driven low. The signal is weakly pulled high by the Autostar.

Although the wiring between the Autostar and the motors would allow the two sets of signals to be completely seperated, it appears that the data lines are either tied together in the Autostar controllers.

The DH motors appear to reset if the clock line is held low for more than a few ms. I'm not sure what the magic time is.

Data transfer protocol:

The data transfer is in structured as a series of commands. Each command has:

Each bit of data after the start sequence is transferred as follows:

Start sequence:

In response to the Autostar driving the clock line low, the motor drives the data line low. This is used by the #494 Autostar to determine the presence of a motor.

The state of the data line seems to be ignored by the #497 Autostar software.

Command sequence:

An eight bit command. MSB first, is sent by the Autostar. This tells the motor what to do and what bits will be transferred later in the transfer.

Data sequence:

The most significant bit of the most significant byte (for multibye data) is transferred first. Some commands use a number of bits which is not a multiple of eight.

I know of the following commands. I've had to guess at the interpretation of some of them, and there are a few I don't know yet. Ignoring them when emulating the motor seems to work without obvious problems.

0x0 (Rotate slow)
0x1 (Rotate fast)
speed [24 bits, 2's comp, 16.8 FP format] (A->M)

Rotate the motor at the specified rate. The rate is a 24-bit 2's complement number of motor ticks per 6.5 ms period in a 16.8 fixed point fractional format
The protocol assumes that the autostar and motor act as a closed loop. The changes can be seen as the autostar converges on a sidereal tracking speed.
0x3 (Set LED current)
led value [8 bits] (A->M)
Sets the LED current used for the encoder LED.
This is stored in the Autostar and sent at initialization.
0x4 (Calibrate LED)
Tells the motor to determine the optimal LED current for the optical encoder
Unknown whether it uses this value, or whether it needs to be read and written to take effect.
0x5 (Stop) None Stop the motor The motor may continue to rotate for a short time after this command is issued
0x6 (Full speed reverse)
Rotate the motor at the highest possible speed in the negative direction

0x7 (Full speed forward)
Rotate the motor at the highest possible speed in the negative direction

0x8 (Read status)
relative position change [16 bits, 2's comp],
PWM duty cycle [8 bits], encoder error [1 bit]
(M -> A)
Read information about the position and activity of the motor.

The position is reset after this command
If the PWM value is 0xff and the position change is zero then it is likely that the motor is stalled
0x9 (Get LED current)
led value [8 bits] (M->A)
Get the LED current.
Issued after the calibrate LED command
0xb (Get motor type)
motor type [8 bits] (M->A)
Get the type of motor attached
The DH motors returns 0x10. Larger values cause the #494 autostar to indicate the ETX Autostar should be used.
0xe4 (unknown) None Unknown. Used by the autostar after the stop command when performing LED calibration. parking the scope, or sleeping the scope Doesn't seem to clear the status information.
0x2 (Set error count)
error [16 bits] (A -> M)
Add the specified error to the current position error. The servo loop will try to compensate
This is used by the pulseguide commands to nudge the scope position. For the #497 it's also used to nudge the scope to the correct position after GOTO in some cases.

The following example commands sequeces may help understand the interaction of the autostar and motors. Note that these are the #494 sequences, but they seem to be the same as the #497 ones. (Values returned by status command often differ due to differences in motor speed and command timing)


0x8 (ret: 0x0 0x0 0x0 0)
0xb (ret 0x10)
0x3 0xe7

Initial alignment:

0x8 (ret: 0x0 0x0 0x0 0)
0x8 (ret 0x0 0x2a 0xff 0) [repeated many times during slew]
0x0 0x47 0x1c 0x6f [near end of slew]

Sleep scope:


Park scope:
0x0 0xff 0xa1 0x57
0x8 (ret: 0xff 0xff 0x0 0)

Calibrate motors:
(motors move at this point. I assume it's due to a low-clock reset. This lasts 1 - 2 seconds)
0x9 (ret: 0xe7)
0x8 (ret: 0x8 0x25 0x6c 0x0 0)

Not sure about the timing of this set of commands, but each phase seems to be less that 5 seconds.