brno92

A la demande de plusieurs membres du club astro auquel j'appartiens (Luberon Sud Astro http://www.astrosurf.com/lubsudastro/ ), j'ai réalisé une présentation sur le sujet qui hante de nombreux astronomes amateurs qui est celui concernant l'achat d'une caméra CCD (comprendre CMOS ou CCD) J'ai pensé que cette présentation pourrait être utile à de nombreux amateurs qui souhaitent franchir le pas! Je ne suis pas allé très loin dans la théorie, que l'on trouve d'ailleurs un peu partout, mais j'ai voulu faire un document très pratique (pour quoi faire, pour quel prix, quels sont les fournisseurs etc.) Ce document c'est une dizaine d'années d'expériences plus ou moins réussies (!) avec aussi une dizaine de caméras de tout type achetées ! Il est bien sûr critiquable à de nombreux points de vue, et ne vous privez pas, cela fera progresser le sujet !!! Voici le sommaire : - Un bref rappel historique - Quelle camera pour quelles observations? - Donnée essentielle d’une caméra CCD : dimensions du capteur - Pourquoi une caméra plutôt qu’un AP? - Exemples de caméras CCD utilisées au cours des années - Les principaux fournisseurs et la stratégie d'achat - Conseils divers - Étude de cas : C8 (du club) et caméra Ares-M PRO USB3.0 Couleur Refroidie (IMX 533) Annexes Bonne lecture CameraCCD Guide PratiqueV4.pdf

Le seul USB extender filaire qui existe en USB 3 est, sauf si je me trompe, l'ICRON 3104 (les autres nécessitent une fibre optique) Superbe matériel mais dont le prix est de 869 euros ! Il a 4 ports, mais tu peux mettre sans problème un HUB usb 3 de qualité derrière. https://www.icronshop.com/icron-brand/icron-raven-3104 Si cela t'intéresse vraiment, je peux faire un essai avec les caméras ZWO à nouveau derrière le DS600 ou le SH pour voir si maintenant elles sont supportées.

J'ai pendant longtemps utilisé un USB extender, en l'occurence de modèle ICRON 2304 puis 2312, qui m'ont donné toute satisfaction... jusqu'à ce que je reçoive ma caméra QHY42 qui est en full USB 3.1 et qui ne marchait pas avec les extenders en question. Tous les matériels que vous citez ne supportent que de l'USB 2.0 et non du 3.1 A ma connaissances seul le nouvel extender ICRON 3-2-1 3104 supporte du USB 3.1, mais il doit être hors de prix (sachant que le modèle 2312 est déjà à 420 euros, chez Sphinx France) Concernant le Silex DS 600 et plus encore le SEH, le logiciel de gestion de ces deux équipements sont en permanente évolution et gagnent en performance, stabilité, nombre de périphériques supportés : mon expérience d'y a deux ou trois ans n'a rien à voir avec ce que j'utilise aujourd'hui.

Le Silex a deux ports : un USB 3.0 et un USB 2.0 : tu peux mettre un Hub USB 3.0 sur le premier et connecter 4 device rapides (dont caméras) et un autre Hub USB 3.0 ou 2.0 pour 4 devices plus lents La qualité du Hub USB est très importante et pour ma part j'utilise des "AUKEY HUB USB 3.0 7 Ports ( 4 * USB 3.0 + 3 * Charge 2,4A ) Hub USB SuperSpeed avec Adaptateur d'alimentation" J'ai connecté toutes les caméras sans problèmes (Starlight Express, FLI, y compris QHYCCD USB3.0) à l'exception des ZWO (je ne sais pas pourquoi) En annexe, exemple de connexion de ma configuration actuelle

J'utilise un Silex DS600 entre ma coupole et mon bureau observatoire (environ 60m) Derrière le Silex, il y a un hub USB 3 Aukey. Le tout marche très bien. J'ai même connecté ma caméra QHYCCD QHY42PRO qui a une interface USB3 et elle marche parfaitement La connexion est vue par les logiciels comme de l'USB standard et tous les logiciels, dont ASCOM marchent L'ancien modèle est moins rapide, moins stable et USB2 seulement Alimentation_electrique_V2.2.pdf

Juste une info : j'ai upgradé comme prévu (et gratuitement) ma QHY42 en QHY42PRO (je l'ai envoyé au centre de support en république Tchèque : Jan Soldan en charge s'est démené pour cet upgrade - pas facile semble-t-il ! Mais il m'a tenu au courant tous les 2-3 jours !) J'ai donc récupéré ma caméra (gratuitement y compris les frais de transport !!! ) Merci QHYCCD Première très bonne surprise : le logiciel marche maintenant à la perfection et notamment le driver ASCOM: il est beaucoup plus stable, l'image reçue est l'mage prise au déclenchement, on peut déconnecter la caméra sans crash, l'offset reste stable... Les deux modes sont implantés : STD et HDR (y compris en ASCOM) : HDR, qui donne deux images à deux gains différents, ne m'intéresse pas En fonctionnement STD, les caractéristiques sont à peu près les mêmes qu'avant, sauf que la plage de réglage du gain n'est plus 0-24 mais 0-255). mes réglages de gains anciens (4 pour DSO et 7 pour objet faible sont maintenant de 6 et 10) La (très grosse différence) c'est que maintenant la prise de vue est image par image et non plus une capture du mode vidéo J'ai hate de l'essayer à nouveau sur des objets faibles

J'ai pu observé l'astéroïde Nissen mag 16.9 le 25 Janvier de 20h47 à 23h07 TU 558 images de 10 secondes chacune Première image à gauche : c'est une image calibrée de 10 secondes, en début de période où l'on voit l'astéroïde Première Image à droite : ces ont les 558 stackées où l'on voit clairement la trajectoire de l'astéroïde Deuxième image à gauche : stack de 60 images soit 10 minutes : on voit Nissen au début de la trajectoire Deuxième image à droite : idem mais en fin de session Calcul de la position à 20h47 : Mesurée : AR : 6h34'30.3 DEC : 35 48 23 Éphéméride : AR : 6h34'30.2 DEC : 35 48 22 Pour Varuna, j'ai essayé, mais la magnitude est trop faible ! En plus il se déplace plus vite ! Mag 20 : pas possible Si tu veux des .fit, dis le moi Qu'en pense tu ?

Juste pour indiquer que QHYCCD est en train de développer une nouvelle version du software (camera et driver) permettant un mode natif "single shot" et non simplement un échantillonnage du buffer de la camera. Ceci permettra de supprimer un défaut majeur qui est que l'image que j'obtiens n'est pas en général l'image que je demande, mais une précédente !! (décalage dans les filtres, étoiles qui bougent pendant le guidage ou pendant un slew fait pourtant avant l'acquisition, erreur de temps dans l'en-tête FIT). Et permettre enfin d'utiliser la sensibilité exceptionnelle des chips CMOS Sony et Gsense de manière simple ! Je ne sais pas si cette modification nécessitera une évolution du firmware pour les autres cameras utilisant le driver QHYIII , mais c'est le cas pour la QHY 42. Voir : https://www.qhyccd.com/bbs/index.php?topic=6713.15

Aurais tu une suggestion d'objet faible à observer à titre de comparaison ??

Dès que le ciel se fera un peu plus clément, je ferai un essai sur un objet faible

Merci

Troisième et dernière partie des mesures effectuées avec la caméra QHY42 : mesure du transit d'exoplanètes et comparaison avec d'autres caméras. En résumé, l'approche consistant à prendre 2500 images de 4 secondes (limite de la saturation du full well), puis de les réduire à 160 images de 60 secondes permet de produire des mesures d'excellente qualité et souvent meilleures que celles fournies par des caméras plus conventionnelles à diamètre de télescope équivalent. Même si cette caméra est d'un usage assez difficile, on peut tirer pleinement profit de son QE très élevé (95%) et de son large spectre notamment en proche IR (60% à 800 nm). bonne lecture ! Transit Measures with QHY 42 Camera.pdf

@Gribol Encore un commentaire à propos de la phrase : "- Le choix des étoiles de comparaison au niveau des indices de couleurs (le plus proche possible de l'étoile à mesurer)" C'est ce que dit la théorie et notamment Bruce dans son livre en expliquant très bien pourquoi !!! (le bleu absorbe plus que le rouge lorsque la masse d'air augmente; c'est pourquoi il a fait construire un filtre dit CBB qui coupe les bleus mais laisse passer les infra rouges moins sensibles à l'absorption atmosphérique et permettant en plus de récupérer beaucoup de flux si votre caméra le permet !! Et la QHY 42 est très sensible dans l'infra rouge ;))) Mais la réalité est plus complexe (comme toujours) ! Si le transit est court et si la masse d'air faible (1.0 - 1.2) la différence de couleur joue très peu : si vous avez la chance d'avoir une étoile check assez proche, un peu plus lumineuse que l'objet, de couleur pas trop différente, n'hésitez pas. Dans mon logiciel qui optimise le poids des étoiles de comparaison, les résultas sont parfois surprenants !! Souvent une étoile qui a tout pour être un bon candidat (proche, même couleur, un peu plus lumineuse) s'avère une catastrophe dans la régression (en clair, si vous l'éliminer, l'écart type s'améliore brutalement t) . Parfois pas d'explication, mais souvent : c'est une étoile double (pas très visible) et donc un shift d'un pixel aura une influence très forte sur le flux, et encore plus souvent il y a un bad pixel (soit dedans soit à proximité). A ce propos, je conseille vivement avant de commencer une série de mesures de décaler un tout petit peu le télescope et de bien regarder s'il n'y a pas de bad pixel à l'endroit du l'objet à mesurer. En effet, si c'est le cas, toutes les mesures seront inutilisables !!!

En fait cela dépend plus de la précision de l'analyse astrométrique de PinPoint (en général 0.2 pixel pour la plaque, soit 0.3 - 0.5 pour le centre) que de la précision de la monture qui est de l'ordre aussi de 0.2-0.3 sec pour un recalage En fait je suis toujours en dessous du pixel, pour le recalage lui-même. Mais avant de recentrer, la monture a pu se décaler de 2-3 pixel sur une durée de 30 - 60 secondes. Avec des images toutes les 2 secondes, je recale tous les 15 images, ce qui est largement suffisant. L'amélioration pourrait venir de Maxim DL lui-même : le calage astrométrique prends du temps et n'est pas toujours opérationnel (parfois, il ne trouve pas la position du tout!) et du coup à moins d'avoir l'oeil rivé sur les mesures (c'est pas mon truc!!) la manip s'arrête !! et il faut relancer à la main! L'idéal serait pouvoir choisir l'algo de rentrage notamment "astro star matching" (comme c'est possible dans la fonction stack!) et non systématiquement "astrometric" : cela serait d'une précision équivalente voire meilleure, beaucoup plus rapide et beaucoup plus fiable. Je n'ai jamais eu le temps de leur passer le message ! Je ne sais pas du tout ce que donnerait cette méthode avec une monture moins performante, mais au départ j'ai eu une monture EQ6 avec un interface ASCOM (un très grand merci au passage à l'équipe qui a développé EQASCOM, multipliant les qualités de cette monture assez bon marché !) et j'ai été très surpris de la qualité de cette monture à partir du moment où elle était pilotée par Maxim DL y compris en recentrage. C'était sans doute pas au pixel près mais pas très loin !

Au sujet de la modélisation du transit, j'ai bien sur commencé avec les feuilles Excel de Bruce Gary, et j'ai beaucoup ramé !! Ensuite, j'ai fait pendant longtemps un pré-traitement assez simple en Excel avant de procéder à une simulation avec le site ETD. L'ennui, c'est que dès que vous voulez voir l'impact de prendre tel ou tel jeu d'étoiles de référence, que vous voulez voir l'impact du rayon d'ouverture, du temps de pose (en moyennant) cela devient très vite fastidieux !! En plus, le site n'est pas complètement à jour par rapport au site de la NASA sur les candidats et leurs paramètres. D'où l'idée d'écrire un software complet correspondant à mes besoins, et en local !!! Aujourd'hui, je m'en sers systématiquement et je n'envoie les mesures à ETD que pour publication finale. Si le jeu vous tente, soit je vous donne une copie de mon logiciel (avec strictement aucune garantie !!) soit je vous donne quelques références documentaires qui permettent de gagner beaucoup de temps : - FitProcedureDescription-Pejcha2008 : c'est algorithme utilisé par ETD lien : http://var2.astro.cz/ETD/FitProcedureDescription-Pejcha2008.pdf - Mandel & Agol, Transit Light Curves : modélisation du transit (utilisé dans Pejcha) lien : http://iopscience.iop.org/article/10.1086/345520/fulltext/16756.text.html - Detection and characterization of extrasolar planets: the transit method (Claire Moutou1 and Frédéric Pont2) http://sf2a.eu/goutelas/2005/chap03-moutou.pdf - Pour l'algorithme de régression non linéaire (Gauss Newton) https://fr.wikipedia.org/wiki/Algorithme_de_Gauss-Newton - Et pour les bibliothèque matricielles (pratique !! déjà écrit en VB) : https://codes-sources.commentcamarche.net/source/44258-inversion-de-matrice-resolution-de-systemes-d-equations-lineaires Voici quelques exemples d'utilisation : Choix d'un candidat à partir du catalogue de la NASA (téléchargeable dans l'application) Mesures moyennisées à partir d'un fichier en sortie de MaximDL : Affichage des mesures brutes de toutes les étoiles (objet et checks) (permet d'identifier des points aberrants) Et enfin et surtout, la réduction des données sur le modèle de transit : et cerise sur le gateau, les prédictions pour un jour donné !!