Unistellar Evscope Equinox : Découverte et usage

Mise à jour : Mai 2022

Pas mal des membres de clubs que je fréquente savent que j’ai désormais un exemplaire d’un des télescopes EAA (Electronically Assisted Astronomy) du marché. Ayant un projet qui intégrera l’utilisation de ce genre de technologie, j’ai décidé de m’y attaquer. Mais c’est aussi le bon moment d’en faire une petite analyse afin de balayer ou confirmer les affirmations soutenues (dont les plus fantasques) sur “FB et autres”… (Rem Je ne suis guère sur les “réseaux sociaux” et cela me convient très bien…)

Ce type d’engin déclenche visiblement les passions et clivages, mais surtout montre encore le phénomène d’acceptation de toutes les affirmations sans réflexion… On est soit “totalement pour” ou “totalement contre”. Récemment, on m’a même dit “Si tu es contre ce que l’on dit sur X (=Fesse de Bouc, TikBrol, etc…), j’exige des preuves…“… Hilarant ! Car d’un côté, quelqu’un peut annoncer n’importe quoi sur ces sites et cela devient la “vérité car c’est des gens (évidemment) sérieux qui l’on publié”… Par contre, si on (ose) critiquer soi-même, là, ceux à qui cela déplait “exigent” des preuves !!! Bref : du plus haut comique…

Contra factum non datur argumentum” (“Contre un fait il n’est point d’arguties“) et je stocke ici quelques résultats objectifs d’analyses sur ce matériel. Le pour, le contre, cela ne m’intéresse pas… Puisque de toute manière, j’en possède déjà un exemplaire de ce type de télescope et que son concurrent direct arrivera (peut être) prochainement (si la société survit…). Je préfère donc en revenir à “que peut-on faire avec ?”…

Petit panorama technique

Il y a pléthore de sites qui le décrivent… Mais de nombreux sites annoncent un petit “D=114/F=450mm”, avec un capteur IMX224 (1280×960).

Unistellar précise cependant bien (documentation officielle) que
a) son miroir est un 112/450mm (BK7), soit :
Un rapport F/D = 4.02
Résolution optique = 1,07 arcsec
Magnitude visuelle = 12,35
Magnitude astrophoto limite = 17,35

b) le capteur est un IMX224LQR, avec 1305×977 photosites (max 120 fps, soit 5ms)

  • Part Number : IMX224LQR
  • Manufacturer : Sony Semiconductor Solutions Corporation
  • Description : Diagonal 6.09 mm (Type 1/3) Approx. 1.27M-Effective Pixel, Color CMOS Image Sensor
  • Resolution1305 (H) x 977 (V)
  • Mega Pixels 1.27 MP
  • Supply Voltage 1.2 to 3.3 V
  • Optical Format 1/3 Inch
  • Package Type LGA
  • Chroma RGB
  • Frame Rate 30 to 120 fps
  • ADC Resolution 10 to 12 bit
  • Pixel Size 3.75 x 3.75 µm
  • Pixel 1.27 MP
  • Active Array 1305(H)x977(V)
  • HD Format 720p HD
  • Sensitivity 2350 mV
  • Clock Frequency 27 to 74.25 MHz

Le capteur délivre bien 1035×976 pixels (en raw) et pas 1280×960 en natif. Cette faible différence n’impacte guère ni le champ, ni l’échantillonnage qui sont : Champ = 0,61 x 0,47 deg et Echantillonnage = 1,72 arcsec/pix

Le “LRQ” est une version dédiée à l’industrie du capteur original, mais surtout 2x plus sensible. Il se distingue par une plus grande capacité en basse lumière, facilement visible :

Différence de sensibilité LRQ versus standard

Je m’interroge si tous ceux qui ont testé la comparaison entre une configuration IMX 224 et eVscope (V1 et Equinox) ont intégré cet élément dans leur durées de poses ?

Le logiciel “maître” de ce télescope fonctionne en collaboration avec une “APP” pour tablette/smartphone sous IOS et Android. Le boitier ne permet aucune autre connexion directe (du moins officiellement).

Les fonctionnalités de l’APP sont largement décrites ailleurs. En ce qui concerne la version testée, je suis juste passé à la 1.6 en mai 2022.

Il est a remarquer qu’en mode “vision augmentée”, le gain est généralement poussé à son maximum, exploitant de-facto le capteur à son maximum, mais aussi avec un bruit conséquent. La prise de Dark (un bouton) est largement conseillée au milieu de soirée et fin de soirée !

Le Dark utilisé est en fait un “master dark” issu de 20 captures à durée maximale (4sec). On ne peut pas influencer le processus.

Pas de flat, ni de procédure pour les prendre. Il faudra s’y intéresser.

Points positifs du télescope

Le télescope est monobloc, la batterie est intégrée, pas de fil qui traîne et la mise en route est simplissime : un seul bouton on/off gère le tout. Le reste sera géré après connexion du smartphone/tablette sur le WIFI du télescope.

La “mise en station” (qui n’en ‘est pas réellement une, il faut dire) est tout aussi simplissime et efficace, même dans des conditions de pollution lumineuse difficile. Il suffit de pointer quelques étoiles suffisamment brillantes (aka : visibles dans l’écran de l’APP) et de laisser faire. Même pas une minute après, il annonce qu’il est prêt pour la première observation ! Bluffant pour toute comparaison avec une MES standard…

Ensuite, il faut bien admettre que le “Go To” réel vers un objet n’est pas immédiat… A la différence d’une monture standard dont la précision dépendra essentiellement de la MES et de la qualité de ses engrenages, le pointage va ici s’effectuer en plusieurs étapes (une rapide approximative, puis plusieurs avec astrométrie intermédiaire). Mais là aussi : il fait très bien son boulot ! Sur plusieurs centaines d’observations maintenant, seulement 2-3 pointages objets ont du être recommencés, faute d’une visibilité suffisante. Et là encore : il suffit de pousser sur le bouton….

Sélectionner un objet, demander le pointage, demander la vue “améliorée” et commencer à observer un objet (du ciel profond) est d’une facilité déconcertante et on comprend l’intérêt de ce genre de solution pour le grand public. La plupart des “problèmes” liés à l’observation pour un débutant sont directement levés et la présentation vers un groupe (ou une famille) se fait quasiment en direct.

Le menu “catalogue des objets” permet une navigation relativement facile dans une liste des objets visibles dans “son” angle de vue (fonction “angle de vision”, géré par un onglet dédié, qui est une vraie aide pour les gens qui observent dans un environnement urbain difficile).

Mais remarquons que la liste affichée à un moment donné est assez limitée… Alors que plusieurs objets (NGC et autres) accessibles sont visibles dans la portion du ciel disponible (et on peut parfaitement manuellement le trouver dans la liste), la fonction ne les présente pas au débutant et se contente généralement des Messiers et “remarquables” (indiqués par leur nom commun).

Le mode “introduction” manuelle de coordonnées permet de compléter les observations intéressantes. A mon sens, il manque une fonction de “sauvetage” de ses objets favoris. Une fois les coordonnées sélectionnées/entrées, le pointage s’avère efficace et fait son boulot. Même mieux “manuellement” que “automatiquement” (on y reviendra dans le protocole proposé).

Quand au mode “science participative”, il aura un chapitre dédié.

Sur tous ces points, le cahier des charges est parfaitement répondu.

Points négatifs du télescope

Le résultat final (vu le prix), que vous obtenez sous un ciel de bonne qualité, est optiquement très moyen. Même avec une collimation et mise au point soignée (quasi refaite à chaque fois), on sera facilement distancé en qualité par d’autres matériels équivalents (ex : ASI AIR + monture AZ GTI et un tube identique). La raison se trouve dans le logiciel et dans le but d’utilisation de la monture.

Ce télescope permet de découvrir le ciel profond et ses objets avec une facilité déconcertante… Mais au prix d’une optimisation d’image “forcée” qui va quasi systématiquement “forcer” la saturation des étoiles pour que le rendu sur un (petit) écran soit optimal dans une période de temps courte (quelques minutes suffissent pour quasi tous les objets).

Tout ceci s’effectue en mode “full automatique”… Et sans aucune capacité d’agir sur les paramètres de capture. Dès que le mode “vision augmentée” est enclenché, impossible d’agir sur la capture (par exemple : réduire/augmenter le temps de pose ou le gain…). Ce mode est très rapidement frustrant pour un astrophotographe (quelque soit son niveau).

Je conseille donc, avant de dépenser 4700 eur pour ce type de solution (trop cher, selon moi, pour le dernier modèle), de bien réfléchir à son usage cible… La récente augmentation de prix du V2 (visiblement plus adaptée pour pour “vendre” leur sac de transport qui ne se vendait guère autrement…), incite à la réflexion sur son usage par des astro-amateurs plus aguerris.

Ensuite, évidemment libre à chacun de prendre une décision (comme moi-même), mais en étant bien informé : son but, ses besoins, ses envies et ce que l’on peut attendre = la satisfaction d’avoir acheté une solution qui vous convient.

Par exemple : la saturation (quasi) systématique des étoiles, quelque soit la durée de “pose”.

Un exemple de vue 3D d’une étoile, vision augmentée de 5 min su M57
M57 est déjà bien visible, mais les étoiles sont plus des “tâches” que des “ronds”

Par exemple : le suivi parfois approximatif. Le mécanisme altazimutal de pointage se révèle par moment capricieux. Et si on n’y regarde pas AVANT d’appuyer sur le bouton “vue améliorée”, on obtiendra un pointage où la dérive est TRES importante (visible à l’oeil nu.. Comme sur l’image suivante, une image prise aussi vite qu’on accepte le bouton de capture manuelle…).

Exemple de dérive après Goto (sans appliquer de correction, voir dessous)

Dans ces conditions, l’empilage / dérotation logiciel sera toujours “pâteux” et les étoiles seront tout ce qu’on veut, sauf rondes… (le logiciel ne peut pas faire des miracles !). Mais la solution à ce problème est relativement simple (mais pas expliquée dans le manuel), j’adresserai ce point spécifique dans le chapitre “protocole”.

Les fonctions de l’APP pourraient donc être améliorées, principalement avec des mécanismes pouvant “étendre” manuellement le catalogue des objets observables et une liste d’observations programmable.

Qualité des images

Le télescope, via l’APP, fournit des images PNG au format 8bits (donc de qualité limitée) sur les smartphones/tablettes connectés.

La taille et le mode des images sont évidemment également “bridés” par les contraintes techniques de la solution. On a une visualisation en temps réel, via WIFI, sur chaque smartphone connecté. Augmenter la taille/qualité de l’image issue d’un petit capteur serait certainement trop pénalisant pour la solution. Donc, le format et qualité est un “équilibre” visant à optimiser l’usage.

Par contre, le format “RAW” des images (fits/tiff) est accessible (via un upload obligatoire vers le site du constructeur), une demande et un “download” vers son PC. On y reviendra.

Cependant, des objets fort caractéristiques du ciel sont bien rendus par la solution, quelques exemples (avec durée, dans le mode “cropped” – Voir description plus bas dans le texte).

NGC3628 – 21min
M97 – 14 min
NGC6946 – 21 min
M27 – 10 min
M11 – 6 min
M5 – 6 min

Remarque : toutes les images impliquant des objets fortement Ha ne seront pas fortement rendus, par contre… (Voir le chapitre “filtre” plus loin)

D’un point de vue “sécurité” de la solution

Ok, le but de type d’outil n’est pas d’offrir une plateforme informatique de pointe, mais il y a de tout de même des choses à dire…

1) Positif : Le WIFI démarré par le télescope offre une connexion non sécurisée suffisamment puissante que pour assurer une bonne connexion à 10m.

Négatif : La sécurité de la connexion s’établit donc ainsi non pas via un accès protégé (WIFI avec mot de passe), mais au niveau du protocole d’échange entre APP et télescope. L’examen approfondi de la conversion montre des échanges dans ce sens. Le premier connecté (via l’APP) héritera des droits “opérateur” (gestion complète du télescope), tandis que les suivants hériteront des droits “observateur” (affichage uniquement). C’est un protocole simpliste, mais théoriquement efficace.
Théoriquement seulement… Car ce droit opérateur peut être “réclamé” par un observateur, si… Il connait le n° de série du télescope (étiquette placée sous le bloc moteur).

Donc, à ce stade… On pourrait conseiller de…
– Primo : ne faut pas s’éloigner trop du télescope, car sinon on perdra la contrôle et il peut donc se trouver transféré à une personne du public !
Et si on doit s’absenter, mieux vaut le couper.

– Secondo : le n° de série du télescope apparait en fait comme une “clé” d’accès à beaucoup de ressources… En soit, ok, pourquoi pas ? On sait où le trouver et si on protège l’accès physique au télescope, cela peut être une solution facile pour des gens peu doué en informatique… Mais : Inutile ! Car le Wifi qui est démarré comporte le même n° de série ! 🙁
Et, cerise sur le gâteau, il est impossible de le changer ! (on peut rajouter des caractères, mais pas supprimer des caractères… ).

– Tertio : le WIFI étant “ouvert”, on pourra assez facilement bloquer l’opération même du télescope…. Le mot de passe étant distribué, n’importe qui va pouvoir s’amuser à “réclamer” les droits “opérateur” (même si il vaut valider l’action, cela va perturber son usage)… On peut également perturber les opérations en multipliant connexions/déconnexions… Un joyeux b… en perspective…

– Quarto : une fois informé (après avoir lu ces lignes ?) Rien n’empêche un pirate débutant de se mêler à un groupe de spectateurs et de… Démarrer son “propre” point WIFI en copiant celui du télescope… Et lors de la connexion (qui sera toujours autorisée au niveau WIFI au minimum), d’installer un logiciel malveillant dans le smartphone de ceux qui s’y connectent ! Agenda, adresses mails, compte bancaire, comptes sociaux offert sur un plateau à un pirate ? Et cela pour une observation d’objets du ciel ? Pas terrible… D’ailleurs, si une “Cyber Police” retrouve la trace de la dernière connexion à partir de laquelle on a “hacké” le smartphone, on risque aussi de retourner vers le possesseur du eVscope !!! (dont le n° de série se trouvera dans la liste des WIFI connectés)

Conclusion au niveau sécurité :
Sauf une simple mise à jour qui règlera ce problème (à mon sens, c’en est un gros…) et déjà au vu que l’on ne peut pas “protéger” son propre usage…
Je déconseille logiquement l’usage de la fonction WIFI “observateurs partagés” en public à ce stade de version (1.5).
Et c’est le comble ! Car c’est supprimer 50% de l’intérêt de la solution !
Mais si on le fait, c’est bien à ses risques et périls…
(et certainement pas sur les conseils de celui qui écrit ces lignes…).
Mais on peut tenter de “parer” quelque peut via une solution “home made” qui va “dérouter” le WIFI “ouvert”.

Pour ce qui est de l’usage privé (dans son jardin) ou de l’affichage à l’écran, il n’y a largement moyen de limiter le risque (répéteur, ne pas s’éloigner, couper en cas d’absence, émulateur sur PC, etc).

Perso, je travaille avec un émulateur Android (freeware) et une machine virtuelle dédiée… si on y accède, il n’y a pas grand chose à y voler… A part les images du eVscope ! 🙂

Sans internet, pas d’espoir…
Bien que le logiciel est clairement orienté pour fonctionner sur Smartphone, il faut cependant disposer d’une connexion WIFI Internet “propre” pour le fonctionnement normal du télescope.
Il dispose d’une bonne mémoire “propre” (64 GB) mais on sait bien à quelle vitesse cela peut se remplir avec les images astronomiques (surtout en poses courtes, ce qui est le cas ici). Or, pas de solution pour “vider” la mémoire utilisée hormis une procédure “exportation des images” (vers le site d’ Interstellar)… Procédure qui fonctionne, certes, mais prend du temps !

Ok… Peu efficace, mais la procédure fonctionne et les gens du support réagissent correctement et rapîdement pour toutes les demandes (voir traitement des RAW)…

Cependant, deux remarques pratiques :
a) la procédure ne fonctionne que avec une liaison WIFI classique (SSID, password). Et si on est par exemple à l’hôtel (ou à l’étranger) (WIFI avec login WEB) : pas possible de l’utiliser !
Selon le site support : “même avec une mémoire pleine (100% de stockage de données utilisé), l’eVscope continuera à fonctionner normalement, et vous pourrez toujours enregistrer vos images. Cependant, vous ne pourrez pas participer aux événements communautaires ou aux campagnes de science citoyenne“. Si “enregistrer vos images” veut dire “sauver les images via l’APP”, c’est en effet possible. Mais si on est en voyage (sous un ciel plus bleu), mieux vaut pouvoir sauver !

b) si vous démarrez un “point WIFI” depuis votre Smartphone en solution backup (faute de mettre à zéro votre forfait 4G), il vous faut deux APP au même moment !
A savoir :
– une tablette pour vous connecter sur le WIFI du télescope
– un smartphone en 4G pour le partage du WIFI en upload.
Et j’espère que vous avez à la fois du débit constant (la procédure d’upload est apparemment faible côté stabilité, j’ai du recommencer deux fois sur un routeur 4G) et un forfait adapté !

c) Une remarque pratique… Une fois introduit le nom et mot de passe du WIFI de la maison introduit, le télescope “travaille” (longtemps) seul… Mais… Que deviennent ces informations après usage ? (stocké dans le télescope ? l’APP ? Envoyé à Unistellar à la même occasion ? )
Une question non résolue (et vérifiée) à ce stade. On y reviendra…

Conseil pour upload : Comme le télescope est donc incapable de supporter une sécurité plus évoluée (genre WPS), je conseille donc de créer un utilisateur et mot de passe dédié (guest) à son usage, si votre routeur le permet. Comme cela, on ne “partage pas” la sécurité de sa maison avec un point (totalement) non sécurisé…

Un petit mot sur le format des images

Le télescope est vendu avec une “offre” de science participative. Ce qui peut inciter à croire que son possesseur pourra aussi utiliser les images capturées dans ce mode. Avec ce type de solution uniquement “numérique”, autant examiner de près ce qui sera la seule sortie que l’utilisateur “amateur” pourra utiliser depuis le télescope même

Les créateurs de la solution exploitent clairement le fait que l’affichage
des images se fera sur “petit écran” (donc : avec des détails peu visibles).

A ce stade, deux formats de “sortie”

  • une présentation circulaire (crop central de l’image avec fading), avec information de capture (utiles à garder)
  • une image rectangulaire (format capteur), mais… AUCUNE information stockée (Exif ou autre), ni accessible ! Ce qui est un manque criant (et incompréhensible), au niveau “astro” !

D’un côté pratique, l’utilisation sur Android l’emporte, surtout pour l’exportation des images capturées.

  • Sous IOS, les captures doivent être gérées manuellement “image par image” et lors de l’exportation (vers un drive cloud, par exemple), on perd totalement toute information…
  • Sous Android, toutes les images sont stockées dans une sub-dir (Pictures/Unistellar) et elles seront facilement copiées vers un PC. Dans le nom du fichier, on trouve en outre la date et le temps (UTC), c’est déjà cela (faute d’autre chose)…

Dans l’usage “scientifique” (lié au SETI), je suppose que toutes les informations indispensables seront envoyées. Mais à ce stade, de nouveau, visiblement pas moyen d’y accéder directement..

J’ai “envoyé” deux observations en mode “science (occultations), mais pas possible de connaître clairement son usage… (si même valable ou pas ?)

Pour le mode “enhanced vision” standard, j’ai donc très rapidement demandé l’accès à mes données directement sur le site Unistellar.
Après une procédure qui fonctionne (même si on indique le critère “en développement” de la solution) j’ai effectivement récupéré un volume impressionnant de données (fichier compressé de plusieurs GB, format fits) qui seront analysées dans un chapitre dédié (voir dessous).

Bon point : on récupère (enfin) ses données, mais au bout d’une procédure qu’un simple accès USB sur le télescope aurait largement simplifié…

Dans les autres modes, cet aspect “aucune métadonnée” présente dans les images (ce que le moindre freeware de capture astronomique fait pourtant sans problème) montre clairement que l’intention des créateurs n’est pas de faciliter l’utilisation en dehors de leur écosystème

=> Pourquoi ne pas inclure les informations de l’objet dans l’image ?
=> Pourquoi ne pas permettre l’exportation directe depuis le Télescope ? On peut imaginer plusieurs raisons (principalement commerciales), mais c’est clairement une limitation actuelle pour l’amateur.

Pour “solutionner” ce problème, j’ai développé une solution (Python, of course) qui peut aider… Voir la page “utilitaires“.

Question format d’image…

A l’utilisation, on découvre que les tailles et modes des images varient selon le type d’utilisation. Le paramètre de configuration (menu utilisateur) “avec cadre” influence beaucoup de choses.

On part visiblement de 1305×977 et 10/12bits en natif (IMX224LRQ) et on obtient les types suivants (j’ai donné des noms, vu que rien n’est décrit) :

  • Basic” :
    • Paramètre “cadre” : off
    • Sauvé via bouton “save” sans avoir fonction améliorée active, semble le format capteur natif
    • 1280×960, 24bits/pix RGB (.png, compressé zip)
  • Full” :
    • Paramètre “cadre” : off
    • Sauvé après “vision améliorée”
    • 2560×1920 24 bits/pix RGB (.png, compressé zip, 200% capteur)
  • Crop Basic” :
    • Paramètre “cadre” : on
    • Sauvé via bouton “save” sans fonction améliorée active
    • 1120×1120, 32 bits/pix RGBA (.png, compressé zip, )
  • Crop Enhanced” :
    • Paramètre “cadre” : on
    • Sauvé après “vision améliorée”
    • 2240×2240, 32 bits/pix RGBA (.png, compressé zip, 200% mask basic)

Deux remarques :

  1. Il apparait clairement que l’on utilise un “upscaling” (final ou à chaque image ?) pour augmenter la taille de l’image. Techniquement, je dirai un “Drizzle” adapté par Unistellar à son eVscope

    Pourquoi ? Un Samsung S20 atteint (mode normal) 2400×1080, un iPhone 13 dispose de 2 778 x 1 284 pixels à 458 ppp. Donc, je suppose qu’une image de 2560 ou 2240 “passera” visuellement mieux qu’une plus petite…

    Le smartphone est clairement la “cible”, surtout pour les “observateurs occasionnels” (qui se baladent rarement avec une tablette dans la poche lorsqu’il vient à une “star party”). Mais “projeté” (cf remarques sur la sécurité) sur un écran TV (32″), cela pixélise un brin…
  2. Ce “32 bits” n’apporte pas de détails en plus, la valeur RGB reste codée en 8 bits x 3 mais on rajoute 1 byte de canal alpha (un relicat du masque circulaire apposé sur l’image, je suppose). Il faudra le supprimer dans les outils de traitement pour éviter des problèmes (4 couches indiquées, mais que 3 présentes).

Rappelons qu’un capteur couleur n’a que 1/4 de la résolution d’un capteur N/B équivalent. Si on travaille sur les images “brutes”, le mode d’interpolation (+ upscaling) aura son importance.

Donc, à ce stade…
a) dès quelles sont issues de la “vision augmentée” (enhanced vision), les images sont donc visiblement soumises à un “Drizzle personnalisé”, qui double la taille de l’image et vise a augmenter (artificiellement) la résolution. Mais le défaut sera le bruit engendré par ce genre de technique.
=> d’où l’importance du dark

b) comme aucun des format d’images n’a ses données “exif” (ou autre métadonnées) remplies avec les informations de capture. Donc : si on n’utilise pas le mode “crop” (qui fait perdre une bonne partie de l’image), mieux vaut noter/annoter manuellement toutes ses captures ! => Nous voilà revenu à l’Astrophoto des années 2000, quand on annotait nos images issues d’un Canon300D… Le comble !

c) si on veut “post-traiter” les images soi-même, on part déjà sur du “faible” au niveau signal (8bits)… Et visiblement, rien n’est prévu pour le 16bits à ce stade, même avec le “sauvetage” manuel.

d) le mode “scientifique” permet des fonctions de séquençage et de capture continue, mais sans pouvoir obtenir les images stockées en “internes”, cela n’aide pas à ce stade (et après upload : non plus…).

e) comme le télescope est “fermé” (pas d’ajout de filtres et autres directement possible) les autres informations (flat, offset) ont été fixé à la construction… Par contre, je m’interroge comment (bien) nettoyer le capteur (le miroir, on explique) des immanquables poussières qui s’y déposeront à la longue ! Et sans “flat”… Pas d’autre solution.

Les images au “format brut”

Comme déjà indiqué, on peut demander à Unistellar de nous renvoyer nos images accumulées dans la mémoire du télescope.

J’ai testé la procédure, et le retour est ok… J’ai ouvert un ticket au support et après quelques échanges (identification, format d’image, date), on reçoit un “gros” zip à décharger… Cette procédure a été mise à jour en 2022… Elle indique désormais, je cite :

While our team is still working to automate the raw data process, today we are make it evolve a little bit to better suits the needs of our valued Unistellar stargazers !
We are no longer limiting the file size at 5GB which will give you more data at once. From now one, please contact us within the last 30 days of your observation (previously 90 days) and we will get you your data !
We hope the evolution of the raw data process suits your needs better. We remain open to hear your feedback.”

En ayant désormais déchargé plus de 41.000 images à cette date (05/2022)
Je peux désormais garantir plusieurs choses :
– Positif : La procédure fonctionne… Et même fort bien ! Le délai entre demande d’accès et mise à disposition du lien est désormais de quelques heures. Parfois, j’ai mes données 2h après ma demande !
– Positif : Elle a bien évolué, comme annoncé. Et le volume ne pose plus de problèmes (max 5 GB jadis) ! Mais il faut les demander dans les 90 jours. Ce qui, perso, ne me pose pas de problème.
– Info clé : Le n° de série du télescope est la donnée “clé” pour toute la procédure et dans les données fournies (présent partout : nom des fichiers, structures, fichier documentation, “exif” des images)
=> donc, si on veut “montrer” ou “distribuer” les images, il faut totalement éditer les images pour “supprimer” cette information…
Car sinon : cette info “clé” est utilisable pour d’autres objectifs (cf paragraphe sécurité, ci-dessus).

Réaction du support :

Récemment, j’avais détecté un “bug” dans le déchargement des données dans la nouvelle version (1.6). J’ai donc introduit un ticket chez Unistellar.
En moins de 16h, le bug était analysé, résolu et mes données renvoyées correctement.
=> Bon point, et réaction rapide, pour le support ! Dans le monde “astro hardware”, c’est souvent bien plus long…

Conclusion : si on veut systématiquement récupérer ses images pour les retraiter, on peut désormais dépasser 10% de la mémoire et être certain de pouvoir toutes les récupérer… Et mon utilitaire de “clean” ôte les problèmes de confidentialité… 🙂

Dans l’archive reçue, on retrouve toutes les images réellement prises par le télescope en pose courtes… Un exemple précis :

Une capture automatique, mode “enhanced vision”, format “Crop”, sur Android

Cette image se matérialise dans une sub-dir de 264MB, 218 fichiers.
L’image visible représente env. 7 min (420sec), avec une capture (indiquée dans l’APP) de 4 sec.

J’ai demandé des images au format FITS (Taux de compression généralement de 40% min), et ai bien reçu des images de 2,49MB avec 1305×976, une pose de 4sec… Et 108 images => 108*4 sec = 432sec…
Il y a aussi un “average” Dark présent… Tout colle… 🙂
Chaque image est décrite via un fichier JSON dédié qui reprend les informations de capture. Les coordonnées de l’objet sont fournies, et sont parfaitement utilisables par Simbad, par exemple… (Et on retrouve, évidemment : M57)

Ma durée de capture maximum est actuellement de 2h… (soit 1800 images…) et diverses techniques de traitement ont été mises au point.

Mais si je teste (rapidement) un empilage…Je rencontre des problèmes de dématricage. A l’examen superficiel, une image individuelle est :

Une image “raw” de capture

Apparemment, les algorithmes ne peuvent pas déterminer la bonne combinaison sur base des informations disponibles et il faudra regarder cela à l’aise (et régler cela via l’utilitaire de traitement à écrire).

Amélioration de la capture

Les tests réalisés sur différents objets montre les limitations issues du mode “full auto” : tjs 4sec/image de pose, tjs le même gain, “boost” systématique, excepté en mode science (hélas inaccessible pour ses propres travaux).

Même si Unistellar indique que l’ajout d’un filtre n’est pas souhaitable et si dégats : hors garantie…Il est cependant parfaitement possible de rajouter un filtre de 31.74mm sur l’entrée même du capteur numérique.

Un peu acrobatique (mieux vaut faire cela le tube à plat…), on peut facilement mettre un adaptateur “C > 31.74mm” et un filtre pour “booster” la capture.

Trois remarque pratiques :

  • mettre un filtre trop “sélectif” (du genre UHC, OIII, etc…) bloque complètement le guidage via astrométrie. Donc : pas à faire..
  • mettre un filtre “atténuateur” (type ND ou polarisant) permet de certes réguler la saturation, mais est difficile à régler (ou déterminer la valeur ND optimale)
  • mettre un filtre de type “PL” semble offrir une meilleure solution pour optimiser la capture Ha (on “coupe” fortement la fréquence verte) et ne perturbe (pas trop) le guidage astrométrique.

Perso, j’ai actuellement porté mon choix sur un filtre CLS bon marché (la version Svbony) qui répond bien à mes attentes actuelles en terme de photométrie (limiter au maximum la saturation des étoiles dans la longueur d’onde verte).

Exemple de spectre après filtre CLS

Un protocole de capture parmi d’autres…

Après quelques sorties, j’ai fini par définir “mon” protocole de capture.
Il vaut ce qu’il vaut, mais avec le développement d’outils additionnels (le but du site 🙂 ), il me convient.

  1. Je fais fonctionner l’application Unistellar en mode “opérateur” sous émulateur Android sur Windows. Bluestack est parfait pour ce rôle. Cela offre plusieurs avantages :
    1. le confort de la taille de l’écran
    2. les images sont directement exportables vers Windows
    3. le WIFI est plus aisément contrôlable (signal et tentative de piratage), plus rapide et permet de rester bien au chaud en hiver
    4. Dans la configuration, je décoche l’option “ajouter un cadre…”, ce qui implique que toutes les images stockées exploiteront la taille maximale (“full” ou “base”).
      Et je coche l’option “Activer le sauvetage automatique…”, de telle manière que à chaque activation du mode “amélioré”, l’image soit sauvée.
  2. Je démarre une deuxième version, en mode “observateur“, sous Android. Rem : une tablette ! Le smartphone (si on est informé), on le protège, de nos jours.
    1. Si il faut régler la collimation, on peut se déplacer près du télescope
    2. Dans la configuration, je coche l’option “ajouter un cadre…”, ce qui implique que toutes les images stockées localement seront “annotées” avec les informations de capture (avec un masque : “crop” ou “cropbase”).
      Et de même, je coche l’option “sauvegarde automatique”…
  3. Je travaille essentiellement sur PC : recherche d’objet, pointage et puis “vue améliorée” (puisque c’est le seul mode disponible).
    Mais en fin de capture (après x minutes, par exemple), AVANT de clôturer la “vue” (ce qui déclenche la sauvegarde de l’image complète), je sauve “manuellement” l’image sur la tablette, ce qui génère la sauvegarde d’une image “crop” avec toutes les informations de capture sur le Smartphone.

    Remarque : si on veut sauver une série d’images “base” (manuel sur PC), il suffit d’en faire une en début et fin de séquence sur le Smartphone pour garder des informations utiles.
  4. A la fin de la soirée, j’ai donc deux sauvegardes quasi identiques : x images “Full” sur PC et x images “crop” sur Smarphone. Il suffit ensuite de copier le tout dans une structure de sub-précises et de lancer le script écrit spécialement pour l’usage (voir page utilitaires).

En finale, on récupèrera toutes les images “full” correctement annotées et avec une préanalyse sur la qualité.

Voir la page Unistellar : Pre-traitement des images pour en savoir plus.

Premier test avec “Pollution Lumineuse”.

On annonce une grand performance de traitement des images sous un ciel pollué lumineusement. Parfait, c’est justement mon cas toute l’année ! 🙂
J’habite dans une région particulièrement touchée : proximité d’une grande cité (8 km), d’un aéroport (5km) et de lumières intempestives (éclairage urbain inadapté), bref : disposer de 18,5 mag/arcsec² est déjà une bonne nuit…

Avec la météo actuelle, il faut profiter de la moindre éclaircie…
voici les tentatives réalisées un matin entre les nuages.

Le site est pollué lumineusement toute l’année (Bortle 8/9) et un SQM de 20,4 est le maximum atteignable (exceptionnel, en cas d’éruption volcanique empêchant les avions de décoller et de panne de courant !)

De 4h à 6h, la météo fut relativement calme, avec des nuages de haute altitude. A partir de 6h, les conditions se sont lentement dégradées (nuages bas et moyenne altitude). A 7h (fin des tests), on avait le ciel quasi totalement couvert… Donc : des conditions météo peu favorables !

Mise en station :
La focalisation et la création d’un “Dark” ayant déjà été réalisé la nuit précédente, cela prend

  • 1 min pour sortir physiquement le télescope
  • une fois démarré, 1 autre minute pour annoncer “prêt à l’emploi”.

=> C’est remarquable… Et comme indiqué, le cahier des charges est rempli.

A chaque “goto” demandé, le télescope se dirigera vers la “région” cible (approximative) et ensuite, par astrométrie et déplacements successifs, se dirige vers l’objet concerné.

Cependant avec des “ratés”… Surtout sous un ciel “éteint”, certains Goto finissent par : soit la mauvaise région du ciel, soit on rate l’objet cible (surtout si il est faible). Mais là encore : il suffit de “relancer” le Goto (il repart dans un cible de détermination+déplacement) et généralement à max le 3ème coup, il parvient à parfaitement centrer l’objet !

=> C’est efficace, relativement rapide et fait très bien son job : une belle solution technique !

Le suivi et les solutions pratiques pour la qualité

Faut pas réver… Ce sont de petits moteurs, du plastique et une monture en mode altazimutal ! Donc, le pointage aura les faiblesses bien connues.

Que fait le logiciel pour parer à cela ?
Je remarque que lors d’un pointage “manuel” (coordonnées), le GOTO prend en finale “son temps” pour vérifier le positionnement. Il finit généralement avec une mention “GOTO vérifié”. Et là : l’image est relativement stable (comme il peut l’être dans ce mode de pointage).
Donc : l’empilement sera plus valable et les étoiles mieux définies…

Quand on pointe un objet du catalogue, il fait “plus confiance” et généralement, n’effectue pas cette vérification finale. Donc, si l’image dérive après pointage, il suffit de la reproduire manuellement !

Evidemment, la position du tube influence cela (au plus bas, le moteur “peine” un peu), mais c’est simple : il suffit d’opposer une commande de déplacement opposée à la direction de la dérive (2X de préférence)

Donc : si l’image dérive vers le bas = appuyer 2x sur la commande “vers le haut”. Et généralement, cela règle le “backslash” moteur qui pose problème.

Rem : rien de nouveau, on fait cela systématiquement sur d’autres télescopes de ce type.

La collimation et la mise au point est cruciale… Dans ce dernier cas, mieux vaut réduire l’intensité de la capture au minimum pour que la mise au point utilisant le masque de Bathinov soit la plus précise possible…

Betelgeuse fortement “éteinte” pour disposer de la meilleure MAP

Quand à la collimation, autant “zoomer” au maximum pour arriver à centre la croix (je travaille par capture d’écran pour vérifier dans GIMP le centrage).

La capture en elle-même… On sait pas faire grand chose !
D’un côté, c’est le but de la solution (rendre accessible à n’importe qui) mais de l’autre, c’est vite “limitatif”.

Si on est en mode “vue directe” (brut de capteur) on peut régler gain et durée de capture (jusque 5 sec). Mais cela de manière fort peu précise (curseur) et refaire deux fois de suite le même réglage exact est du sport…

Mais dans ce mode : seule la “vue directe” exploite ce réglage (bouton sauve image)… On ne se voit pas faire 500 sauvetage en pose courte manuellement ! Donc : exploitable que pour les objets fort lumineux (Lune et Soleil…)

Dans le mode “vue améliorée”, on dispose de deux réglages (amplification et fond). Le mode “auto” va impitoyablement “saturer” les étoiles à l’empilage… Là encore, pour une vue sur un Smartphone et un petit écran, cela passe… Mais quand on regarde sur un plus grand écran, la qualité de l’image finale se dégrade progressivement… (les étoiles grossissent et n’ont pas de dégradés). L’usage d’un filtre aiderait à réduire ce phénomène… Mais là, c’est une autre histoire… (pour plus tard)

A ce stade, sur des objets ponctuels, je mets l’amplification quasi au min (et laisse poser plus longtemps) et le fond du ciel au milieu. Sur des objets “larges”, l’amplification est réduite de 1 cran alors que le fond du ciel est gardé au milieu.

Après application de ces principes, on obtient des images qui raviront les observateurs occasionnels du ciel… Ce qui est bien le but premier de cette technologie…

M42, avec léger réglage de niveau pour l’affichage web…

Comparaison rapide avec une autre configuration

Une astrophotographe débutante a tout récemment réalisé une image idéale pour comparer… Sa configuration : 150/750, EQ3.2, ASI385, ASI AIR, 8 min de captures à 5 sec de pose individuelle, résultat du “live stacking” ASI .

Vu les fonctions EAA désormais disponibles sur l’ASI AIR, on est dans un concurrent direct de la solution… (env. 2000 eur, soit la moitié de la nouvelle configuration V2)

Image capturée par une configuration classique (Merci à “Vivi” de AstroNamur 🙂 ).

La différence dans les “détails” obtenu (et la différence entre 150mm (R=1,07) et 112mm (R=0.8) n’est pas si énorme, sous un ciel perturbé de Belgique) saute immédiatement aux yeux…
Y-a-t-il moyen de faire mieux avec l’Evscope ? Il faudra voir avec les brutes, mais sinon : on voit directement la différence des buts :
– Evscope = obtenir une image “rapidement” sur petit écran et sacrifier la qualité dans ce but.
– Matériel “EAA” assemblé = setup standard (composant et poids, mise en station obligatoire + temps pour le faire), mais la qualité est présente.

Mode “science” participative

Entre deux observations, j’ai réalisé une première session de “capture” (40 min sur un astéro¨¨ide NEO) récemment. Et ai envoyé toutes les données via “upload”… Elles semblent être parties (la mémoire est vide)…
J’ai introduit également le formulaire pour indiquer la capture.
A ce stade , pas de message pour savoir si les infos étaient valables ou pas…

Mais… J’avais aussi capturé des images hors “session science” et il apparait que lorsque j’ai demandé le download des données RAW, le support Unistellar m’a répondu que… Il n’y avait rien !

Bug ou systématique lors de l’utilisation du mode “science” ? Je l’ignore à ce stade… Il faudra retester…

Conclusion finale

Essayons de synthétiser

TopicScoreCommentaire
Intégration+++1 sac et tout y est, aucun fil autour
Poids+++9.5 Kg (Trépied + Tube/moteur)
Setup+++Difficile de faire plus simple…
Démarrage+++Immédiat
Mise en station+++Inutile…
Pointage+++Très peu d’erreurs et un “redo” le corrige
Suivi++Altazimutal… Avec défauts inhérents liés.
Vitesse pointage++Petits moteurs, raisonnable sans plus.
Mise au point+++Avec masque Bahtinov, efficace si on diminue l’intensité de l’étoile cible
Collimation+Simple, mais peu précise
Live Stacking++Efficace pour le suivi (et dérotation), mais “sursature” trop dans le but d’offrir la visualisation immédiate sur petit écran de smartphone…
Images directes– – –Que 8 bits ! (png)
Et sans “export direct” de la mémoire du télescope.
Images RAW++Complète, mais accès limité dans le nombre
des images ! (que 10% de la mémoire du télescope)
APP (Android)+++Efficace, mais il manque des fonctions…
Export d’image relativement simple
APP (Iphone)++Idem, mais “export” peu pratique avec moins d’information encore !
Usage privé+++Il fait son job et très bien même avec de la PL.
Mais il ne faut pas espérer (de base) de belles images de Nébuleuses profondes…
Meilleur sur étoiles, objets ponctuels faibles et galaxies, mais le problème de “sursaturation” systématique est pénalisant sur les images “standards”. Sur le Soleil, peut être efficace avec un (très) bon filtre. Sur la Lune : moyen…
Usage public+Tant que l’on reste sur un écran…
Et en espérant que personne ne perturbe votre session, vu la sécurité informatique inexistante…

Dernier point : il existe un guide (gratuit) pas mal fait pour les débutants…
Je recommande la lecture..