Meade Autostar / Motor Protocol Information

Title: Autostar / Motor protocol description

Version: 2

Date: 17 Aug 2005

Introduction:

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.

Notices:

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:

A start sequence (which allows the Autostar to be sure there is a motor present)
A command sequence during which the eight bit command is sent by the Autostar
A data sequence during which some number of bits containing data associated with the command, or returned by the Autostar. The number of bits is a function of the command, but is always constant for a given command

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

The Autostar drives the clock line high
The transmitter of the bit forces the data line low (to transfer a zero value), or allows it to float high
The Autostar drives the clock line low
The receiver of the bit samples the data line to determine the bit value

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.

Cmd	Parameters	Description	Notes
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)	None	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)	None	Rotate the motor at the highest possible speed in the negative direction
0x7 (Full speed forward)	None	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)

Startup:

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

Initial alignment:

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

Sleep scope:

0x5
0xe4

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

Calibrate motors:
0x5
0xe4
(motors move at this point. I assume it's due to a low-clock reset. This lasts 1 - 2 seconds)
0x5
0x4
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.