MCMTII

MCMTII

Other languages : voir la page en français.

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

Recent versions of the MCMTII (starting from 2011), 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 above, or the Ascom driver. The purpose of this project is to provide resources that will enable the MCMTII to be controlled by free software on other operating systems. There are two ways: developing a driver for the official motor unit, or developing a new protocol for the motor unit. This project aims for the first, with the creation of an INDI driver, the other way is explored by this project. They have both stopped activity before reaching a full working state, but were not far from it.

The source available from the download page is quite old. Fortunately, the authors have been kind enough to give us the version of August 2012. 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 micro-controllers, 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 if INDI is not used. A project did that but for eqmod: https://sourceforge.net/p/mcmt32/svn/commit_browser

The code of the current implementation is on gitlab.

Update April 25th, 2013: first slewing (GoTo) tests on live the real hardware. It works fine when there is no mount flipping involved, with the INDI driver, tested with XEphem and Skychart. The lib detects the flip status from the first synced position and slewing can then be used on the same half-part of the sky. Project stalled since then.

Update January 5th, 2013: first live test, serial link connection, basic commands (device ready?, version getting, EEPROM content getting, encoder value getting, slewing order, stop slewing order) confirmed to be operational. GoTo fixing for the INDI Telescope Driver is on the way, using the gathered data.

Update December 2012: a C library has been made to control the MCMTII, called libmcmtii. It supports GoTo and guiding, virtual hand-controller operation, getting and displaying the EEPROM data, getting the version, changing the current guiding speed. It does not support any writing to the EEPROM, using the MCMTII's periodic error correction.

An INDI Telescope driver has been made for the MCMTII, using libmcmtii. Skychart and XEphem have been tested offline and are able to use the telescope (not handling mount flip).

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. There is no INDI support in Stellarium.

Cartes du Ciel (skychart), XEphem and KStars use INDI to communicate with the telescopes. There are two issues regarding the default Telescope driver interface: there is no "allow flip" property, or any other flip control way, and the coordinates are given in absolute RA/DEC which need to get converted to local HA/DEC values. A property could be added to control the flip, or the flip can be done automatically on GoTo and not on guiding for example.

XEphem configuration: see the nice documentation. The strings to enter in the configuration window's goto and marker lines are MCMTII Telescope.EQUATORIAL_EOD_COORD.RA and .DEC.

Skychart configuration: put the telescope type to "MCMTII Telescope" in the telescope settings window (and INDI driver interface).

Use in existing Autoguiding software

See the full list of autoguiding software. To sum up, nothing is really working fine right now on Linux for amateur telescope autoguiding.

GoQat establishes a direct serial link with the mount (only the Losmandy Gemini) and opens the camera with the V4L2 or Unicap API. INDI support may be coming soon, for cameras to begin with. Adding support for a new mount will be complicated because lots of things are based on the capabilities of the Gemini mount. Code is C.

OpenPHD Guiding mainly uses INDI to communicate with the telescopic mount and the camera. It also supports V4L2 natively for the camera, but there does not seem to be a native alternative for mounts supported in POSIX systems. Code is C, with a bit of C++.

It should be noted that simply displaying the guiding camera image in VGA format and detecting a star in it already eats 95% CPU in OpenPHD Guiding (because it stacks frames for long exposures if the camera does not support it) and 60% in GoQat, with an AMD64 2.0GHz CPU).

RS232 protocol

The protocol for the serial link is quite simple, based on request-response exchanges.

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 two main modes of operation of the MCMTII: the guiding mode and the slewing mode. Additionally, there are some specific modes such as the EEPROM update mode and the parking mode, not yet documented here.

• 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 they are not processed correctly.
• when slewing, the main task is to provide an accurate positioning. It gives priority to steps counting. Only 2-byte serial commands, with the heavyweight 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. Slewing mode is entered when medium or max speed are used (by physical or virtual hand controller or 'p' command).
• when flashing the EEPROM, 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 (ready, guiding) or 00 (slewing)
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 (interrupts the positioning loop)	axis_id, F0	06 (ACK) or nothing if not in slewing mode

ASCII commands, 8 bytes, non-interrupting, are structured as follows.

ASCII command	Response
axis_id, {ASCII id}, {4 data bytes}, {heavyweight bits for the 4 previous bytes}, {checksum}	06 (ACK) or 15 (NOACK, never used), {data} (if response data is available)

The 5 bytes composed of the identifier and the 4 data bytes are those listed in the tables below. The identifier is the ASCII value of a letter, which are always lower than 7F and thus don't throw interrupts. The 4 data bytes are cut to 7 bit values to prevent interruptions, a 5th byte is added and contains the heavyweight-bit value for these 4 bytes. 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 i^th 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
move number of steps at max speed, the slewing command, from TelescopeMoveAxe	'p', {4 bytes of signed int32 number of steps}	none
north or west move max (slewing) speed, from MoveTelescope	'X', 0, 0, 0, 0	none
north or west move medium (slewing) speed, from MoveTelescope	'G', 0, 0, 0, 0	none
south or east move max (slewing) speed, from MoveTelescope	'W', 0, 0, 0, 0	none
south or east move medium (slewing) speed, from MoveTelescope	'F', 0, 0, 0, 0	none
north or west move min (guiding correction) speed, from MoveTelescope	'D', 0, 0, 0, 0	none
south or east move min (guiding correction) speed, from MoveTelescope	'Q', 0, 0, 0, 0	none
stop moving, resume sidereal speed (cancel guiding corrections), from Stop_Telescope	'S', 0, 0, 0, 0	none
set parking mode (sets internal flag and stops guiding), from STOP_ALL_Telescope	'P', 0, 0, 0, 0	none
unset parking mode, from ReturnToSideralSpeed	'N', 0, 0, 0, 0	none
update current guiding (sidereal) speed (or stop moving). Can be done only when sidereal speed is the current speed. The new value is reset to EEPROM's guiding speed when using commands above. from RetrieveData AlphaDelta_Internal	'R', {3 bytes (same format than 3 first bytes of 'r' reply)}, 1 for guiding direction or 0 for the other direction	none

ASCII commands for periodic error correction (PEC)

The commands listed below are used when the internal PEC is used. In most cases (in PRISM for example), this code is not used, and the PEC is managed on the computer side by software changing the current guiding speed periodically (see the 'R' command above). The MCMTII's internal PEC records the changes of guiding speed and replays them when activated.

Command	Request	Response
get current guiding speed and data for internal PEC, from RetrieveData AlphaDelta_Internal	'r', 0, 0, 0, 0	10 bytes, containing as follows (decimal values):
		current guiding 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 the EEPROM's content as described below
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.

EEPROM content

Address (dec)	Address (hex)	Content
{0..2}	{00..02}	guiding speed
{3..4}	{03..04}	correction + speed
{5..6}	{05..06}	correction - speed
{7..8}	{07..08}	slewing low speed
{9..10}	{09..0a}	slewing high speed
{11}	{0b}	acceleration
{12}	{0c}	the direction of guiding
{13}	{0d}	the direction of correction +
{14}	{0e}	the direction of correction -
{15}	{0f}	the direction of slewing low +
{16}	{10}	the direction of slewing low -
{17}	{11}	the direction of slewing high +
{18}	{12}	the direction of slewing high -
{19}	{13}	the guiding resolution
{20}	{14}	the correction + resolution
{21}	{15}	the correction - resolution
{22}	{16}	the slewing slow resolution
{23}	{17}	the slewing high resolution
{24}	{18}	the guiding amperage
{25}	{19}	the slewing low amperage
{26}	{1a}	the slewing high amperage
{28..29}	{1c..1d}	the resolution?
{30}	{1e}	first bit is the park mode
{47}	{2f}	first bit is PEC enabled