MCMTII/fr

MCMTII

Lien vers la page officielle. MCMTII (Motorisation Compatible Multi Télescope II) est une motorisation de télescope libre. Elle utilise deux micro-contrôleurs pour commander des moteurs pas-à-pas. Elle offre plusieurs moyens de contrôle : une raquette, une liaison série (RS232) qui sert aussi bien à la configuration et au contrôle total de la motorisation, et enfin une interface compatible SBIG ST-4 pour l'autoguidage.

Les versions récentes de la MCMTII (depuis 2011), qui ont subi quelques évolutions depuis la description originelle de la motorisation sur le site officiel, ne fonctionnent qu'avec Windows et le logiciel non-libre PRISM version 7 ou 8, ou bien le driver Ascom. Le logiciel interne de la MCMTII et PRISM sont développés par Alcor System. Le but de cette page est de fournir les ressources qui permettront de contrôler la MCMTII avec des logiciels libres sur des systèmes d'exploitation compatibles POSIX.

Le code source disponible sur la page de téléchargement officielle est assez vieux. Les auteurs ont été assez gentils pour nous donner les versions actuelles utilisées par PRISM (Août 2012). Il y a deux façons de comprendre le protocole série de la MCMTII, en partant le code source des deux cotés du lien :

• le code source de la DLL de communication, utilisée par PRISM et le driver Ascom. L'archive contient les sources du programme de configuration de la motorisation, et de la DLL. Voici une copie locale de la version disponible sur le site : version 1.2.3.8.zip. Et voici l'archive de la version courante donnée par les développeurs : version 2012.08.zip. Le code est en langage Delphi pour Windows.
• le code source des micro-contrôleurs, un fichier C, aussi disponible sur le site officiel, et qui est plus facile à lire que le code de la DLL pour comprendre le contenu des paquets du protocole série. Vous trouverez ici une copie locale du fichier fourni sur le site (v2.7.1), et ici la version actuelle (v2.7.5, Août 2012).

Implémentation d'une bibliothèque pour système POSIX

Le choix évident serait de développer une bibliothèque (library) portable en C POSIX. Cependant, on doit considérer que le bon choix n'est pas forcément le choix le plus évident, mais le plus utile. Vaut-il mieux écrire une bibliothèque ou une API ? Si c'est une API, en quel langage ? Les logiciels qui utiliseront la bibliothèque doivent être étudiés avant de se lancer dans n'importe quoi.

La couche d'abstraction INDI permet à tout type de dispositif de décrire ses capacité et permet aux programmes utilisateurs de les utiliser sans les connaitre a priori. Cela semble prometteur. Quelques classes de dispositifs standards, comme les télescopes ou les focusers existent déjà, et définissent les interfaces de base qui devraient être fournies par un driver INDI. Évidemment, si un dispositif supporte plus de fonctionnalités que celles décrites dans l'interface standard, le driver INDI peut être étendu. L'interface de guidage sera probablement utile aussi. Pour la création d'un driver INDI, l'idéal serait de développer une bibliothèque pour la MCMTII, comme ce qui a été fait pour Ascom.

Une interface logicielle de simulation de LX200 pour la MCMTII pourrait être créée. Cela rendrait beaucoup de logiciels existants compatibles avec la motorisation. Cela nécessite toutefois de bien connaitre les deux protocoles.

Le code source de l'implémentation actuelle est stocké dans une base subversion (SVN), située à l'adresse https://free-astro.org/svn/MCMTII/ . La base est en lecture seule pour les utilisateurs anonymes ; vous pouvez obtenir un compte (contact) et participer au développement.

Mise à jour du 25 avril 2013 : premier test de pointage (GoTo) sur le vrai matériel. Cela fonctionne, tant qu'il n'y a pas de retournement nécessaire, avec le driver INDI, testé avec XEphem et Skychart. La bibliothèque libmcmtii détecte le sens de la monture lors de la première synchronisation, et tant qu'on reste du même coté du ciel le pointage peut être utilisé (retourné ou non).

Mise à jour du 5 janvier 2013: premier test réel: connexion au port série et envoi de commandes de base (device ready?, récupération de divers paramètres comme la version, le contenu de l'EEPROM, les valeurs des encodeurs, envoi de commande simples de déplacement et d'arrêt de déplacement) ont bien fonctionné. Le GoTo du driver Telescope INDI est en cours de correction en utilisant les données collectées, et sera testé dès qu'il fera plus chaud.

Mise à jour de décembre 2012: une bibliothèque en C a été faite pour contrôler la MCMTII, appelée libmcmtii. Elle permet de contrôler un télescope en GoTo et guidage, d'utiliser une raquette virtuelle de contrôle, de récupérer et afficher les données des EEPROMs, récupérer la version, et changer la vitesse courante de guidage pour effectuer une correction d'erreur périodique du coté PC. Elle ne permet pour l'instant pas d'utiliser la correction d'erreur périodique du coté MCMTII, et d'écrire dans les EEPROMs. Le code est dans la base SVN décrite ci-dessus.

Un driver Telescope INDI a été développé pour la MCMTII en se basant sur la libmcmtii donc. Cartes du ciel et XEphem ont été testés et sont capables de communiquer avec la motorisation. Les tests réels de GoTo seront faits prochainement. Le code est aussi sur la base SVN.

Utilisation dans les logiciels de pointage (GoTo) existants

Stellarium peut interagir avec des montures de deux façons et pour seulement deux fonctionnalités : envoyer une position à pointer, et recevoir la position courante. Le premier moyen est d'établir un lien série direct avec la monture. Dans ce cas, il est nécessaire d'avoir un fichier dans le plug-in de contrôle de télescope qui crée la connexion et interagit avec la monture. Le deuxième moyen est d'utiliser un serveur autonome qui communique avec Stellarium avec un protocole simple. Dans les deux cas, le code est en C++, et une bibliothèque donnant l'accès à la MCMTII serait un bon début. Un problème est que la MCMTII ne permet pas directement de faire du GoTo absolu, et que l'interface de Stellarium est très réduite, mais cela peut être corrigé par un serveur un peu plus évolué. Un développeur de Stellarium a prévu d'intégrer le client pour le driver Telescope INDI, mais pas à court terme, c'est assez complexe.

Cartes du Ciel XEphem et KStars utilisent INDI pour communiquer avec les télescopes. Il y a deux problèmes avec le driver Telescope de base : il n'y a pas de propriétés indiquant si on permet le basculement ou non, ou quelque autre contrôle de basculement, et les coordonnées sont données en RA/DEC qui doivent être converties en valeurs HA/DEC locales. Une propriété devra donc être ajoutée pour contrôler le basculement ou celui-ci sera effectué automatiquement sur le pointage et pas sur le suivi par exemple.

Configuration de XEphem : voir la belle documentation officielle. Les chaînes de caractères à rentrer dans les lignes goto et marker de la fenêtre de configuration sont MCMTII Telescope.EQUATORIAL_EOD_COORD.RA et .DEC.

Configuration de Cartes du Ciel : mettre le type de télescope à "MCMTII Telescope" dans la fenêtre de configuration du télescope (et dans l'interface du driver INDI).

Utilisation dans les logiciels d'autoguidage existants

Voir la liste complète de logiciels pour l'autoguidage. Pour résumer, rien ne fonctionne correctement (pour l'instant) dans le monde du libre pour le guidage de télescopes amateurs.

GoQat établit un lien série direct avec la monture (seulement la Losmandy Gemini) et ouvre la caméra de suivi avec V4L2 ou l'API Unicap. Le support d'INDI devrait arriver bientôt, mais pour l'instant que pour les caméras. Ajouter le support d'autres montures sera compliqué à cause des nombreuses configurations basées sur les capacités de la monture Gemini. Le code est en C.

OpenPHD Guiding utilise principalement INDI pour communiquer avec les montures de télescopes et les caméras. Il supporte aussi V4L2 de façon native pour les caméras mais il ne semble pas y avoir de support natif pour les montures supportées sur les systèmes POSIX. Il faut voir dans quelle mesure on peut utiliser le driver Guider INDI, qui semble assez limité. Le code est en C, avec un peu de C++.

Il est à noter que le simple fait d'afficher l'image de la caméra de guidage dans un format VGA et détecter une image dedans consomme déjà 95% du processeur dans OpenPHD Guiding (parce qu'il superpose plusieurs images pour les expositions longues si la caméra ne le supporte pas), et 60% dans GoQat, avec un processeur AMD64 2.0GHz. Cela limite grandement les tests et la capacité d'utiliser ces logiciels.

Le protocole RS232

Le protocole du port série est assez simple, basé sur des échanges de forme requête-réponse.

Le premier octet des requêtes est l'identifiant d'axe, parce qu'il y a deux micro-contrôleurs dans la MCMTII, un pour l'axe ascension droite et un pour l'axe déclinaison. axis_id est `E0' pour l'axe alpha (AD), `E1' pour l'axe delta (déclinaison). Dans les requêtes et les champs de réponses des tables suivantes, les valeurs ou les identifiants représentent des octets et sont séparés par des virgules. Le PIC utilise en encodage big-endian; la plupart des donnée listées dans les requêtes ou réponses de 2 octets ou plus de long doivent être convertis si l'ordinateur est en little-endian (= Intel). Les nombres ci-dessous sont en hexadécimal, sauf indication contraire, les caractères entourés par des apostrophes correspondent en fait à leur valeur ASCII, comme c'est souvent le cas dans les langages de programmation. Les commentaires sont entre parenthèses.

Il y a deux modes d'opération principaux de la MCMTII : le mode guidage et le mode pointage. Il y a d'autres modes spécifiques comme le mode de mise à jour et le mode parking, mais nous n'entrerons pas dans ces détails ici.

• Lors du guidage, la tâche principale de la MCMTII est de fournir une vitesse de rotation constante aux moteurs. La priorité est donnée aux horloge, et les traitements des interactions (série, raquette, ST4) sont effectués en tâche de fond. Toutes les requêtes sont confirmées par un ACK même en cas d'erreur dans la requête.
• Lors du pointage, la tâche principale est de fournir un positionnement précis. La priorité est données au comptage de pas. Seules les commandes à 2 octets, avec le bit de poids lourd à 1 (les commandes non-ASCII donc), sont traitées par interruptions. La liste de ces commandes est juste en dessous. Pendant le pointage, une horloge spécifique est utilisée pour ajuster le nombre de pas duquel il faut se déplacer, en fonction du temps passé à se déplacer pour rattraper la rotation de la Terre. La MCMTII entre en mode pointage quand les vitesses medium ou maximales sont utilisées, par la raquette physique, virtuelle ou par la commande 'p'.
• en mode de mise à jour d'EEPROM les commandes peuvent être longues de 16 octets.

Les personnes qui ont besoin de comprendre la suite parlent probablement anglais, alors cela ne sera pas traduit.

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.

Commandes ASCII pour les opérations basiques

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

Commandes ASCII pour la correction d'erreur périodique (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

Commandes ASCII pour la configuration du télescope

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.

Contenu de l'EEPROM

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