keymlinux

Bonjour, Si ton APN est un Canon alors il y a 44mm entre le capteur et le rebord du boitier ou se plaque l'objectif, et cela tombe bien car la plupart des adaptateurs EOS-T2 font 11mm d'épaisseur. EOS-T2 c'est d'un coté la baïonnette Canon EOS, de l'autre un pas de vis T2, soit du 42mm de diamètre avec un pas de 0.75 Si tu n'a pas un APN Canon et que tu as effectivement une distance capteur au rebord du boitier de 45mm, alors il te reste effectivement 10mm à combler, ce que tu peux faire avec une bague d'adaptation pour ton APN qui fasse 10mm ou moins. Si elle fait moins de 10mm tu comblera la différence avec un lube d'extension de quelques milimetres Cordialement

Bonjour. Il y a un sujet très complet ici:

Bonjour, J'utilise une AZEQ6, principalement en nomade, avec les instruments suivants: - une lunette 80/500 pour astro photo - un C8 pour visuel/photo planétaire - un newton 10pouces, principalement en visuel, un peu en photo Les conditions d'observation à domicile: un balcon mal orienté (nord et est) au 2eme étage d'un appartement en ville en région parisienne, donc avec un ciel orangé... pas les conditions optimales pour observer, mais j'arrive à y faire un peu de planétaire/lunaire/solaire à l'est... Au vu des conditions décrites ci dessus, pour le visuel ciel profond et la photo, c'est déplacement obligatoire, en voiture à environ 60km au sud, 1 heure de route, pour s'installer en bord de champ à la campagne. Cela implique de déplacer systématiquement la monture, le trépied les contrepoids, une batterie 12V (j'ai opté pour une batterie au plomb, mais j'envisage de migrer vers une batterie lithium pour diviser le poids par 2), le tube, les accessoires, et éventuellement chaise + table de camping, en clair l'expedition... Depuis que je fais de l'astrophoto j'ai l'habitude de dire que mon meilleur accessoire astro c'est un diable pliant pour transporter tout le matos. La monture: 15 kg Le trépied: 7.5 kg Les contrepoids: 2x5 kg La batterie: 12 kg La lunette: 7Kg (équipée avec APN, autoguidage en //, focuser électrique, raspberry+hub usb) Pour le reste je suis très satisfait de cette monture (j'image avec un APN Canon, avec des poses de 2 ou 3 minutes avec la lunette de 80mm). Au moment de l'achat j'avais hésité avec une AZEQ5 sa petite soeur (qui a ma connaissance n'est plus vendue en France), pour la photo avec la lunette et le visuel au C8 c'était suffisant, mais comme je comptais aussi y mettre un newton 10" j'ai opté pour l'AZEQ6, et malgré une masse plus importante je ne regrette pas. Le mode azimutal proposé par la monture je ne l'utilise que lors des seances publiques avec le club, c'est pratique pour mettre 2 instruments (lunette + C8) pour montrer au public le même objet avec un champ couvert différent. Cordialement, Stephane

Bonjour, Globalement un telescope inverse l'image (haut/bas ET droite gauche) Avec un renvoi coudé à miroir ou a prisme standard on redresse le haut/bas mais pas le droite/gauche Avec un renvoi coudé a prisme Amici on redresse haut/bas ET gauche/droite, c'est le type de renvoi à privilégier pour l'observation de la nature, et plutôt avec un angle de 45° vu qu'en observation "nature" on observe souvent vers l'horizon ou a faible hauteur Cordialement

Bonjour, Sur le site de la SAF, ils citent en référence le livre "Camille Flammarion" de Ph. de La Cotardière et P. Fuente paru aux editions Flammarion en 1994 https://saf-astronomie.fr/portail-camille-flammarion-biographie/ On peut le trouver en occasion ici https://www.abebooks.fr/9782080666291/Camille-Flammarion-Philippe-Cotardière-Patrick-2080666290/plp note: je n'ai pas lu cet ouvrage, donc je ne peux pas donner d'avis sur le contenu, mais vu que la SAF le cite et que les auteurs sont membres de la SAF, on peux penser qu'il est plus axé sur l'astronomie que sur le spiritisme. Cordialement

Bonjour, Mesa c'est une librairie graphique pour le mode OpenGL. Sous Windows pour faire simple tu as Direct3D ou OpenGL Pour le reste je ne peu pas répondre, d'une part j'utilise Stellarium sous MacOS, d'autre part ta description du problème n'est ps très claire (tu parles de Stellarium et de Nina, mais je ne vois pas bien la relation entre eux...) Cordialement

Pour completer la réponse déjà donnée... En astronomie on parte souvent de filetage M42, pour parler du diamètre du filetage, mais il faut aussi parler du "pas" qui est de 1mm sur le standard M42, mais de 0.75mm sur les équipements astro de diamètre 42mm, et ces bagues sont habituellement vendues sous la denomination bague T2 (et pas M42) Pour les objectifs photographiques, on a bien du filetage M42 (diam 42mm pas 1mm), donc il faut trouver une bague EOS-M42 et habituellement on n'en trouve pas dans les magasins astro (on y trouve des bagues EOS-T2) Sur les APN Canon, les objectifs EF et EF-S ont besoin d'un tirage de 44mm, et on trouve donc sur un APN EOS le capteur qui est enfoncé de 44mm après le rebord du boitier. Pour les objectifs photos M42, il leur faut un tirage optique de 45.5mm, c'est supérieur à 44mm et cela tombe bien, cela veut dire que l'on dispose de 1.5mm pour y interposer une bague d'adaptation EOS-M42 Les appareils Nikon et leur objectifs ont un tirage optique de 46.5mm, donc on ne peut pas juste utiliser une bague simple pour y utiliser un objectif M42 qui lui a besoin de 45.5mm (cet objectif sera trop loin de 1mm, et ne pourra pas faire la mise au point à l'infini), on doit alors utiliser un complement optique, donc une bague qui contient une lentille (cela joue le même rôle que les glasspath que l'on rajoute avec les binoculaires pour faire ressortir le foyer sur nos telescope et compenser la consommation de chemin optique e la bino) EDIT: plus d'infos ici https://www.suaudeau.eu/memo/pratique/Les_montures.html Cordialement

Bonjour, Le passage 32bits à 64 bits trouve souvent sa justification dans la taille de la memoire qui peut être adressée, donc cela se justifie pour 4GB de memoire ou plus. Pour les RPI avec moins de memoire cela peut effectivement se discuter, car notamment la memoire consommée sera plus grande en 64bits (impact négatif), mais cela peut aussi se justifier sur une recherche de performance pour certains traitements spécifiques (impact positif d'utiliser des instructions et des registres memoire 64 bits qui permettent d'effectuer une operation sur 2 fois plus de données pour le même nombre de cycle d'horloge du cpu) voir ici des résultats de bancs sur rpi4 en 32 et 64 bits https://www.phoronix.com/review/raspberrypi-32bit-64bit Et comme le dit @rmor51pour Kstars le support 32bits c'est fini pour les versions après 3.6.0, et comme le sens de l'histoire c'est d'avoir des ordi avec de plus en plus de memoire, donc avec une nécessité de passer au 64 bits, certains developpeurs supprimeront le support de leurs applis en 32bits. A noter qu'avec un OS 64bits on peut généralement quand même lancer des applications 32bits (mais ce n'est plus vrai sur MacOs après la version 10.14 Mojave où le support 32bits a été supprimé)

Vérifie aussi que sur ton APN tu n'as pas activé le mode "relevage du miroir", ce qui pourrait expliquer la prise d'une image sur deux. En mode normal, la prise d'une photo (via le bouton ou intervalometre) provoque: le relevage du miroir puis la prise de photo puis l'abaissement du miroir En mode "relevage du miroir", la 1ere activation du bouton (ou 1er ordre envoyé par l'intervalometre) provoque la monté du miroir, le second ordre de prise de photo (bouton ou intervalomettre provoque la prise de photo + abaissement du miroir Concernant le fait que la led verte signifierait que l'APN est prêt: à ma connaissance l'intervalomètre envoi des ordres de déclenchement à l'APN, mais il n'y a pas de retour d'info, il ne peut pas connaitre l'état de l'APN, et personnellement avec mon intervalometre le laisse 5 seconde entre 2 expositions pour laisser le temps à l'APN d'écrire sur la carte SD Le delay initial, je le laisse à 0 La longueur de l'exposition je met x secondes (souvent 30 secondes) L'intervale, je met le temps de pose (x) + 5 secondes (sur mon intervalometre l'intervalle ce n'est pas le délai entre la fin d'une exposition et le début de la suivante, c'est en fait le délai entre 2 débuts d'expositions !, mais à priori tous les intervalometres ne se comportent pas de la même façon)

Oui, mais je doute que clonecopy aille modifier le contenu du fichier cmdline.txt et du fichier /etc/fstab de la partition linux pour changer le nom des périphérique qui y seraient codés en dur. Si par contre le créateur de l'image SD a utilisé des LABELS ou des UUIDS pour identifier des partitions alors là oui, le clonage sera transparent. Vérifie que l'image nafabox 3.4.0 de ta clé USB, si dans le cmdline.txt il est codé en dur root=/dev/mmcblk0p2, remplace par /dev/sda2 (qui est valable pour une clé usb) et cela devrait booter (restera à corriger le contenu du /etc/fstab) EDIT: Et oui, c'est complexe, mais il existe des scripts tout fait qui s'occupent de toute la mécanique, y compris rendre indépendants des noms de périphériques ... voir par exemple ici: https://www.framboise314.fr/dupliquez-la-carte-sd-de-votre-raspberry-pi-avec-rpi-clone/

Je n'utilise pas (ou plus) les images Nafabox toutes faites, je veux pouvoir choisir ce que j'installe, même si c'est plus de boulot. Lorsque j'utilisait un PI3 pour le Nafabox j'utilisais des images toutes faites, ce n'est plus le cas. Mes problèmes ont commencé lors du passage au PI4, avec des images toutes faites qui étaient incapables de booter de manière fiables sur un PI4 et encore moins de gérer le boot sur USB (disque SSD, pas clé USB...) Donc lors du passage au PI4 je suis passé au mode je choisi ma distrib, je l'installe, et j'installe les scripts Nafabox par dessus pour le post install avec les softs "astro" Il y quelques mois j'ai refait ma distribution Nafabox, j'avais un échec systématique pour upgrader de ubuntu 20.04 à 22.04 avec crash pendant l'upgrade et figé au boot... (et ce n'était pas un problème lié à une corruption de la carte SD vu que je boote sur un disque SSD USB) Mon choix: je part d'une install Ubuntu 22.04 LTS, distrib "Mate" (le download c'est ici: https://ubuntu-mate.org/download/ ) . L'équipe Nafabox préconise une xubuntu (Ubuntu avec Xfce) mais je n'aime pas cette variante... (les goûts, les couleurs...) La technique, pour au passage installer sur le disque USB: - Je copie l'image Ubuntu Mate sur une 1ere carte SD (appelons la carte A) - Je copie l'image Ubuntu Mate sur une 2ere carte SD (appelons la carte - Je boote le raspberry sur la carte A - Je met la carte B dans un lecteur de carte et le connecte en USB au PI - Je connecte mon disque SSD en USB au PI - sur le SSD, je cree des partition à la taille voulue avec "fdisk" o la partition de boot en FAT de 1GB (label=system-boot)(sur les cartes SD elle fait souvent moins de 256MB mais cela commence à être petit o la partition OS ext4 de 64GB (label=writable) o une partition de swap de 8GB (label=swap) (même avec n PI4 avec 4GB de ram, un peu e swap peut être pratique, et en SSD c'est rapide, ne pas faire swap sur une carte SD ou une clé USB au risque de les tuer...) o une partition data sur le reste du disque pour stocker les photos... (label=data)(avec un SSD de 1TB cela laisse de la place...) note: je precise les LABELS car dans le /etc/fstab les partitions sont montées en fonction de leur label, pas en fonction du nom de périphérique, qui varie selon la techno, avec une carte sd on a du /dev/mmcblk0 avec un disque usb on aura du /dev/sda, etc..., et si en plus on utilise une clé usb et un disque USB, leur noms de périphérique va dépendre de l'ordre de connection (/dev/sda pour le premier, /dev/sdb pour le second) Mon /etc/fstab ressemble à cela LABEL=writable / ext4 defaults 0 0 LABEL=system-boot /boot/firmware vfat defaults 0 1 LABEL=data /media/nafabox/data auto defaults 0 0 LABEL=swap none swap defaults 0 0 suite des opérations: - pour la partition FAT, le monte la source, 1ere partition de la carte B, et la destination, 1ere partition du disque USB, dans des répertoires tempo je copie de l'un vers l'autre (commande cpio pour préserver les attribute set dates de motifs des fichiers), et je démonte les deux, cela est pratique pour au passage passer d'une petite partition de 256M à une nouvelle de 1G - Avec la commande "dd" je clone la partition EXT4 de l'OS de la carte B (celle dans le lecteur de carte en USB, donc avec les partitions qui ne sont pas l'OS en cours de fonctionnement) vers le disque USB (on ne clone pas le contenu de la carte A car copier un filesystem monté en cours de modification ce n'est pas fiable, d'où l'utilisation de 2 cartes SD...). On pourrait aussi faire avec du cpio, mais c'est plus efficace avec le "dd", et puis contrairement à une partition fat, une partition ext4 on peut changer sa taille (via resize2fs) - Je redimensionne le contenu du filesystem cloné avec resize2fs pour l' étendre à la taille de la partition de 64GB - ensuite j'enlève les 2 cartes SD, je ne garde que le disque USB et je reboote --> le PI4 boote sur le disque SSD, c'est plus rapide Ensuite je poursuis l'install Nafabox standard, à savoir clone git des scripts, lancement des scripts pour installer les outils astro... En espérant avoir été clair... EDIT: pour ton problème d'image Nafabox toute faite qui ne boot pas (celle de la 3.4.0), vérifie le contenu du fichier cmdline.txt de la partition fat: si il y a quelque chose du style "root=/dev/mmcblk0p2" alors cela explique le pourquoi cela ne boot pas La plupart des personnes bootent leur raspberry sur une carte SD, donc avec la partition fat qui sera /dev/mmcblk0p1 et la partition root linux qui sera /dev/mmcblk0p2. Si tu clone cette image sur une clé USB, le raspberry saura trouver la 1ere partition pour charger le kernel Linux (fichier vmlinux ou vmlinuz) et lire les fichier config.txt et cmdline.txt, ici on a encore pas de linux qui tourne et on se fout des noms de périphérique linux, mais une fois que le kernel linux var démarrer, si on lui explique via le cmdline.txt qu'il doit monter /dev/mmcblk0p2 et bien il ne trouvera pas cette partition, car sur une clé USB cette partition se nomera /dev/sda2 et pas /dev/mmcblkp2 Si on utilise des labels de partitions, comme pour le /etc/fstab on peut aussi les utiliser dans le cmdline.txt, et on écrira: root=LABEL=writable

Bonjour, il semblerait que le package indi-full ne soit plus dispo pour Ubuntu 18.04 bionic dans le repository de Jasem Voir page ce dessous, sur le site tu peux filtrer les packages par distrib (liste déroulante e bouton filtrer au dessus de la liste des packages) . Pour Bionic il y a kstars mais plus indi, les deux sont dispos par contre pour le distrib Focal (20.04) https://launchpad.net/~mutlaqja/+archive/ubuntu/ppa/+index?field.series_filter=bionic

Mon message de 19h44 n'est pas vide, mais je conçois qu'il puisse apparaitre vide pour certains, je soupçonne une facétie informatique, liée à un copier coller depuis une page web, avec des effets de bord liés à la couleur de la police et du fond... Ci dessous je tente de réécrire le contenu, y compris une capture du dit message, tel qu'il m'apparait. Le repository de Jasem pour Indi et Kstars (cela fonctionne pour les distrib Ubuntu, a voir pour Bullseye) sudo add-apt-repository ppa:mutlaqja/ppa sudo apt update Cordialement

Peux tu être plus précis ?

Le repository de Jasem pour Indi et Kstars (cela fonctionne pour les distrib Ubuntu, a voir pour Bullseye) sudo add-apt-repository ppa:mutlaqja/ppa sudo apt update

C'est vrai, mais sur un PI4 avec 4GB de ram ce n'est pas trop gênant (cela peut l'être avec un PI4 2GB) Exact, il n'existe pas de Buster 64bits pour raspberry (mais il en existe des Buster 64bits pour PC, d'où le mélange de ma part...) Bilan, tu va devoir te refaire une image de boot à partir d'une Bullseye 64bits.... 😉

Bonjour, Tu peux télécharger l'Atlas Virtuel des Planètes ici https://www.ap-i.net/avp/fr/start C'est le même duo qui développe l'Atlas Virtuel de la Lune https://www.ap-i.net/avl/fr/start Tu y choisi Mars, et cela présente son aspect en fonction de la date et heure, y compris la phase A priori en ce moment au dessous de la calotte polaire c'est Acidalia Planitia Cordialement

Si tu es content de la distribution Buster que tu utilise actuellement, tu peux aussi reconstruire une image de boot avec une Buster 64bits, ou bien tenter l'installation d'une Bullseye 64 bits. Personnellement je ne suis pas fan des distributions Debian, je préfère les Ubuntu (question de goût). J'ai récemment refait ma Nafabox avec une image Ubuntu 22.04 LTS

Je pense que tu veux plutôt parler du back focus entre le correcteur et le plan focal de l'imageur ? Pour ce qui est du back focus, a priori il n'évolue ps en fonction de la focale de la lulu. Annoncé à 56mm (plus ou moins 4) pour le trf-2008, et pour l'explore scientific, il est fourni avec la bague EOS pour APN Canon, donc back focus fixe (on doit pouvoir y ajouter des cales d'ajustement pour ajouter 1mm entre le correcteur et la bague EOS)

Habituellement les correcteurs ou correcteur-réducteurs "génériques" sont annoncés pour une plage de focale ou de rapport f/d optimum. Par "génériques" j'entend les correcteurs et réducteurs qui ne sont pas annoncés par un constructeur comme spécifiquement conçus pour un modèle de lunette particulier. Pour le TRF-2008 il est annoncé comme utilisable avec des focales entre 400 et 600mm (avec 500mm tu es pile dans) Pour le Hotech, il est annoncé utilisable pour des rapports f/d entre f5 et f8, ici aussi avec un rapport 6.25 tu es pile dedans. Personnellement avec mon Equinox 80/500 (et un capteur aps-c) j'utilise un correcteur-réducteur TRF-2008 (trouvé ici dans le grenier). En correcteur sans reduction j'utilise un Explore Scientific MPCC qui fait le boulot (c'est bien un correcteur pour lunette, ne pas confondre avec le Baader MPCC qui est un correcteur de coma pour Newton) Et concernant ta première question, ce qui m'avais fait éviter le correcteur dédié pour SW ED80 (sous entendu 80/600) c'est justement qu'il était partout annoncé comme spécifique à ce modèle, sans que l'on trouve d'autre information relative à une plage de focale ou rapport f/d compatible (si cette information existe je ne l'ai pas trouvée), et le fait que j'ai trouvé un TRF-2008 a bon tarif en occasion. Cordialement, Stephane

Salut @rmor51. Ta distrib Buster, elle est en 32 bits ou 64 bits ? https://www.indilib.org/forum/ekos/12389-kstars-3-6-1-package-for-raspbian-buster-32bit.html Pour verifier, avec les commandes suivantes: uname -a ou cat /etc/os-release

Ce matin, temps de m.. sur Juvisy, ciel totalement bouché lors de l'immersion, c'est un peu mieux pour l'emersion. Voici quelques photos d'une qualité deplorable (issues d'une video, où j'ai du jouer en permanence avec le gain de la camera pour compenser les sous et sur-expositions liées aux passages nuageux...) Prise de vue au C8 avec camera ASI178 monochrome + filtre UV/IR cut (avec en prime des poussières sur le capteur...) Cordialement, Stephane

Bonjour, Techniquement il est partiellement inexact de dire que la lune tourne autour de la terre, plus précisément les deux (terre et lune) tournent autour de leur barycentre, qui au vu de leur différence de masse est plus proche de la terre que de la lune, même tellement proche qu'il se situe dans l'enveloppe de la terre. Si on considère l'orbite de la terre autour du soleil, la trajectoire elliptique est celle du système terre+lune, donc c'est le barycentre qui a une trajectoire elliptique, la terre elle oscillera légèrement autour. A noter que de la même façon, pour les planètes autour du soleil, il faut aussi considérer le barycentre. Les planète ont une masse très négligeable par rapport du soleil, mais suffisante pour provoquer une oscillation de la position du soleil. Cette oscillation de la position d'une étoile est une technique de detection des exoplanètes Pour la notion de barycentre, et des videos qui décrivent le phénomène, c'est ici https://www.mathweb.fr/euclide/2020/12/23/la-notion-de-barycentre/ Et pour répondre plus simplement à ta question, comme l'a bien dit @Daniel Rosier, lorsque 2 corps massifs tournent l'un autour de l'autre (ou plutôt tournent autour de leur barycentre), le barycentre sera plus proche du plus massif (peu importe la taille, c'est la masse qui compte) et donc observé de l'extérieur on verra le moins massif tourner autour du plus massif Cordialement

Remarque très pertinente (comme souvent Ney 🙂 ), en plus du capteur il faut tenir compte de l'électronique périphérique implémentée dans la camera et surtout du firmware (logiciel embarqué dans la camera), raison pour laquelle j'ai précisé que j'avais une ASI178 de ZWO, rien ne garantie qu'une cam QHY disposant du même capteur ait les mêmes possibilité de ROI Pour le choix de la camera monochrome (versus couleur), le pseudo utilisé (SpectroSolar) me laisse penser que la spectroscopie est l'usage premier visé pour l'achat de cette camera, et là l'usage d'un capteur monochrome se justifie pour le gain en sensibilité et en definition (personnellement l'achat de l'ASI178MM c'est pour un usage spectro avec un SolEx) et pour du planetaire lunaire (oui il y a de la couleur sur la lune, mais en monochrome c'est très bien aussi). Par contre il est vrai que la roue a filtre sur Jupiter c'est compliqué vu sa vitesse de rotation... Cordialement