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. MCMTII software is developed by Alcor System, so is PRISM. 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. Fortunately, the authors have been kind enough to give us the current versions (August 2012). Protocol documentation is on its way too. There are two ways to understand the serial protocol for the MCMTII, using source from both sides of the serial link:
- the source archive for the communication DLL. The archive contains sources of the setup program used to configure the MCMTII, and of the DLL used by PRISM or by the Ascom driver. Here is a local copy of the archive available on the website, version 1.2.3.8. Here is the current version (2012.08) of the DLL, given by the developers. The code is in Delphi language for Windows.
- the code of the microcontrollers, a single C file, 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 website's C file (v2.7.1), and Here is the copy of the current version (v2.7.5, August 2012).
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.
A software LX200 interface for the MCMTII could be created too. That would make more software compatible with it easily.
The code of the current implementation is stored on a subversion repository, located at https://free-astro.vinvin.tf/svn/MCMTII/ . It is read-only for anonymous users, you need to get an account (contact) to have a write access.
Use in existing GoTo software
Stellarium can interact with mounts in two ways, and for only two functionalities: send GoTo and receive current position. The first way is to establish a direct serial link with the mount, in which case it needs to have a file in the Telescope control plug-in that creates the connection and interacts with the mount. The second way is to use a standalone server that communicates with Stellarium with a simple protocol. In both cases, the code is C++, and a library giving access to MCMTII would be a good start.
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 with 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.
Requests are always 8 bytes long. The first byte is the axis identifier, because there are two micro-controllers in the MCMTII, one for the right-ascension and one for the declination axis. axis_id is `E0' for alpha axis (right ascension), `E1' for delta axis (declination). In the request and response fields of the tables below, values or identifiers represent bytes, and they are separated by commas. PIC is big-endian; most data listed in the requests or replies 2- (or more) byte long must be converted if the computer is little-endian (Intel). Numbers below are in hexadecimal, characters enclosed in quotes mean that's the ASCII value, as in many programming languages. Comments are between parentheses.
There are three modes of operation of the MCMTII: the guiding mode, the slewing mode, and the EEPROM update mode.
- when guiding, the main task is to provide a constant motor rotation rate. It gives priority to the clocks and backgrounds the processing of the serial link. All commands are replied with an ACK even if it doesn't apply.
- when slewing, the main task is to provide an accurate positioning. It gives priority to steps counting. Only 2-byte serial commands, with the 8th bit high (non-ASCII commands), are processed as interruptions. The list of these commands is just below. During the slewing, a specific timer is used to adjust the number of steps to move to, as function of the time spent to slew.
- when updating, commands are 16 bytes long.
Below is the table of the three non-ASCII, 2-byte, interrupting commands.
| Command | Request | Response |
|---|---|---|
| device ready | axis_id, FF | 01 |
| read encoder | axis_id, F1 + byte number [0..3] (must start with F4, as it copies the value in the 4 byte buffer for subsequent requests) | the requested byte from the int32 value |
| stop slewing (emergency with no deceleration? not used in PRISM) | axis_id, F0 | 06 (ACK) |
ASCII commands, 8 bytes, non-interrupting, are processed like that:
| Command | Request | Response |
|---|---|---|
| ASCII command | axis_id, {ASCII identifier} {4 data bytes}, {heavyweight bits for the 4 previous bytes}, {checksum} | 06 (ACK), {data} (if response data is available) OR 15 (NOACK) |
The next 7 bytes start with an identifier, the ASCII value of a letter. Following that, the 6 bytes contain actually 4 command data bytes cut to 7 bit to prevent interruptions, the 5th byte contains the heavy-bit value for the 4 command bytes, and the last byte is a checksum. Below are lists of ASCII commands, separated in three categories: the list of usual runtime commands, the list of periodic error correction commands, and the list of setup commands.
Bytes from the response buffer are referenced as {i} where i is the ith byte. KING refers to a method for refraction compensation by offsetting the telescope pointing. from SomeFunction indicates in what function of the DLL the command is used.
ASCII commands for basic telescope operation
| Command | Request | Response |
|---|---|---|
| update current speed (or stop moving) from RetrieveData AlphaDelta_Internal |
'R', {3 bytes (same format than 3 first bytes of 'r' reply)} | none |
| move number of steps, from TelescopeMoveAxe | 'p', {4 bytes of int32 number of steps} | none |
| north or west move max speed, from MoveTelescope | 'X', 0, 0, 0, 0 | none |
| north or west move medium speed, from MoveTelescope | 'G', 0, 0, 0, 0 | none |
| north or west move min speed, from MoveTelescope | 'D', 0, 0, 0, 0 | none |
| south or east move max speed, from MoveTelescope | 'W', 0, 0, 0, 0 | none |
| south or east move medium speed, from MoveTelescope | 'F', 0, 0, 0, 0 | none |
| south or east move min speed, from MoveTelescope | 'Q', 0, 0, 0, 0 | none |
| stop moving, resume sideral speed, from Stop_Telescope | 'S', 0, 0, 0, 0 | none |
| move to parking position, from STOP_ALL_Telescope | 'P', 0, 0, 0, 0 | none |
| no park mode, from ReturnToSideralSpeed | 'N', 0, 0, 0, 0 | none |
ASCII commands for periodic error correction (PEC)
| Command | Request | Response |
|---|---|---|
| get step values for PEC, from RetrieveData AlphaDelta_Internal |
'r', 0, 0, 0, 0 | 10 bytes, containing as follows (decimal values): |
| current speed steps per second = 625000 / {3} / 10 + {2} + 256 * {1} | ||
| index PecC (PEC_BASE) = {4} | ||
| Pec step = 256*{5} + {6} | ||
| another step value? 256*{7}+2*{8} | ||
| Pec state 1 = {9} (0: no PEC, 1: PEC activated, 2: PEC recording about to start, 3: PEC recording) | ||
| Park state = {10} (0 or 1) | ||
| activate PEC, from RetrieveData AlphaDelta_Internal |
'L', 2F, activate?1:0, 0, 0 (see setup commands below) | none |
| erase PEC, from RetrieveData AlphaDelta_Internal |
'e', 0, 0, 0, 0 | none |
| save PEC (start recording), from RetrieveData AlphaDelta_Internal |
'E', 0, 0, 0, 0 | none |
ASCII commands for telescope setup
| Command | Request | Response |
|---|---|---|
| read byte from MCMTII's EEPROM | 'J', address, 0, 0, 0 | the_byte from EEPROM |
| read all from MCMTII's EEPROM (setup data) | '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', address, one or two data bytes (see below) | 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 save setup, ('L' command), there are two bytes read if((address < 11 && address != 2) || address > 47) (decimal values), else, only one. See code of procedure TSetupTelescope.Button_EcrireClick in Setup.pas (from the DLL code) or better, the defines at the beginning of the C code of the microcontroller. Speeds, power, precisions and corrections are set using these commands.