goto EM200b

[matteo 0]

Bonjour à tous, je viens d’acquérir une EM200b, et j’aimerais modifier l’électronique pour faire du GOTO . Sur le marché, il existe plusieurs choix, Temma, FS2, Dynostars, Pic Astro ….., on propose aussi le changement des moteurs d’origine par des moteurs SECM3 pour les électroniques type FS2 .
Quel est l’avantage de changer les moteurs, la qualité du suivi et du pointage est-elle meilleure ?
Le Temma a-t-il le meilleur suivi et pointage de tous les systèmes cités au dessus ?
Merci par avance pour vos réponses

[micv 11]

au niveau pointage, ep,etc je ne pas qu'il y ai de grande difference ,les systemes dont tu parle on deja fait leur preuves.
par contre, il faudrait comparer les capacités des systeme, je pense notemment au temma qui m'a un peu déçu avec l'em200 temma jr comparativement aux autres: pas de fonction parking,pas de compasention de backlash,pas de pec,pas de tracking off via le pc...attention aussi à l'inversion au meridien, les systemes reagissent differement.des choses trés interessantes pour l'imagerie et à prendre a compte si on evolue vers un poste fixe.je connais pas trop le fs2 ou le dynostar, mais il faudrait voir si ils peuvent faire les fonctions ci dessus.dire que j'ai un ssk2000 qui fait tout ça sur ma gpdx :-(

a+
michael vanhuysse http://astrosurf.com/astro-mike/

[Pierre 309]

Micv: si si il y a une fonction parking dans la protocole Temma mais elle n'est pas utilisée par TT2000, de même qu'une possibilité de déplacer le méridien d'une heure, deux heures etc utile en imagerie. Le PEC ne m'a jamais emballé de ce que j'ai vu sur d'autres montures.

En ce qui concerne le Temma, j'ai eu un souci de pointage avec une erreur "Guiding failed" en voulant me déplacer de Altair à M16 et pas moyen même avec resynchronisation, arrêt du logiciel etc d'y aller pfff.. Là ça fait cher le goto .

En revanche, le pointage est assez précis, l'objet est dans un champ de 11.4'x8.6'

Rémi Petitdemange a travaillé sur un développement du protocole Temma ici : http://www.optique-unterlinden.com/temma2/driver_pl/htm/temmadriver_fr.htm http://www.optique-unterlinden.com/temma2/driver_pl/htm/sommaire_driver.htm

[micv 11]

salut pierre, effectivement j'en avait discuté avec remi de cette alternative, mais c'est un driver non officiel au temma, et qui ne fonctionnera qu'avec ce logiciel,qu'en j'entend fonction parking, c'est quelque chose d'accessible via les softs du marché, par exemple the sky, qui est la reference...ou carte du ciel,et les autres.
j'ai egalement proposer à remi d'essayer son soft pour mon poste fixe, je n'ai pas encore eu le temps de m'y mettre...
mais j'ai choisi de pendre la voie du remote automatisable pour l'imagerie,avec des softs genre ccd autopilot, et la ,le temma n'est pas du tout integré a ce genre de soft, (tout comme avec ccd commander, ou acp3dreams),car il utilise les drivers officiels...
reste la solution ascom, avec des drivers non officiels encore une fois, et qui ne marche pas forcemment trés bien et qui ne sont pas integré avec les softs automatisable.
par exemple le driver de chuck faranda, qui propose le parking,tracking off,etc... mais qui fonctionne 1 fois sur trois chez moi, je suis d'ailleurs en contact avec lui pour travailler dans ce sens.mais cela reste des alternatives, et des prises de tete.
quand on possede un systeme parfaitement integré, genre ssk,( je sais j'en revient a lui),ou lx200, qui l'un des protocoles les plus utilisé tout fonctionne correctement.quand on voit les moults possibilitées de ces softs (ccd autopilot,ccd commander,acp..) et que l'on passe a coté de plein de chose , c'est la que le bas blesse...
maintenant, si on n'envisage pas un poste fixe,pas d'imagerie,le temma fonctionne bien, mais comparativement a ce qui existe sur le marché, il y a mieux, pour pas forcement plus cher.
ceci dit c'est peut etre une volonté commercial de takahashi,mais je trouve cela dommage que nos amis japonnais a la pointe de la technologie électronique, ne sont pas au top a ce niveau.remi va peut etre s'exprimer sur le sujet?

je me suis un peu eloigné du sujet de notre ami,desolé, mais quelques precisions permettent de bien choisir.;-)
a+
michael vanhuysse http://astrosurf.com/astro-mike/

[Ce message a été modifié par micv (Édité le 20-08-2006).]

[Pierre 309]

Michael: Ok, tu recherches un système élaboré pour ton installation remote. Je comprends. Le Temma n'est pas fait pour toi dans ce cas... Mais il marche pas trop mal en imagerie, enfin pour ce que j'en utilise dans ce domaine

Mes excuses à Matteo pour la dérive du sujet initial .

[Ce message a été modifié par Pierre (Édité le 20-08-2006).]

[micv 11]

entierement d'accord avec toi pierre, le temma fonctionne trés bien!il y a juste des systemes plus elaborés ;-)
a+
michael vanhuysse

[matteo 0]

Je vous remercie Pierre et MICV pour vos réponses, C’est vrai que le sujet est vague et que je n’ai pas été assez précis sur la question. En faite après avoir lu et relu des forums, je me dirige vers la formule FS2…, mais dans ce cas est-il avantageux de changer les moteurs ( SECM3) ?
Le Temma a peut-être moins de fonction que le FS2, mais le système avec encodeur est peut- être plus précis que le FS2 qui prend en compte les pas des moteurs, de plus en prenant l’option Temma , tout est changé, les nouveaux moteurs ont-ils une grande souplesse de fonctionnement et un très bon suivi ?
Pour ma part, je fait de l’imagerie numérique d’objet qui sorte un peu des sentiers battus, d’où avoir une bonne recherche auto et une bonne qualité de suivi .

[micv 11]

pour avoir vu (et entendu) tourner les moteurs secm3, c'est de tres bonne qualité, ils sont impressionnant de silence...
concernant le pointage entre le temma et le fs2, je ne pense qu'il ne doit pas y avoir de grandes differences, encodeur d'un coté,et calcul de pas de l'autre, c'est de toute facon les jeux mecaniques de la monture qui limiteront la precision.pour le suivi, on parle de moteurs de bonne qualité,donc mit a part les etages de reduction qui peuvent creer des sous periodes dans la courbe d'ep,c'est tres similaire a mon avis.
a toi de comparer les fonctionalités des systemes goto en fonction de tes besoins,et de tes evolutions ;-)
pour un bon suivi, il faut aussi envisager l'autoguidage suivant la focale que tu vas utiliser.et la ce n'est plus vraiment les moteurs and co, qui affecte la precision, mais purement les jeux mecaniques et l'ep de la monture.
si l'option est de prendre le fs2 l'interet est aussi de changer les moteurs pour des secm3.les moteurs d'origine de l'em200b sont certainement moins performant.
ou le temma pc avec les moteurs usd3.dans tout les cas le changement de moteur est un plus.reste a voir le budget...
c'est surtout mon avis, d'autres viendront peut etre?
a+
michael vanhuysse

[Rémi Petitdemange 120]

Bonsoir,

Désolé c'est long ...

Matteo :
Pour le FS2 mieux vaut changer les moteurs d'origine car ils sont limités en vitesse de pointage 32X ou 50X mais bon c'est pas une obligation
car le FS2 est capable de gérer ces moteurs impeccablement même lentement.
Encore faut-il qu'ils soient en bon état mécanique.
Avez-vous une EP sur l'état actuel c'est très instructif avant d'investir dans autre chose !

Je ne vais pas de faire pub pour tel ou tel systeme, pour moi le meilleur est celui qu'on apprivoise vite, celui qui est sûr et stable.
Qualité d'intégration pour le Temma et autonomie complete par rapport au PC pour le FS2 sont pour moi les premières qualités de chacun.
Ensuite chacun voit midi à sa porte et là y a le choix du coeur
La monture si elle est bien réglée mécaniquement fera le reste tant que les moteurs RA et DEC sont en bon état et bien montés.
Régulièrement des micro-réducteurs usés ou déffectueux sont cause de gros soucis d'EP !
Sinon les plus belles EP que j'ai vu venaient de l'USD2/3/TemmaJR en EM-200 (les plus nombreuses testées aussi).

Pierre :
Merci d'avoir passé les liens ici
ci-dessous des infos et une pub outrageuse pour mon script Temma qui serra finalement peut-etre utile à certains utilisateurs sous Windows

Pour le Temma le protocole est simple (minimalisme nippon oblige) et particulièrement adapté aux montures allemandes puisque né sur ces montures au début des années 90 (exporté malheureusement seulement en 2001).
On envoi une RA/DEC au firmware et la monture fait son pointage, elle gère sont retournement si nécessaire.
Pour ce faire le firmware doit connaitre :
- Le temps sidéral local (TSL) qui est la RA en cours au méridien local pour définir le vérrou méridien.
(calculé à partir de la date/TU et la longitude comme chacun sais ).
- La latitude qui est la DEC du zénith pour définir le vérrou "horizon".
- Le coté de la monture où se trouve le scope (coté Ouest vu par défaut à la mise sous tension).
- Une bonne mise en stat et une initialisation sur le zénith (pour approximation) ou/et sur une étoile (pour faire précis) suffisent.
Le mode F recommande chaudement les 2 d'affilées et on est tranquille toute la nuit sans même utiliser une seule fois le chercheur.

Les 2 vérrous "méridien" et "horizon" sont là pour "sécuriser" les manoeuvres de pointages :

- vérrou "horizon" : si l'objet pointé se trouve à moins de 5° au-dessus de l'horizon théorique le pointage ne se fait pas.
Un message d'erreur (R4 pour ne pas le nommer) est retourné par le firmware et c'est au soft de le traduire en clair à l'utilisateur...

Votre message "Guiding failed" est plutot bizarre, quel soft peut commettre un truc pareil dans cette condition ?
Quelle date et heure TU était-il ?
Votre latitude était-elle juste ?
Les coordonnées étaient-elles saisies manuellement ou automatiquement par clique de souris sur un carte ?
Le port série est-il stable à toute épreuve sur votre PC (série natif ou USB série) ?

- vérrou "méridien" : il ne provoque pas de blocage du pointage.
Il passe l'info TSL au firmware qui prendra la décision de pointer directement ou par retournement.
La position du scope sur la monture est déterminante (coté Est ou Ouest, tag E ou W sur les softs).
Mieux qu'un verrou c'est plutot une charnière et si il est exploité coté soft on en fait ce qu'on veut dans les limites imposées par le matériel.
(longueur du tube optique, usage d'un trépied ou d'une colonne...).
D'où le vérrou réglable LST+/-1, LST+/-2 et LST+/-3 dans mon script Temma.
J'aimerai bien que ce soit implémenté ailleurs mais pour le moment sauf erreur de ma part c'est pas le cas .
Info ici : http://www.optique-unterlinden.com/temma2/driver_pl/htm/ajustement_verrou_temma.htm

Le firmware ne retourne rien à ce sujet et la décision revient au soft de prévenir ou pas l'utilisateur si on va avoir un retournement.
Perso je préfère savoir ce qu'il va se passer d'avance sans avoir à réflechir (y a pas que ça à faire ).
On est jamais assez prudent avec des cables de partout en poste distant sans visibilité du matériel
(le remote c'est mon cas c'est grave docteur ? ).
En général aucun avertissement n'est passé à l'utilisateur d'où la surprise du néophite quand la monture pointe en faisant un retournment.
(on pense même à une erreur de pointage la première fois, bref, si tous les cable sont encore branchés ça va mieux ! )
On est sur monture allemande et le firmware essaye d'immiter l'utilisateur prudent équipé d'un tube long en faisant des pointages croisés type scope coté Ouest et pointage coté Est et inversement.
Pour l'imagerie on veut souvent un truc du genre :
Scope coté Est et objet pointé coté Est pour avoir du temps devant soit pour lancer 6 heures de poses et ça le vérrou méridien l'empêche en laissant le scope sur le coté Ouest au pointage ou le cas échéant en provoquant un retournement d'Est en Ouest du scope (bref pas ce qu'on veut !).
Malheureusement cette possibilité n'est pas encore exploité à ma connaissance et c'est pour cela qu'on la trouve dans mon script en attendant !

Alors Pierre, pointer M16 depuis Altair vous pose un pb :
Avez-vous essayé l'inverse du temps que y étiez ?
Il n'y a pas de raison que ça coince au niveau du firmware tant que l'objet se trouve 5° au dessus de l'horizon.
Dans ce cas le pointage n'est pas vérouillé par le firmware (pas de verrou "horizon").
Si y a vérouillage du firmware le soft devrait retourner un message d'erreur approprié genre "objet sous l'horizon" ou équivalent dans la langue de Shakespeare ... mais bon les messages d'erreurs sont parfois un peu abscons coté PC .
Si M16 vient de passer le méridien alors que votre scope est coté Ouest de la monture et pointé sur Altair qui est encore à l'Est du méridien :
Il y a retournement de la monture au pointage si le verrou "méridien" est le méridien lui-même (verrou du firmware généralement utilisé par les drivers des softs ou Ascom comme dit plus haut et par simplification ou par sécurité on va dire...).
Si le scope est coté Est de la monture et que Altair et M16 ont passé toutes les 2 le méridien depuis un moment il est problable que ce soit le vérrou "horizon" qui bloque le pointage.
Une "synchronisation" ne sert à rien dans ce cas ni un relancement du soft !
On pourrait dévérouiller soit-même en modifiant le paramètre de latitude (passer à 40° au lieu de 48°) si nécessaire.

Michael : oui faut qu'on cause .
C'est juste pour dire mais pour moi le remote et l'imagerie sont ok, parquage y compris bien que pas encore utile pour moi
La mise en standby de la motorisation, accessible en remote, permet de faire un parquage quelconque récupérable le lendemain à la remise sous tension de la monture (synchro sur la position de parquage au démarrage du script par exemple).
En revanche on ne peut pas commander en remote la mise hors tension ou sous tension de la monture mais ce n'est pas rédibitoire si on est encore en état d'atteindre et d'éteindre manuellement la monture au final .

J'use et abuse du remote depuis que j'ai le Temma en perfectionnant régulièrement mes scripts Temma c'est mon truc pour gaspiller du temps libre .
(très efficace au passage )
Je passe une heure à installer mon setup et puis basta, j'enfile mes charentaises et hop je regarde la TV comme tout le monde, euh mon PC pardon pour les pointages, acquisitions (CCD Platinum), autoguidage webcam etc ...
Arhhhhgg faut encore pointer l'étoile guide sur place quelle galère !!!
Ceci dit je n'utilise pas de camera Sbig et ne peut donc tout fait comprendre vos besoins spécifiques et c'est précisément là-dessus qu'il faudrait discuter pour faire avancer les choses !
Le logiciel libre AudeLA n'a pas la philo ni le hightech des usines à gaz US mais il permet déjà le controle en remote d'un setup complet.
Il faut consulter la liste du matériel compatible sur le site AudeLA. Ok là n'est pas tout à fait le propos.

Qu'appellez-vous driver officiel ? Pour moi rien n'est officiel dans cette histoire mais je peux me tromper !
Takahashi a mis à dispo son protocole et les éditeurs US de softs comme Bisque ont écrit leur propre driver Temma tout en implémentant ensuite parallèlement Ascom.
Chuck (Ascom Temma) devrait régler rapidement ce bug qui traine sur ce point
Que manque-t'il aux drivers dits officiels ?
Je veux bien discuter directement avec Bisque ou autre éditeur concerné pour l'optimisation de leurs drivers Temma par utilisation complète du protocole ou par ajout de quelques fonctionnalités complémentaires au protocole, on peut rêver
Quelles seraient à vos yeux les fonctions utiles à ajouter directement au firmware ?
Qu'entendez-vous par élaboré par rapport à votre GPDX, avez vous des souhaits précis ?
Et que dire de l'interfaçage avec les autres devices utilisés (CCD, focuser...), les interfaces clients-serveurs qu'on trouve chez Bisque ?
Là on est dans un autre monde où la robotisation et l'intégration a toujours été très en avance.

Pour info, Indi est je crois multiplateforme, mais surtout il fonctionne en réseau TCP/IP (archi clientsAstro-serveursIndi) avec distribution de matériel. De nouveaux drivers arrivent régulièrement. C'est une techno alternative pour le remote qui a de l'avenir pour l'amateur.

Cordialement,
Rémi

[Pierre 309]

Rémi: merci pour toutes ces explications, le soft en question est TT2000, Carte du ciel cafouillant toujours autant avec le Temma. En heure TL, il devait être 23h30 environ. Pas essayé le trajet inverse, mais j'avais pris la précaution de décocher l'option "5 deg".

je vous appelle mardi pour en causer. .

[Ce message a été modifié par Pierre (Édité le 21-08-2006).]

[Astromania 5]

Bonjour,

Très intéressante cette discution surtout que j'ai une EM200 Temma 2, une SBIG et le souhait d'utiliser tout ça en remote "local" (dans le fond du jardin) dès que je pourrais...

Comme Michael, je regrette vivement l'absence de certaines fonctions du Temma!
Le principal reproche étant l'absence de PEC. La plupart des montures motorisées ont le PEC aujourd'hui même les moins chères !!
Sur le coup, Taka à 20 ans de retard dans ce domaine... Un PEC bien fait (calculé automatiquement, par exemple, par PemPro) permet de bien améliorer les choses...
Par exemple:
Mount Manufacture PE Before PE After Reduct
Paramount ME Software Bisque 3.8" 0.8" 78%
AP 1200 Astro Physics 4.2" 1.3" 70%
MI 250 Mountain Instr 4.2" 1.4" 82%
AP 900 Astro Physics 5.8" 1.6" 73%
Titan Losmandy 7.5" 1.5" 80%
G-11 Losmandy 9.1" 2.3" 75%
RCX400 Meade 31.5" 6.7" 79%
LX200GPS Meade 45.9" 7.5" 84%
LX200 Classic Meade 53.3" 12.7" 76%

C'est vrai qu'avec le recul, mon choix se portertai plutôt vers une AP900...

Un gros défaut c'est la nécessitée de basculer en vitesse normale (NS) après un recentrage ou un pointage à la raquette !
Je ne compte plus les fois où j'ai lancé ma calibration d'étoile guide en HS ! .. et les insultes quand ma monture se barre en vitesse rapide durant 12 secondes et qu'il faut tout recommencer!

Les autres fonctions manquantes sont bien sur:
Le Parking
Le réglage du passage au méridien
Le Tracking Off

Au niveau du Driver, l'activation d'alertes visuelles ET Sonores (fichier Wav ?) permettant de connaître (en regardant la télé ):
* Le passage du méridien
* L'approche de la limite fixée avant retournement de la monture.

La plateforme ASCOM me semble une bonne solution, car elle est reconnue et utilisable par beaucoup de logiciels...et c'est "Standardisé".

Je me vois mal installer le Perl/Tk sous windows pour simplement utiliser un driver....
Et je ne me vois pas du tout me passer de TheSky et de sa connection avec la monture (TheSky est quand même une référence pour les CCDistes "SBIGiens")
Il faut absolument un driver 'intégré' (ASCOM ?) aux soft de pointage et être utilisable directement par script (VBS, Visual Basic, etc...).
CCD Commander, CCD Autopilot, etc... sont quasi-indispensables pour plannifier des acquisitions durant la nuit... (car il faut gérer aussi les nuages, la fermeture du toit coulissant ou du cimier, etc...)

Rémi: Où peut-on avoir les descriptif détaillé du protocole Temma ?
Y a t-il un driver Temma "ASCOM" en open source où l'on puisse récupérer les sources ?

Il faudrait lister les fonctions des systèmes les plus courant, et faire le tri de ce qui serait utile d'avoir dans le driver Temma...

Dans un autre domaine, qui se sent capable de créer une convertisseur USB vers Ethernet ?
L'utilisation de l'USB pou piloter la caméra SBIG n'est vraiment pas Top en Remote (dixit Laurent Bernasconi), l'idéal reste un pilotage par Réseau Ethernet.
Cela existe et fonctionne bien l'Audine (EtherAude), mais rien n'existe pour les SBIG.... Y a un marché

Cordialement.
Vincent V.
http://www.astrosurf.com/astromania

[micv 11]

desolé , c'est long ;-)
je rejoint vincent, tout ce qui manque au temma c'est ce qu'il a ennoncé... et le temma friserai la perfection ;-)

remi, pour le parking, c'est l'inconvenient de devoir couper manuellement l'alimentation du temma pour arreter le suivi.certains on automatisé ce processus via des modules externes (mais à quel prix!)comme l'astro hub: http://www.aquest-inc.com/AstroHub/AstroHubHome.htm
il ne me semble pas qu'il soit necessaire de couper l'alimentation sur les autres montures goto?je me trompe peut etre.dommage encore une fois qu'il faille intervenir physiquement pour que cela marche.
concernant audela, j'ai essayé d'utiliser audace un moment avec quelques bugs,mais je l'utilise encore pour le king.pour moi, les softs bisque,ccdware, etc, sont completement fonctionnels avec les sbig,et en plus d'etre intuitifs,ça marche sans prise de tete.je suis plutot partisan du plug and play, si tu voit ce je veux dire.
par contre, le travail fait sur audela ainsi que les audines est remarquable!mais ,(je pense), specifique à audine ce qui est normal...c'est vrai que je ne suis pas certain que d'ici quelques temps les possibilitées "d'usine a gaz" comme tu le cite ne seront pas accessible aux sbig et au temma via audela .j'en serait ravi.et cela me couterait moins cher ;-)
concernant les drivers "non officiels" , j'ai simplement reprit le titre de la page web de ton driver...;-) comme tu le nomme driver "non officiel" , je suppose donc que l'officiel est celui livré d'origine avec le temma et le tt2000? m'aurait-on menti? ;-)
pour le driver de chuck, il vient de m'envoyer une version beta à essayer pour le parking justement... je suis convaincu qu'il reglera cela sous peu, il est trés réactif malgré qu'il est sur d'autres projets.son driver possede de tres bonne idées: un timer d'arret pour le suivi,le parking suivant des coordonnées precise en altaz avec un slew , ou le parking à la position courante,un reglage de la vitesse de guidage qui reste en memoire,une fonction tracking off...
plein de potentiel.
pour bisque, j'ai contacté daniel bisque pour lui poser la question du parking intégré à the sky, il a repondu en me disant que c'était au programme des prochaines mise a jour (sans delai malheureusement...)
concernant ma gpdx, c'est plutot le skysensor 2000pc que je trouve difficile a mettre en defaut (ce sont des japonais au passage ;-)),pec, parking, tracking off, reglages de backlash sur les deux axes,choix du protocole (ssk, lx200,et d'autres), suivi cometaire, suivi artificiel pour les satellites par exemple,alerte de passage au meridien (debrayable), si,si vincent...je le trouve plus que complet, et ça fonctionne...il rivalise a mon avis avec les systeme goto us sans probleme. j'ai d'ailleurs vu qu'au japon des montures takahashi était montée avec le ssk,tu est au courant?faut il changer les moteurs dans ce cas la? je me souviens avoir vu dans les menu du ssk que l'on pouvait configurer les rapports de reduction,nombre de dents des couronnes etc...
mais,je m'eloigne du sujet...
"Et que dire de l'interfaçage avec les autres devices utilisés (CCD, focuser...), les interfaces clients-serveurs qu'on trouve chez Bisque ?"
heu,je ne comprend pas ta question,les focusers,roue a filtres,rotator,etc sont completement fonctionnels avec les softs bisque.il est vrai que la plupart sont d'origine americaine (optec,fli,etc...). si le sens de ta question était d'intégrer ceux ci dans le driver temma,oui pourquoi pas, mais il existe des softs qui fonctionnent bien, pourquoi ne pas en profiter,peut etre faut il faire communiquer les softs entre eux.ça ne doit pas etre simple!
sinon, dés que je trouve un peu de temps , j'essaye ton driver,au vu des fonctionnalitées, c'est du beau travail...
mais cela fait peut etre prendre une "voie" differente des softs bisque, ou ccdware, notemment ccdautopilot3, que je trouve remarquable.(ce n'est malheureusement pas les memes budgets de developement de logiciel par rapport à audela, et cela peut se comprendre qu'il soit bien meilleur, difficile de faire tout seul ce que font plusieurs, et sont meme payés pour ça... )
au passage, ccd autopilot gere le passage au meridien avec le temma , on peut y mettre un delai egalement avant qu'il ne se declenche.
merci a toi d'etre intervenu pour eclairer nos lanternes, cela fait plaisir de te voir sur le forum;-)
ps: je doit t'appeller également mardi pour un autre probleme,ne reste pas trop longtemps au téléphone avec pierre ;-))))
a+
michael vanhuysse

heu , les gars, on a sérieusement dérivé du sujet de notre ami... désolé mattéo.

[matteo 0]

Pas grave MICV, au contraire, on apprend beaucoup de chose.
Cette petite dicusion m'a permis de mieux cerner le Temma que je ne connaissais pas trop et aussi toutes les possibilités qu'offrent les différents systèmes .
Merci encore et que le débat continu .

[DOLGER 0]

salut à tous ,

je viens de lire ce post super intéréssant avec des interlocuteurs qui ne le sont pas moins.
possédant du matériel décrit ci dessus ,je me tiens à l'affût de toute évolution qui peut être profitable à chacun de nous.
encore un coup de chapeau à Rémi, que je salue ici au passage,pour son dévouement ,compétence etc..

bien cordialement

dolger

[Rémi Petitdemange 120]

Hello de lu

En vrac, excusez-moi si c'est décousu ou redondant :

Michael :
Content de lire que tout ne va pas si mal et les souhaits se précisent encore un peu plus...
C'est clair la mise hors tension distante reste à faire côté firmware, solution plus élégante !
Je ne sais pas ce que donnerait le fait de laisser sous tension la monture plusieurs jours (en standby donc) ...
J'essaierai pour voir les conséquences éventuelles. On la laisse bien toute la nuit en tracking sans soucis...
On pourrait en alternative disjoncter globalement le matériel (monture et CCD) en fin de session avec un relais X10.
(Laurent Bernasconi en sait long sur la question dans son obs !)

Non officiel = en attendant le driver officiel ouvert et documenté...qui n'est jamais venu bien sûr
A l'époque de 1ers imports Temma (2001/2002) seule l'appli Pegasus permettait le pilotage d'où le terme employé par la première personne qui a développé un driver pour TheSky. J'étais apparament le 2eme à me lancer la dedans et euh ben j'ai repris l'idée ... ) !
Maintenant avec Ascom et Indi ça ne signifie plus grand chose vu que les drivers sont récrits pour intégration dans des interfaces dont l'un des objectif est la standardisation des commandes coté soft client.

SSK sur montures Taka : oui c'était proposé au Japon pour les japonais surtout..., le pb c'est la pérénnité du système malgré ses qualités évidentes. On ne compte plus les systèmes ou combinaisons intéressantes qui ne survivent pas au marché pour X raisons hors raisons techniques.
A l'heure actuelle je ne sais pas quels seraient les moteurs compatibles (faut voir les docs).

"interfaçage avec les autres devices utilisés (CCD, focuser...)..." :
Une vraie longueur d'avance des US, aucun doute là-dessus, en plus tout ça semble se piloter en réseau !
Ce n'est pas le rôle d'un driver de monture de piloter tout ça on est d'accord .
Je penserais plutôt à AudeLA ou Prism par exemples.
Tant que les protocoles ou les drivers sont ouverts c'est mieux pour tout le monde, c'est un autre débat !
Sinon "ccd autopilot" propose effectivement une bonne gestion de montures allemandes !
(je me demande si c'est en "surcouche" au driver Ascom par pilotage direct).

Pierre :
Pegasus : faudrait laisser coché les 5° au-dessous de l'horizon pour voir la prochaine fois un peu plus tôt peut-être.
CdC : faudrait noter les paramètres du setup et noter ce qui coince précisément pour déceler d'où viennent les soucis (driver Ascom ou de CdC), on en reparlera.

Vincent :
Réponse dans le désordre, désolé je ne sais pas encore récupérer les points évoqués plus haut en citation dans le post.
(par simple copié collé ? ou par rtfm ).

Le protocole est là : www.optique-unterlinden.com/temma2/driver_pl/protocole_temma.pdf
C'est une traduction du japonais et US que j'ai complété et annoté au fur et à mesure de mes avancées dans le dev et les tests.
J'ai aussi des diagrammes récaps des commandes Ascii de la raquette via RS-232.
Faut juste que je finisse de les mettre au propre si besoin.
Il y a aussi un "txt" de ce "pdf" dans l'archive de mes scripts.

Pour les sources Temma Ascom il faudrait contacter Chuck directement, à ma connaissance c'est le seul driver Ascom.
Est-il Opensource ou autre ? faut voir avec lui, il est joignable sur la liste US de Taka.
Il m'a contacté il y a quelque temps pour les fonctions de standby remote justement et je lui ai passé toutes les infos.
(c'était encore en japonais cette partie là).
Un coup de main d'amateurs avisés serait sans doute utile sur ce chantier (dev et tests).

Le PEC est très demandé effectivement et Takahashi finira par l'implémenter dans une version future.
C'est vrai que les chiffres annoncés sont très séduisants sur toutes les montures évoquées.
N'étant pas coutumier du PEC je me pose cette question :
Qu'est-ce qu'on attend du PEC à ce jour quand on autoguide systématiquement ?
- faire des poses courtes avec de courtes focales sans guidage (un faux mode F puisqu'il faut mettre en stat) ?
- venir à la rescousse de l'autoguidage : mais dans quelle mesure est-ce utile ? y a t'il des tests comparatifs là-dessus ?
- et si en plus de l'autoguidage on a un AOL, le PEC sert-il encore à quelquechose ?
Y a t'il des avis éclairés là dessus ?
Perso j'entends surtout parler de PEC non utilisés, on l'a mais on s'en sert pas parceque c'est pas si évident ni très efficace...
Maintenant tout évolue vite aussi !

Switch hardware de vitesse NS/HS sur raquette uniquement :
c'est clairement une grosse lacune d'autant que :
- les vitesses NS (normal speed) sont paramétrables via le protocole avec réglage effectifs sur le port autoguidage (incréments 0.01 et non 0.1 comme sur la raquette hardware).
- la commutation NS/HS (high speed) existe bel est bien via le protocole mais n'est pas effective sur le port autoguidage
Elle n'est effective que les commandes de raquette soft via le protocole.
On est nombreux à pester là-dessus et j'ose croire à une solution à l'avenir.
Ce détail montre bien que Takahashi ne pensait pas à fond remote à la conception.
Mais y a une solution néanmoinssssssss !
1) On met sous tension la monture sans raquette.
Dans ce cas la monture oublie carrément la vitesse HS et passe en NS par defaut RA:90%, DEC:90%.
2) On ajuste via un soft la vitesse NS en RA et DEC (exemple RA:50%, DEC:50%).
Et voilà ! Po belle la vie ?
Faut pas débrancher/rebrancher la raquette à chaud, c'est tout !
Ce sont des tests récents que je n'ai pas eu le temps de valider sur le ciel.
(détail vu depuis que j'utilise le port autoguidage au lieu du port RS-232 pour l'autoguidage )
Perso je sens que je ne me servirai de la raquette hard que pour les mises à niveaux préparatoires (viseur polaire et zénith).

Les autres fonctions manquantes sont bien sur:
- Le Parking
C'est un goto vers un point fixe mémorisé, par exemples :
- au zénith : RA=TSL DEC=LATITUDE.
- ou 10° au-dessus de l'horizon Sud : RA=TSL DEC=LATITUDE°-80°.
(valeurs hms et dms compatibles avec le soft utilisé évidemment).
etc ...
Ensuite on fait un "tracking off" càd une mise en standby en remote du protocole.
TheSky devrait le faire bientôt, les infos ont été passées également sur la liste US depuis un bon moment en tout cas !

- Le réglage du passage au méridien
Bien qu'encore un fois côté soft ce soit simple à faire ce sera mieux effectivement dans le firmware.

Le Tracking Off : lié au parking
C'est dans le protocole du Temma2 mais peu exploité malheureusement.
Ca devrait changer rapidement les infos sont dans les mains des personnes concernés.

Ah les alertes musicales pour le passage du méridien ou quand on est au taquet tube coté Ouest...
De mon côté l'aspect multiplateforme de mes scripts rend la chose un peu plus compliquée en dehors du bip mais pourquoi pas
Une mise en standby automatique (Tracking Off) quand on frôle le pied est le prochain ajout dans mon script Temma.

D'accord avec pour lister les fonctions des systèmes les plus courants, et faire le tri des besoins.
Je suis ouvert à toute discussion pour faire remonter les demandes chez Taka.

Mon appli-driver en Perl/tk permet de tester facilement ce qu'il est possible de faire avec le protocole.
Tous ce que la monture mémorise est visible à chaque instant (pour déboguer c'est utile).
Sinon on a :
- L'élargissement du verrou méridien pour pointages directs.
- Le parquage.
- Une raquette assez sympa
- Le tracking cométaire et lunaire...
quitte à le lancer juste pour faire un truc précis et à jeter le tout si pas utile.
Le plus compliqué pour moi c'est l'install simplifié à la Windows. Faudra faire plus simple si des gens sont intéressés.
(détails d'install dans le fichier lisezmoi.txt section Windows).
Si Windows pouvait être aussi simple que le pingouin sur ce point ça serait un jeu d'enfant (simple copie des fichiers dans un rep) mais il reste 2 points délicats, l'install des 2 modules (Win32-API et serialport) en ligne de commande (c'est pas la mer à boire non plus).
Pour info l'environnement Perl/Tk pèse environ 60 Mo sur un disque dur NTFS et le reste pour le Temma pèse quelques centaines de Ko.

Et merci à Matteo pour ce post !

Cordialement,
Rémi