Line 12: Line 12:


The [[INDI]] abstraction layer allows any kind of device to describe its capabilities and allows user-end programs to use devices without knowing about them in the first place. It sound promising. A few classes of standard devices, like [http://www.indilib.org/api//classINDI_1_1Telescope.html telescope] or [http://www.indilib.org/api//classINDI_1_1Focuser.html focuser] exist and define the basic interface that should be provided by an INDI driver. Obviously, if a device supports more functionalities than the standard interface, the INDI driver can extend it. The [http://www.indilib.org/api//classINDI_1_1GuiderInterface.html Guider Interface] will probably be useful too. About the implementation of an INDI driver, a MCMTII library should be used, like what has been done with Ascom.
The [[INDI]] abstraction layer allows any kind of device to describe its capabilities and allows user-end programs to use devices without knowing about them in the first place. It sound promising. A few classes of standard devices, like [http://www.indilib.org/api//classINDI_1_1Telescope.html telescope] or [http://www.indilib.org/api//classINDI_1_1Focuser.html focuser] exist and define the basic interface that should be provided by an INDI driver. Obviously, if a device supports more functionalities than the standard interface, the INDI driver can extend it. The [http://www.indilib.org/api//classINDI_1_1GuiderInterface.html Guider Interface] will probably be useful too. About the implementation of an INDI driver, a MCMTII library should be used, like what has been done with Ascom.
===Use in existing GoTo software===
[[Stellarium]] establishes a direct link with the mount.
[[Cartes du Ciel]], [[XEphem]] and [[KStars]] use INDI to communicate with the mount (''in what extent?'').
===Use in existing Autoguiding software===
[[GoQat]] establishes a direct serial link with the mount and opens the camera the relevant API (v4l2 or unicap).
[[OpenPHD Guiding]] uses INDI to communicate with the mount and the camera (''to be verified'').


==RS232 protocol==
==RS232 protocol==

Revision as of 02:46, 3 September 2012

MCMTII

Link to official webpage (in French). MCMTII is an open telescope motor control unit. It uses microcontrollers to command stepper motors. It has a hand controller, a serial RS232 interface for setup and control and a SBIG ST-4 compatible interface for autoguiding.

Recent versions (2011) of the MCMTII, which have undergone a few evolutions since MCMTII has been described on the website, only work with Windows and the non-free PRISM software in versions 7 or 8, or the Ascom driver. The purpose of this page is to provide resources that will enable the MCMTII to be controlled by free software on other operating systems.

The source available from the download page is quite old. Here is a local copy of the source archive for the communication DLL, version 1.2.3.8. The current version (2012.08) of the DLL, the same than in PRISM v8, has been obtained from the developers (published soon). Protocol documentation is on its way too. The code is in Delphi language for Windows. The code of the microcontrollers, in C, is available on the official download page too, and is actually easier to read than the DLL's code to understand the serial protocol. Here is the local copy of the C file. MCMTII software is developed by Alcor System, so is PRISM.

Implementing the library for POSIX systems

The obvious choice would be to code a portable (POSIX) C library. However, it must be considered that the right choice is not the obvious choice, but the most useful choice. Is it better to write a library or an API? If it's an API, in what programming language? Software that will be using the library must be studied before starting to write crazy things.

The INDI abstraction layer allows any kind of device to describe its capabilities and allows user-end programs to use devices without knowing about them in the first place. It sound promising. A few classes of standard devices, like telescope or focuser exist and define the basic interface that should be provided by an INDI driver. Obviously, if a device supports more functionalities than the standard interface, the INDI driver can extend it. The Guider Interface will probably be useful too. About the implementation of an INDI driver, a MCMTII library should be used, like what has been done with Ascom.

Use in existing GoTo software

Stellarium establishes a direct link with the mount.

Cartes du Ciel, XEphem and KStars use INDI to communicate with the mount (in what extent?).

Use in existing Autoguiding software

GoQat establishes a direct serial link with the mount and opens the camera the relevant API (v4l2 or unicap).

OpenPHD Guiding uses INDI to communicate with the mount and the camera (to be verified).

RS232 protocol

The protocol for the serial link is quite simple, based on request-response exchanges. Is it the LX200 protocol? How does it differ from it?

Three types of messages exist, as explained in the following table. axis_id is `E0' for alpha axis (right ascension), `E1' for delta axis (declination). In the fields request and response of the table, values or identifiers represent bytes, and they are separated by commas. Numbers are in hexadecimal, characters enclosed in quotes mean that's the ASCII value, like in C. Comments are between parentheses.

Command Request Response
device ready axis_id, FF 01
read encoder axis_id, F1 + byte number [0..3] (must start with F4, this copies the value in the 4 byte buffer for subsequent requests) the requested byte from the int32 value
special command axis_id, {7 bytes maximum for the command} 06 (ACK), {data} (if response data is available) OR 15 (NOACK)

Most commands then fall into the special command category. Commands start with an identifier, the ascii value of a letter. We will now see the list of special commands, separated in two categories: the list of runtime commands and the list of setup commands.

Bytes from the response buffer are referenced as {i} where i is the ith byte. PEC is periodic error correction. KING is a method for refraction compensation by offsetting the telescope pointing.

Special commands for telescope operation mode

Command Request Response
from RetrieveData
AlphaDelta_Internal, get step values for PEC
'r', 0, 0, 0, 0 10 bytes, containing as follows:
current speed steps per second = 625000 / {3} / 10 + {2} + 256 * {1}
index PecC = {4}
Pec step = 256*{5} + {6}
another step value? 256*{7}+2*{8}
Panel info pec = {9} & 0F
Pec state 1 = {9}
Pec state 2 = {10} (boolean value indicating if parked)
from RetrieveData
AlphaDelta_Internal, update current speed (or stop moving)
'R', {3 bytes (same format than 3 first bytes of 'r' reply)} none
from RetrieveData
AlphaDelta_Internal, activate PEC
'L', 2F, activate?1:0, 0, 0 (see setup commands below) none
from RetrieveData
AlphaDelta_Internal, erase PEC
'e', 0, 0, 0, 0 none
from RetrieveData
AlphaDelta_Internal, save PEC
'E', 0, 0, 0, 0 none
from TelescopeMoveAxe, move number of steps 'p', {4 bytes of int32 number of steps} none
from MoveTelescope, north or west move max speed 'X', 0, 0, 0, 0 none
from MoveTelescope, north or west move medium speed 'G', 0, 0, 0, 0 none
from MoveTelescope, north or west move min speed 'D', 0, 0, 0, 0 none
from MoveTelescope, south or east move max speed 'W', 0, 0, 0, 0 none
from MoveTelescope, south or east move medium speed 'F', 0, 0, 0, 0 none
from MoveTelescope, south or east move min speed 'Q', 0, 0, 0, 0 none
from Stop_Telescope, stop moving, resume sideral speed 'S', 0, 0, 0, 0 none
from STOP_ALL_Telescope, move to parking position 'P', 0, 0, 0, 0 none
from ReturnToSideralSpeed, no park mode 'N', 0, 0, 0, 0 none

Special commands for telescope setup mode

Command Request Response
loading setup (read from
MCMTII's EEPROM)
'K', 0, 0, 0, 0 48 bytes, containing as follows:
{1..3} is guiding speed
{4..5} is correction P speed
{6..7} is correction M speed
{8..9} is point L
{10..11} is point R
{12} is acceleration
{13} is boolean for inversion
{29..30} is the resolution
saving setup (write to EEPROM) 'L', setup command ID, data ... none
get MCMTII's version 'V', 0, 0, 0, 0 a string up to 80 characters
flash EEPROM (put device in special programming mode) 'M', 0, 0, 0, 0, followed by data: none
dev_id (initialize transfer) EB (IDACK)
E3 (WRITEBOOT), address high, address low, length (10), checksum, {10 bytes data} E7 (DATA_OK), E4 (WOK) (success)
ED (DONE), {whatever?} E4 (WOK) (success)

For setup command IDs, see code of procedure TSetupTelescope.Button_EcrireClick in Setup.pas (from the DLL code) or the C code of the microcontroller. Speeds, precisions and corrections are set using these commands.