Bonjour NicoAstro, Cool, si tu ou vous traduisez la donc en fr! Je suis très mauvais en anglais! 😉 JM

- AstroBerry (le meilleur je pense) Pour info j'ai commencé à traduire en Français la page du Wiki, je vous invite à y participer pour faire avancer ce projet : https://www.astroberry.io/docs/index.php?title=Astroberry_Server/fr - Easy Astro Box (à l'air très bon, j'attends une carte SD pour le tester) - StellarMate - AstroPI3 - NafaBox - ASIAir (payant & uniquement pour matériel ZWO je crois)

Il y a le clone d'indi (je retrouve plus le nom). -> je viens de retrouver : indigo. Astropi3 faut le compiler. astroberry, il y a un ppa.

Tiens, je ne connaissais l'AstroPI3... Résumons... il y a: -La NafaBox -L'AstroBerry -L'Easy Astro Box -L'AstroPI3 Y en a t-il d'autres dans la liste ?? JM

Bonjour, Il me semble que tu en avais déjà parlé. Ca à l'air intéressant. Perso, j'ai une astropi3 (un peu modifiée à ma sauce) et une astroberry (2 cartes différentes). Je les trouve très bien toutes les 2. Sur un rpi4 4GB.

Bonjour, Vous connaissez le projet Easy Astro Box ? http://www.easyastrobox.com Un autre projet RPI pour l'astro! JM

Salut jgricourt, Très intéressant même si cela ne fonctionne pas sur AstroBerry... Sinon tout va bien... je me suis fait un script perso avec de menu bash ;-) Vlc ne veut pas non-plus lire les mjpg sur AstroBerry... j'ai donc utilisé omxplayer par l’intermédiaire d'un fichier fifo... sinon ça fonctionne pas non-plus! Voilou, JM

J'ai trouvé un truc intéressant : https://www.crackedthecode.co/how-to-use-your-dslr-as-a-webcam-in-linux https://medium.com/nerdery/dslr-webcam-setup-for-linux-9b6d1b79ae22 C'est une méthode simple sous Linux pour rendre disponible le flux vidéo de la caméra sous forme d'un device (comme une webcam), l’intérêt c'est que n’importe quel application peut maintenant le lire et surtout on peut développer des applications sans se préoccuper de la nature du flux vidéo capturé., bon je crois pas que cela te fera avancer mais vue que j'ai passé un peu de temps à comprendre tout ça ... Pour rappel ce que tu fais : $ gphoto2 --set-config-value eoszoom=0 --capture-movie --stdout | vlc - Donc : gphoto2 [écrit sur stdout le flux au format motionjpeg] -> vlc [affiche la vidéo] Ce qui est proposé ici : $ gphoto2 --stdout --capture-movie | ffmpeg -i - -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video0 Donc : gphoto2 [écrit sur stdout le flux au format motionjpeg] -> ffmpeg [converti le flux reçu au format rawvideo] -> v4l2loopback [récupère le flux et le rend dispo sous forme d'un périphériques vidéo dans le système] Aussi en annexe l'usage de v4l2loopback avec un simple fichier vidéo en source pour comprendre comment ça marche : https://debian-facile.org/doc:multimedia:v4l2loopback Attention aussi aux ports utilisés : Pour savoir lesquels $ gphoto2 --auto-detect Et ensuite rajouter par exemple --port=usb:002,004 (ou ce qu'il conviendra) dans la ligne de commande de création de stream gphoto2

Ça c'est con... un pb de câble USB! 😉 LoL JM

Justement une interface graphique peut te cacher tout ça ! J'aurai bien tenté de coder un liveview dans un premier temps mais je n'ai pas le cable USB de mon Nikon ...

C'est un peu compliqué la ligne de commande... trouver les bonnes commandes... surtout quand tu fais une sortie astro... Alors qu'avec une interface graphique... clic, clic, tu règles le temps d’exposition, les ISO... c'est cool, c'est interactif! Sinon j'ai quelques scripts gphoto... mais bon, c'est moyen... lancer le bon script... l'écrire dans un terminal... c'est moyen, moyen en sortie astro! Tiens regarde 2 scripts qui capturent la vidéo avec vlc: $ cat bin/gphoto2--capture-movie-zoom1X-2vlc.sh #!/bin/sh gphoto2 --set-config-value eoszoom=0 --capture-movie --stdout | vlc - $ $ $ cat bin/gphoto2--capture-movie-zoom5X-2vlc.sh #!/bin/sh gphoto2 --set-config-value eoszoom=5 --capture-movie --stdout | vlc - JM

C'est toute la beauté d'une interface, de ce que j'ai lu du code source sur le site du projet, gphoto est une interface qui permet de s'abstraire des spécificités des cameras supportées, on invoque seulement des commandes universelles après je n'ai pas l’expérience de l'usage de gphoto (je découvre avec ce post). - voir en zoom x1 x5 x10 comme tu voudra c'est une fonction du logiciel de l'interface graphique pas de gphoto donc c'est facile à coder. - changer le tp et les ISO ça c'est une fonction de gphoto piloté par l'interface graphique alors soit par un appel à gphoto en ligne de commmande (le plus facile) soit par intégration de la lib c de gphoto dans le code (le plus compliqué). On peut aussi imaginer une interface web dans laquelle on verrait le liveview et d'où l'on pourrait contrôler la camera ... depuis n'importe où du moment qu'on est sur le réseau internet (pc, smartphone, tablette etc). Tu veux dire quoi par c'est pas du tout itératif ???

Ah... tu veux ré-encoder une interface ! 😉 Mais bon... même en QT4 c'est suffisent... parce qu'à parement c'est pas QT qui est en cause... Et puis, je suis partie sur AstroBerry... dans l'idéal ce serait pour AstroBerry avec du QT4 donc! Ce que j'ai besoin de eos-movrec, c'est de voir la vidéo en zoom 1x et 5x... et de pouvoir changer le temps d'exposition et les ISO... Alors effectivement, c'est réalisable en ligne de commande, mais c'est pas du tout itératif! Et je me dis, que cela ne doit pas être aussi évidant que ça à coder, car chaque APN a sa liste de commandes! Mais bon, si le cœur t'en dit, je ne t'arrête pas! 😉 JM

En fait qu'est ce que tu as besoin de faire que te permet eos-movrec ? Je pense que tu peux le faire directement avec gphoto en ligne de commande et si tu veux une interface graphique c'est pas compliqué je peux en coder une en QT 5.

Bon... y a des trucs cool et des moins cool 😉 Ce qui est cool, c'est j'ai appris que pour gérer la dépendance à QT4, il suffisait d'installer le paquet libqt4-dev... Du coup j'ai pu l'installer sur l'AstroBerry... Car au départ j'installai le paquet qt-sdk pour gérer la dépendance QT4, ce qui me faisait planter totalement l'AstroBarry au redémarrage. Ce qui est moins cool... c'est que eos-movrec refuse de fonctionner... En fait eos-movrec compile jusqu'au bout... Il s’exécute... il affiche une image figée de l'APN (dommage!)... y a les menus ISO et temps d'exposition qui fonctionnent... mais eos-movrec et bien planté... et pour l’arrêter, il faut le killer... et ce, sur la dernière Ubuntu 64bits (en fait LUbuntu) ou sur l'AstroBerry apparemment 32bits, sur lequel gphoto2 n'a pas de bug comme sur Ubuntu! Donc voila, si vous avez la soluce ? JM

Salut, je voulais savoir quelles étaient les meilleures solutions logicielles pour faire du planétaire sur un rpi4. Sous linux, j'avais déjà fait des essais avec Oacapture ou planetary imager, mais j'avais pas réussi à les installer il y a quelques mois sur mon rpi. Faut dire que j'avais pas trop insisté, trop pris par le ciel profond. Mais prévoyant des soirées de visuel assisté cet été, je trouverais trop bête de ne pas proposer en direct la vision de Juju ou Saturne. Et comme Kstars n'est pas franchement user friendly en planétaire, je cherche une alternative... Qu'est-ce que vous me conseilleriez ?

Ok j'ai compris comment ça marche en fait l'outil se sert de gphoto comme interface pour commander l'APN. La liste des caméras supportées : http://www.gphoto.org/proj/libgphoto2/support.php mais c'est pas des masses quand même pour ce qui est des appareil de moins de 5 ans. La lib ptp propose aussi un support : http://libptp.sourceforge.net Après chaque constructeur propose sa solution, peut être qu'ils proposent aussi de lancer des commandes ...

Oui... les deux fichiers ouvre le contenu de l'APN dans le gestionnaire de fichier... ce qui a pour effet de locker l'APN... Mais apparemment chez Ubuntu ils ont une solution plus radicale: http://doc.ubuntu-fr.org/gphoto#installation Non, je ne sais pas, et je sais pas comment le vérifier! Gphoto2 prend en compte un grand nombre d'appareil Nikon: $ gphoto2 --list-cameras | grep -i nikon « Nikon 1 (WLAN) » (test) « Nikon CoolPix 100 » « Nikon Coolpix 2000 (PTP mode) » « Nikon Coolpix 2100 (PTP mode) » « Nikon CoolPix 2100 (Sierra Mode) » « Nikon Coolpix 2200 (PTP mode) » « Nikon Coolpix 2200v1.1 (PTP mode) » « Nikon Coolpix 2500 (PTP mode) » « Nikon CoolPix 2500 (Sierra Mode) » « Nikon CoolPix 300 » « Nikon Coolpix 3100 (PTP mode) » « Nikon Coolpix 3200 (PTP mode) » « Nikon Coolpix 3500 (PTP mode) » ... JM

Donc tu as juste retiré les droit d’exécution sur 2 fichiers ... et l'outil de capture fonctionne maintenant ? J'ai pas vérifié mais est ce que tu sais si l'outil repose sur le SDK officiel de Canon ? https://github.com/Blackdread/canon-sdk-java/blob/master/doc/dll_path.png Je n'ai pas d'appareil Canon chez moi car je suis équipé Nikon mais je me dis que ça pourrait être intéressant de développer une solution qui inclurait les 2 marques après si les logiciels existent déjà ça vaut pas la peine

Bonjour jgricourt, Si je m'en suis sortie... cela dépend de ce que l'on appelle sent sortir! ;-) À vrais dire... l'utilitaire gphoto2 est buggé... pour que gphoto2 fonctionne il faut faire: $ sudo chmod -x /usr/lib/gvfs/gvfs-gphoto2-volume-monitor $ sudo chmod -x /usr/lib/gvfs/gvfsd-gphoto2 comme expliqué ici: https://github.com/gphoto/libgphoto2/issues/297 Et je me suis dit, que si gphoto2 est buggé, c'est certainement normal que eos-movrec ne fonctionne pas correctement! Du coup, j'en suis resté là! Voilou, JM

Alors tu t'en es sorti ?

Pour démontrer quoi ?? Puisque l'AstroBerry fonctionne! Puis je veux bien les histoires des 32bits et des 64bits... en attendant l'AstroBerry fonctionne et pas la NafaBox... Ça sert à rien que la NafaBox soit 64bits si elle ne fonctionne pas! Après y en a qui font des fixettes sur les problèmes amenés par les hotspots sur la NafaBox... moi je suis pas du tout convaincu. D'ailleurs le Wifi fige le temps de l'utilisation de la EQ6 ou de l'APN... puis, après cela refonctionne (si je peux intervenir en direct sur la NafaBox)... et c'est pas une déconnexion, reconnexion du Wifi qui le fige... sinon cela se verrait! Quoi qu'il en soit... c'est bizarre... et je peux plus tester la NafaBox car j'ai reformaté ma carte sd pour y installer l'AstroBerry! JM

Hé si 😉 https://docs.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases Pour tes problèmes de Wifi installe d'abord une version de Raspberry Pi OS, vérifie que ton Wifi fonctionne. Puis installe Ekos/indi https://indilib.org/download/raspberry-pi.html

Hotspot et wifi c'est forcément lié puisque l'un utilise l'autre. Je pense que si Astroberry exploite correctement le wifi c'est que ce dernier n'est pas pollué par des démons qui pourraient en perturber le fonctionnement. Hors ces démons sont installés par les scripts NAFABox pour gérer le hotspot donc polluent le fonctionnement du wifi. Ta monture, ton appareil photo font circuler les infos via le réseau wifi du périphérique vers le RPi4 puis vers ton PC de contrôle et réciproquement. Si un des éléments de la chaîne de communication merde les signaux échangés sont soit perdus soit bloqués et ce de manière assez aléatoire. Et ce que le hotspot soit sur ton téléphone ou le RPi4. Si cela ne vient pas de là, je ne vois plus que la version d'Ubuntu qui sert de socle à NAFABox qui pourrait en être responsable.

Bon bien j'ai l'utilitaire gphoto2 qui ne fonctionne pas... pas la peine de chercher plus loin! JM