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 (published soon). 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 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.
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.