Dans le domaine du bricolage astro...
Vous savez que je travaille sur des projets de "longue durée"...
Ici, c'est le projet "ASO" ou "All Sky Observer", un observatoire miniature
totalement automatisé.
Hier soir et ce matin, j'ai apporté la phase finale à la première partie.
Objectif suivi : le contrôle d'une CCD à distance.Entendons-nous, pour contrôler une CCD, il y a 4 méthodes utilisées
- une connexion USB (limitée à quelques mètres) ou RJ45 (rare, que 2 marques) directes entre CCD et PC
- une connexion USB avec un "extendeur" (pour éloigner la CCD du PC), limité à quelques dizaine de mètres
- une connexion USB/IP avec convertisseur (USB/RJ - RJ/USB, cable dédié)
- une virtualisation de connexion USB dans un LAN
Comme vous vous en doutez, c'est la dernière solution qui m'a intéressé...
Le but est simple : quelque soit le PC que l'on désire utiliser, et sa place dans le réseau local,
(machine principale, notebook, tablette) il peut "récupérer" l'usage une CCD qui a été "virtualisée".
Ex pratique : on désire traiter des images avec le PC du salon... Mais il faut mettre au point, et
cela exige soit des dispositifs coûteux (focus à distance, etc...) soit que l'on déplace une fois, avec
un portable, à côté du télescope.
Une fois la mise au point faite, on "libère" la CCD et on revient au PC principal et on commence à acquérir
comme de rien n'était... Joli, non ?
Bon, c'est pas tout de rêver, comment on fait ?1) analyse du besoin : une à 2 CCD à virtualiser... Cela consomme combien ?
- USB 1.1 = 12 Mbit/s
- Firefire 400 = 400 Mbit/s
- USB 2.0 = 480 Mbit/s
- FireWire 800 = 800 Mbit/s
- USB 3.0 = 5 Gbit/s
Or, je dispose d'une ATIK 16IC (USB 1.1) et d'une DMK (USB 2.0) ou d'une WebCam (Compatible StarShoot)
que j'aimerai utiliser...
Mais d'un autre côté,
ATIK : 659 x 494 x 16 bits = 5.208.736 bits/sec, mettons 6Mbits/sec
DMK :30 img/sec à 1024x768 et 8bits de résolution = 188.743.680 bits/sec, donc 200 Mbits/sec
Webcam : idem DMK au max...
Mais à un moment donné, on ne mettra que 2 caméras actives
(une pour le visible, une pour le solaire ou la spectro).
Résultat, on exploite à 50% les normes.
Et avec 500 Mbits/sec, on couvre les deux besoins.

Donc, un simple cable UTP6 couvre largement le besoin.

Maintenant, pour des raisons personnelles, je préfère passer actuellement par CPL ou WiFI.
Le cable est une meilleure solution, mais cela entraînerait d'autres travaux dans mon cas...
Donc, il faudrait un vrai CPL de 500 Mbits ou un WIFI de 2x 300Mbits.
=> je choisi le CPL pour commencer, et pour garantir la vitesse, il sera dédié aux CCD's.

2) Commander la monture : un protocole de contrôle est très simple, la dépense
en réseau est négligeable. Mais par contre, il y a une communication permanente.
=> donc, on va également passer le contrôle via réseau et les quelques kbits/sec ne
fera pas grand chose...
Mettre cela en musique... J'ai testé une dizaine de solutions...
Avec des solutions "toutes faites" et d'autres "bricolées".
En finale, j'ai opté pour un mélange entre les deux :
- la virtualisation des USB est une solution "pro" (industrielle), compatible ASCOM
- la virtualisation des accessoires est une solution "brico" (Rasbperry Pi), compatible INDI
- la commande du télescope sera en IP "pure", compatible ASCOM, avec le protocole Vixen.
Donc, me voici avec une "boite" sur laquelle se trouve branchée tous les éléments actuels de ma monture,
qui finit avec une prise électrique...
4) Test (hier soir) : tout est "on-line"...

Tout devrait fonctionner, en théorie...
Et...
Commande de monture : ok, nickel...
Un pointage polaire et après alignement de 4 étoiles, je prends le contrôle en
"mobile" : ok, tout fonctionne. "The Sky" et son catalogue sont disponible.
Ok, passons aux CCD. Pour simplifier, je mets la WebCam.
Et là, à chaque tentative de connexion : abend !!!

Alors que sur le banc de test avec l'ATIK et la DMK, tout fonctionnait !
Grrr...
OK, on va tout reprendre à zéro...

a) problème network ? on change le CPL par un vrai câble : idem...
b) problème switch ? je connecte les CCD en direct : idem...
c) problème soft ? je teste en local la WebCam : cela fonctionne...
d) problème énergie ? je vérifie les voltages, tout est ok...
M'enfin ?
Mais... Ok, on va retester avec l'ATIK.
- démontage, remplacement, lancement virtualisation
- connect : ok
- acquisition : ok !
- remet le switch : ok !
- remet le CPL : ok !
Donc... C'est la qualité du "Driver" de la Webcam qui pose problème...
Evidemment, un driver de webcam n'est pas, normalement, au même niveau
de finition que l'on s'attendrait, et donc : il "bugge" car on a utilisé une
astuce quelconque de programmation pour accéder l'USB.
En théorie, on attaque un USB via un "bloc" virtuel.
Ex : https://msdn.microsoft.com/en-us/library/windows/hardware/dn376872(v=vs.85).aspx
On dispose de plusieurs modes (KMDF, UMDF et WinUSB)
https://msdn.microsoft.com/en-us/library/windows/hardware/hh770892(v=vs.85).aspxEt les trois modes sont toujours disponibles sous Win10 (on prévoit...)
Il faudra que je regarde en détails les drivers pour comprendre "qui est compatible ou pas".
Mais par contre, a ce stade, cela fonctionne... Je peux "acquérir" la CCD (ATIK) en mobile,
faire toutes les mises au point près du télescope et rentrer. Ensuite, je la "récupère" sur mon
poste fixe et je continue l'acquisition et le pilotage de la monture...
Mais je vais améliorer deux-trois trucs pour rendre cela plus fluide (priorité et performance IP, par exemple).
Je précise que la solution utilisée et une solution "micro-boitier" (donc pas de PC avec écran, ni OS
standard) organisée autour d'un processeur à 800Mhz, le tout alimenté sous 5V/1A. Le logiciel
dédié "boote" en 2 sec et ne fait "que" cela...
Si cela intéresse quelqu'un, je vous propose de faire une conférence sur le sujet...
En fait, j'en ai déjà deux : "les outils Open Source" et "la virtualisation de CCD".
A vous de voir et de m'indiquer si cela vous intéresse...
