Jump to content

Mala

Membre
  • Content Count

    81
  • Joined

  • Last visited

About Mala

  • Rank
    Membre
  • Birthday 11/02/1978

A propos

  • Résidence
    Gap
  • Intérêts
    Heu... l'astro, le dessin, dao, un peu de 3D, la programmation, l'astrophotographie, etc... etc... e
  • Occupation
    Développement logiciel
  • Matériel
    Mewlon 250, CN 212
  • Site Web

Recent Profile Visitors

972 profile views
  1. Du seconde degré? Pas mon genre. Sinon j'aurais mis des guillemets... 😁
  2. Pour ceux que cela pourrait intéresser, j'ai partagé sur mon thingiverse les adaptateurs en impression 3D pour barlow Powermate 3x et 5x... https://www.thingiverse.com/thing:4562984 Ils ont été conçus pour le Canon EF 400 F/5,6 qui permet de rentrer la barlow en partie dans l'arrière creux de l'objectif. Le tirage obtenu permet à la fois un usage en imagerie avec caméra et ADC ainsi qu'en visuel avec renvoi coudé. La compatibilité sera à vérifier si vous souhaitez les utiliser avec un autre caillou. On obtient ainsi une mini lunette de 71mm dans mon cas... Et voici quelques exemples de ce que cela peut donner en planétaire... Bref, autant dire qu'on emplafonne joyeusement les montages avec mise en cascade d'Extender 1,4x ou 2x de chez Canon pour un prix défiant toute concurrence. La barlow 3x TeleVue coulant 31,75mm coute en effet moins de 135€... Bon ciel à tous et bonne journée.
  3. Tu photographies avec quoi niveau caméra sur ta 120? Voici ce que j'arrive à sortir avec une ASI290MC et mon téléobjectif de 400mm (Canon EF 400 F/5,6) soit à peine 71mm diamètre. J'y ai adapté une barlow 5x pour pousser la focale à 2000mm (F/28)... Alors je n'ose imaginer ce qu'on peut sortir avec une TSA 120. 😍 Je précise que j'ai également un CN-212 et un Mewlon 250 donc je comprends parfaitement ton envie de monter en diamètre mais le rapport plaisir/qualité/emmerdement n'a rien à voir par rapport à une lunette. J'avoue que je serais toi, je commencerais par la pousser à bout avec une bonne petit cam + barlow + ADC. Il y a vraiment de quoi faire.
  4. Ça me semble beaucoup sauf à alimenter aussi le PC portable non? Moi j'utilise une batterie au plomb de voiture de 45Ah depuis des années en nomade. Même avec le peltier à plein régime ça laisse plus de 13 heures d'autonomie. Et c'est pas le scope en suivi sidéral 99% du temps qui consomme. J'ai pris les cotes directement sur la cam. J'ai trouvé des schémas sur le site de ZWO mais il n'y a pas toutes les cotes et j'ai l'impression que ce n'est pas à jour pour toutes les caméras.
  5. Vu les résultats avec un simple relai, je pense pas qu'il y ait matière à s'embêter. Et je sais pas si tu as vu mais il n'y a pas de prix et dans le coms il faut commander plus de 25 exemplaires... Dernier test hier soir avec nouveau peltier et un nouveau cocon optimisé. Je pense avoir trouvé un excellent compromis puissance/consommation avec le TEC1–12704 36W en 40x40. La cocon a été revu et simplifié. Il intègre maintenant directement les pattes de fixation du ventirad ce qui fait une pièce de moins à imprimer. Un logement a aussi été ajouté pour positionner le capteur de température contre la paroi. L'épaisseur du capot a été augmentée pour améliorer l'isolation... Je fais maintenant deux tours de cable autour de la caméra et c'est beaucoup mieux. On garde un défaut de linéarité avec la sonde caméra (plus conséquent à température ambiante) mais c'est bien moins important. A noter qu'il semble crucial de laisser respirer les pourtours du peltier sous peine de diviser par deux son rendement. Suite à divers essais j'ai donc revisité légèrement la partie arrière... Mais du coup, la paroi arrière reste extrêmement fine ce qui n'est pas idéal en terme d'isolation dans l'absolu. En l'état, j'atteins maintenant un delta de quasi -27°c sous la température ambiante niveau capteur... Stabilisé avec juste la ventilation (un peu plus optimiste que le boitier nu) j'avais une température capteur de 30,2°c avant de commencer l'expérience (100ms / Gain 300)... Soit un bon -34°c de delta de température capteur avec le refroidissement. Le TEC1–12704 me semble un bon choix. Non que l'on gagne énormément en température mini mais il est surtout beaucoup plus réactif avec une chute de température qui avoisine les 4°C/min sur la phase d'amorçage... Avec une consommation de 3,4A une fois lancé, je pense qu'on est pas mal du tout en terme de rendement. On dépasse même les 40w alors qu'il est donné pour 36w. La partie qui m'embête encore niveau conception c'est le capteur de température étanche. Ça passe crème pour ma 290 mais pour des boitiers moins hauts il va déborder et poser souci pour les tours de câble autour de la caméra. 😕
  6. Non car dans ce cas, on ne pourrait guère descendre en dessous de 10° sous la température ambiante. L'idée c'est d'abaisser la température de la caméra et de l'air du cocon d'isolation. Du coup, on abaisse en même temps le point de rosée. Si condensation il y a, elle est dans les alvéoles du cocon en impression 3D comme les pièces ne sont pas pleines. Hors ces alvéoles ont été fermées lors de l'impression avec des températures de plus de 200°c donc peu probable que de l'humidité y subsiste. C'est ce que je fais avec une sonde positionnée dans le caisson. Mais comme évoqué précédemment, pour un asservissement correct il semble important d'être en contact avec l'alliage de la coque de la caméra pour limiter l'inertie de l'air. j'arrive alors à réguler avec une stabilité de l'ordre de 0,1°c ce qui est excellent. Reste le problème de delta entre la sonde du module et de la caméra. C'est effectivement bien mieux en suivant les recommandations de Gilles et encore vu la proxmiscuité dans mon cocon, je n'ai pu y insérer que 3cm de câble. Je vais voir pour faire un passage de câble pour enrouler le fils de la sonde sur le prochain proto. Par contre, en continuant les tests, je constate un souci. La température de la caméra varie bcp en fonction des réglages (High speed, frame rate et gain notamment). Ce qui me chiffonne c'est que ce delta de l'ordre 1°c, je ne le retrouve pas côté sonde du module. A creuser... En l'état, je vais optimiser le caisson existant en améliorant l'isolation arrière + échappement du flux d'air + test d'un peltier 40x40 pour plus de puissance.
  7. Toutes les solutions sont envisageables simplement il faut peser le pour et le contre en terme de complexité/coût/Intérêt. Ici l'importance n'est pas tellement d'avoir une mesure hyper précise mais reproductible. La caméra dispose déjà d'une sonde donc on a une référence de calibration. Je pense que Gilles a soulevé un point intéressant à vérifier. Ça ne résout pas le problème effectivement et perte de garantie assurée. Et quiz de la complexité de mise en oeuvre? Comme tu l'évoques c'est loin d'être si simple. Le moindre loupé sur la surface du capteur... De plus la condensation qui gèle c'est de la dilatation assurée donc ça peut être aussi destructeur à terme sur l'électronique. A mon sens, la solution la plus efficace reste de prendre le problème à sa base en se tenant à l'écart du point de rosée. Après chacun explore la voie qu'il veut.
  8. Excellente idée. Je me suis posé la question justement.
  9. J'ai enfin réceptionné un w1209 avec écran et sonde. Les premiers essais sont concluant. Pour peu de coincer la sonde de température contre la coque de la caméra un asservissement stabilisé sur une plage de 0,1° fonctionne très bien... Par contre, j'ai noté une dérive importante entre la température caméra et celle du module depuis -24°C jusqu'à atteindre -2°c. Au début je suis à environ +4°c au dessus de la température capteur et à la fin je termine à -4°c. Je penche pour un problème de calibration des données de la sonde du module. De même, du fait du signe - sur l'afficheur, la température sous les -10°c se fait alors au degré près et non plus au dixième. Bref, le principe d'asservissement en tout ou rien fonctionne bien malgré l'inertie mais je pense qu'il y a matière à améliorer la copie en version Arduino.
  10. J'ai pas creusé mais je doute qu'une lecture usb bulkin/bulkout se fasse à accès concurrent sur le driver ASI. Et rien que cam86 déjà tu es 100% windows (c'est con je suis sur Mac quand il s'agit de mon plaisir... 😆). Honnêtement, je pense que ce sera bien plus portable en autonome avec un LCD à côte de l'alim. Tu cales la température désirée en début de séances, tu attends de voir si moyennant ta température ambiante tu obtiens bien ta consigne et basta c'est parti pour la soirée. Le temps de valider l'asservissement avec un beau boitier en impression 3D, de faire quelques tests pendant l'été sur la longueur et ce sera la cas. Et il manquerait plus que le fichier OpenSCAD permette de sortir des STL aux dimensions des différentes petites ASI non?
  11. Merci les gars! @Muloche En fait ce qui est bien avec le sarcophage d'air c'est qu'on abaisse la température de l'ensemble donc aucun problème d'humidité à l'intérieur mais rien n'empêche le dessicant par sécurité. Oui c'est quasiment parfait. Tu peux l'apercevoir sur cette vidéo de montage/démontage. Je le tourne vers la caméra à 0:26 collé au cul du ventirad... Je pense tester également les 40x40 à terme histoire de voir. Je vais opter pour la sonde extérieure pilotée avec boitier de contrôle Arduino et écran 16x2. Je n'aurais aucun problème à faire un asservissement via PC mais cela veut dire faire toute la partie prise de vue également et j'ai pas envie de m'emmerder. J'ai déjà donné à une époque avec les Starlight Express. J'ai commencé à bosser dessus. L'asservissement en vitesse du ventirad via pwm est opérationnel avec retour de la sonde de vitesse également... J'attends les composants pour la partie puissance. Je vais tester le W1209 pour voir ce que donne "du tout ou rien" niveau rendement (j'ai peur qu'on ai beaucoup d'inertie) et aussi une approche via MOSFET en pwm. Passé le KHz certains disent que l'inertie thermique permet d'asservir correctement sans trop de pertes et sans filtrage. Tout cela reste à défricher. Dans l'immédiat, j'ai réalisé les premières images en régulant manuellement avec mon alim de labo l'autre soir... Le setup a tourné plus d'une heure et demi sous zéro sans aucun souci monté sur mon téléobjectif de 400mm. Ici on peut voir M57 shootée à -11,2°c (-23°,2c sous la température ambiante donc on peut ajouter facilement 10° de plus de delta niveau capteur) et qu'on est parfaitement stabilisé sur plus de 5min. En fin d'observation à une heure du matin le capteur était nickel chrome. Et quelle différence sur la montée du fond de ciel et les pixels chaud!!! C'est très encourageant.
  12. Le refroidissement c'est une chose mais si condensation point de salut. Donc en fait le "juste" est tout sauf un problème mineur ici. L'idée d'isoler la caméra est de créer un cocon pour éviter que l'air "chaud" ambiant ne vienne se transformer en gouttelette lorsque la température de la coque descend sous le point de rosée. Je réactive donc un peu ce sujet en vous présentant mon approche du problème en impression 3D pour mon ASI290MC... J'ai opté pour un sarcophage pour emprisonner une petite couche d'air autour de la caméra car l'air reste le meilleur isolant. Comme l'air est confiné (mot à la mode en ce moment), sa température va suivre celui de la coque. Du coup, aucun dépôt d'humidité à l'intérieur du cocon. Voici un éclaté de ma conception 3D... Reste le problème de la vitre. Personnellement, j'ai minimisé l'effet en plaçant mon filtre IR-cut sur l'adaptateur qu'on voit en noir (adaptateur ZWO/Canon maison lui aussi)... https://www.thingiverse.com/thing:4307480 Comme il est imprimé en PETG, la bague du filtre n'est pas en contact avec le métal froid et la température chute moins. Je descends ainsi sous la barre des 11°c pour une température ambiante de 24°c avant que la face avant du filtre ne se refroidisse sous le point de rosé et que de la buée apparaisse. Deux solutions à ce stade: - chauffer la vitre. - isoler la vitre dans une seconde chambre. Hors, monté dans mon cas derrière un correcteur de coma sur mon Newton ou derrière un objectif c'est exactement ce qu'il va se passer. L'air de la chambre, si le volume n'est pas trop importante, fait comme avec le cocon de la caméra et cela repousse le point de rosée. Je descends ainsi autour des 4°c capteur (pour 22,4 ambiant et on peut ajouter d'expérience +10/12°c au niveau du capteur sans refroidissement) et ça avec un petit peltier de 30x30 à 3.2A max (2,63 une fois en inertie)... A ce stade, je n'ai toujours pas de buée et j'arrive aux limites du peltier. On frôle les -30°c de delta au niveau de la température capteur. Je pense que je pourrais gratter encore un peu en poussant le ventilateur du ventirad qui n'est qu'à 50% de sa vitesse mais c'est volontaire pour limiter les vibrations.
  13. Je continue mon petit bout de chemin sur le viseur polaire avec la corrélation stellaire. Pour être le plus performant possible sur le Pi Zéro lors des captures en live, toutes les coordonnées cartésiennes des étoiles seront pré-calculées en pixels (sur la base de l'échantillonnage connu du couple capteur/objectif) et les distances entre chaque étoile stockées dans une base SQLite. Deux avantages: Il sera très facile de limiter le champs de recherche des segments en bornant simplement les requêtes SQL sur leur longueur. Aucune conversion supplémentaire nécessaire afin de respecter des rapports d'échelle pour comparer les distances entre les étoiles. La déformation de champs de l'objectif étant très limitée, une tolérance de +-2,5 pixels semble suffisante pour filtrer correctement les segments. Bref, l'identification commence à marcher... Après avoir fait un peu le tour de ce qui existe pour la conception d'interface (Qt, Gtk, etc), j'avoue ne toujours pas être super emballé par la plateforme Linux dans ce domaine. C'est vieillo et lourd à souhait à mon goût. Du coup j'ai décidé de repartir sur ma bibliothèque ScreenView réalisée à la base pour Arduino. ScreenView est donc en train de devenir une bibliothèque multiplateforme (PC/Raspberry PI/Arduino) pour concevoir facilement des interfaces graphiques en C++. Le code est très fortement inspiré des paradigmes de Mac OS avec son principe de hiérarchisation de vues et l'approche MVC (Model/Vue/Controller) que j'affectionne particulièrement... Le retour d'évènement est 100% objet avec une gestion par délégation (tel qu'on le connait en Objective-C et non en C#). L'idée est donc d'avoir une API haut niveau commune et d'adapter le bas niveau en fonction de la plateforme. Pour Arduino, pas le choix c'est du quasi spécifique à l'écran 4,3" que j'utilise. Pour le Raspberry et le PC, j'ai opté pour OpenCV comme sous couche graphique commune. Voici un aperçu des premiers éléments d'interface sous Linux... J'ai bien dit Linux contrairement aux apparences. Ce n'est pas une appli Mac qu'on aperçoit sur la capture. Je développe en fait sur Xcode mais le code est compilé et exécuté à distance sur Raspbian qui renvoie l'interface graphique à XQuartz via un canal SSH. Linux avec le confort du Mac quoi... Le rendu des interfaces est un peu plus customisé "Desktop" pour le PI mais on retrouve les fondements de ScreenView sur Arduino avec notamment son mode jour/nuit. Voici un aperçu en vidéo... L'idée de base est donc de disposer d'un viseur polaire qui soit autonome au niveau logiciel (capture caméra, analyse du champ d'étoiles et interface graphique). Il suffira d'un simple client VNC sur une tablette, un smart phone ou un PC pour prendre le contrôle du viseur polaire sur la Raspberry.
  14. Ce n'est pas adapté à ce que je veux réaliser. Je ne me contente pas de la position du codeur pour m'indexer sur une table de correction. Mon idée est d'utiliser l'encodeur pour asservir la vitesse (et non la position) afin de compenser en temps réel les erreurs périodiques en amont de la vis sans fin (démultiplication interne du moteur et les deux engrenages de transmission)... Cela permettrait de mettre au point un PEC double étage mêlant l'asservissement de vitesse en cascade avec une mémorisation PEC classique pour la vis sans fin. Ainsi plus de problème avec d'éventuelles sous périodes non multiples de l'EP principale. C'est impossible à faire avec des encodeurs fonctionnant en SPI. J'ai besoin de gérer en direct au niveau Arduino les interruptions matérielles pour mesurer le temps écoulé entre chaque pas codeur et ainsi en déduire la vitesse instantanée.
  15. Pour l'instant je teste avec un encodeur optique incrémental. Celui-ci n'a pas de signal d'index mais je viens de recevoir son grand frère qui en a un. Cela va me permettre d'initialiser automatiquement le zéro. Les codeurs absolus sont plus imposant il me semble non? Tu as une référence en tête pour voir ça de plus près?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.