vbo

Bonsoir, Tous les tubes Newton Sky-Watcher ont cette particularité. Il faut impérativement mettre l'allonge pour avoir la mise au point avec un oculaire, du fait de la position assez reculée du foyer sur ces télescopes. L'avantage de cette grand sortie de foyer est de pouvoir faire des montages variés, sans être trop limité par le tirage. Sur les FlexTube, il est même possible de reculer encore plus le foyer en ne tirant pas les tubes du FlexTube jusqu'en butée (il y a deux positions). Rien ne vous empêche de changer le type de PO 31.75mm. Par contre, ce sera plus compliqué de changer le PO 50.8mm original parce qu'il est vissé sur le tube coulissant du focuser. La longueur de déplacement du tube coulissant du focuser est certes importante mais elle ne permet pas de faire la mise au point dans tous les cas. L'allonge résoud ce problème. Le serrage annulaire a l'avantage de serrer sans marquer les jupes des oculaires mais il a le défaut de tomber parfois en dehors des rainures de sécurité des jupes et donc de provoquer des assemblages au serrage incertain... Vincent OU

Bonjour Gilles, Pour rebondir sur notre discussion sur le forum d'en face, voici une idée plus concrète de ce que pourrait être une architecture de services/microservices dans le cadre de la gestion d'un observatoire. Chaque service est intégré dans son propre container Docker. La liste n'est pas exhaustive puisque n'importe quelle fonctionalité peut être, au final, transformée en service indépendant. - Un service de communication avec le matériel. Typiquement, un serveur Indi offrant une interface de type Alpaca (API Rest). A moins qu'Indi ou Indigo ne proposent déjà ce type de solution. - Un service de reconnaissance astrométrique. Genre ASTAP ou Astrometry.Net ; certains possèdent déjà des offres containerisées. - Un service de mise au point automatique. - Un service d'autoguidage. - Un service de gestion des catalogues d'objets célestes - Un service de scheduler pour l'automatisation - Un service de mise à disposition des données météo/all-sky sur le web - Un service de monitoring / watchdog ... Il est possible de créer, pour chacun de ces services, un ou plusieurs autres services chargés de l'interface utilisateur : une carte du ciel pour gérer le service des catalogues d'objet, des widgets pour les données météo/all-sky, une interface d'administration (type Indi Web Manager) pour le service de communication avec le matériel, une interface graphique pour le séquenceur... Une interface UI peut piloter le tout, qui peut être scindé en services pour l'interface mobile, pour l'interface desktop, pour une web API, etc. En fait, il suffit de reprendre toutes les fonctionalités de Nina, CdC , Prism et cie. Quasiment toutes peuvent être des microservices potentiels. Le gros avantage des services containerisés est qu'ils peuvent être développés indépendamment, dans la technologie la mieux adaptée (du C/C++/Rust pour du calcul intensif, du NodeJS pour du backend web, du React pour le front-end, etc.), avec leur propre cycle de dev. Ils peuvent aussi être repris depuis des projets open-source et containerisés. Autre avantage, ils peuvent être décentralisés. Rien n'oblige à ce que tous les containers soient sur la même machine. On peut imaginer que seuls les containers nécessaires au pilotage de l'instrument soient sur un Raspi sur le télescope, les containers gérant l'abri/la coupole/la satation météo, la all-sky sur un autre Raspi, les containers de calculs dans un PC plus puissant dans l'abri, les containers des interfaces graphiques sur un NUC dans la maison, etc. C'est une architecture très souple mais un peu complexe. Vincent