keymlinux

Bonjour, Belle progression, et puis comme cela cela te fait une version avec la supernova 2023ixf et une sans... 🙂 J'ai 2 questions: - pour la mise au point, tu utilises un masque de bahtinov ou bien c'est au jugé avec le live view ? (et du coup Siril te donne quoi comme FWHM pour tes brutes ?) - quand tu dis qu'il y a 20% d'image rejetée, c'est toi qui le a exclues manuellement après visualisation ?, cela me semble dommage de les exclure totalement. Je dis cela car moi je laisse les photos avec passage de satellite (sinon c'est plus de 50% que je dois jeter sur des poses de 120s ou 180s), et je compte sur l'algorithme de rejection de Siril pour éliminer ces trainées qui par definition ne se trouvent pas sur toutes les images. (mais ne suis pas sûr que mon choix soit le meilleur...) Cordialement

Bonjour, Sur le fond, oui cela existe, voir ici https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-t2/bague-adaptatrice-t2-vers-m48_detail Sur la forme je partage l'avis de @schizophrene Cordialement, Stéphane

@JMDSommeBonjour. Tu ne precise pas si tu utilises un Windows version 10 ou 11, ni si tu utilise l'option "liens" au lieu de copier de fichiers des options de Sirilic Si tu utilise les liens, sous windows cela implique d'activer un mode développeur que la mise à jour windows a certainement changé. Tu devrais essayer: - de changer l'option "utilisation de liens symboliques" dans Sirilic (la désactiver) - si tu souhaite garder cette option, il faudrait réactiver l'option mode développer de windows (je ne peut pas te dire comment, je suis sous MacOS) Et si rien ne marche, abandonne Windows et passe sous linux ou MacOs Cordialement

Bonjour. Concernant la diffusion des chaines TV, de nombreux paramètres entrent en ligne de compte, et pa seulement le temps d'un aller/retour vers l'orbite géostationnaire. Le passage au numérique avec les temps de traitement liés à l'encodage/compression à la source, et le décodage/décompression à la destination entraine de nombreux délais additionnels. Quelques infos ici https://www.lesnumeriques.com/disque-dur-multimedia/decalage-tv-et-latence-comment-ne-plus-voir-les-buts-en-retard-lors-des-matchs-de-foot-a191723.html EDIT: je cite ce site juste pour info, parce que personnellement je n'aime pas le foot, alors le décalage des buts je n'en ai rien a f...

Bonjour, Ta lunette de visée de chasse dispose de 2 anneaux de support qui ont normalement une base de serrage au format "picatinny" de 21mm de largeur C'est aussi ce format qui est utilisé pour les chercheurs point rouge que l'on utilise en astro, il il existe des adaptateurs entre ce format "picatinny" et le format "mini-vixen" utilisé pour les chercheurs sur nos lunettes/telescopes exemple ici (je n'ai pas le lien avec Pierro, on trouve ce genre d'accessoires sur autres sites astro): https://www.pierro-astro.com/materiel-astronomique/accessoires-optiques/chercheurs/pied-metal-pour-viseur-point-rouge_detail Important: habituellement ta lunette est fixée sur un fusil avec 2 anneaux, mais sur l'adaptateur de chercheur de ton telescope tu ne pourra en utiliser qu'un, donc vu la longueur de ta lunette de visée la rigidité de la visée va être compromise...

Si on a droit à un léger hors sujet, alors je présente la photo suivante, prise le 19 juillet 2020 vers 5h, juste un peu avant le lever de soleil. Après une nuit astrophoto j'étais en voiture sur le chemin du retour pour aller me coucher, en voyant le croissant de lune je décide de me garer et d'immortaliser la scène.. Canon 80D + Sigma 105mm ouvert à f2.8, pose de 1/60sec 5400iso

Oui, avec l'altitude et la limpidité de l'air qui va avec cela aide. Mais je n'ai jamais réussi à faire de photos de ciel étoilé en avion, et comme toi je reste dubitatif sur certaines photos "astro" prises depuis des hublots d'avion que l'on trouve sur le net. Une petite dernière, prise soleil couchant, mais le vrai objectif c'était la comète Néowise, pas le ciel du soleil couchant... Canon 80D + objectif Sigma 30mm ouvert à 2.8, pose unique de 4 secondes à 800iso, juillet 2020

J'en ait quelques uns aussi... Au bord des étangs, à Draveil (91) (avec en prime une petite lune sur l'une des photos....) Prises depuis un avion Cordialement

@m27trognondepomme j'ai trouvé un contournement dans le fichier "callbacks.py" de sirilic, ligne 886 en remplaçant result = subprocess.run( editor+" "+ script, capture_output=True, text=True ) par result = subprocess.run( editor+" "+ script, capture_output=True, text=True , shell=True ) note: je n'ai pas trouvé tout seul, voir ici https://github.com/pyinstaller/pyinstaller/issues/4859 MacOs c'est que du bonheur... 😉 note: cela fonctionne avec ou sans le chemin complet pour la commande "open" donc ce n'était pas un problème d'env PATH

@m27trognondepomme 1) Cela ne fonctionne pas (voir ci dessous la log). Je suspecte un problème d'environnement PATH pour les commandes lancées par python, il faudrait tester en utilisant le chemin complet de la commande "open" /usr/bin/open -a TextEdit /path/file.ext au lieu de open -a TextEdit EDIT: testé, cela ne fonctionne pas non plus en mettant le chemin complet. En fait je pense que cela viens du fait que l'on demande à python de lancer la commande "/usr/bin/open -a TextEdit /path/file.ext", alors qu'en fait dans la commande il ne devrait y avoir que "/usr/bin/open" et le reste "-a TextEdit /path/file.ext" devrais être mis dans le tableau des arguments de la commande La log: Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/sirilic/lib/callbacks.py", line 120, in <lambda> i_gui.Bind(wx.EVT_MENU, lambda evt: self.CB_run(evt,True), id=gui.myID_EDIT_RUN ) File "/usr/local/lib/python3.10/site-packages/sirilic/lib/callbacks.py", line 886, in CB_run result = subprocess.run( editor+" "+ script, capture_output=True, text=True ) File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 503, in run with Popen(*popenargs, **kwargs) as process: File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 971, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 1847, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'open -a TextEdit /Users/stephane/Pictures/Siril/script/sirilic.ssf' 2) autre problème qui n'a rien à voir avec l'edit. Suite à la modification du paramètre "pixelsize" pour la commande "setfindstar", on peut désormais le saisir avec 2 digits après la virgule, mais dans le fichier projet il est enregistré arrondi avec 1 digit seulement (mon 3.75 deviens 3.8)

Sur MacOS c'est TextEdit. Pour ouvrir un fichier avec il faut lancer la commande "open" en spécifiant l'application "TextEdit" ex: open -a TextEdit /path/file.ext Si on essaie de lancer la commande avec son chemin complet de binaire pour ouvrir un fichier (comme on le ferait avec "vi") cela ne fonctionne pas ex: /Applications/TextEdit.app/Contents/MacOS/TextEdit /path/file.ext Cordialement

Bonjour @m27trognondepommej'ai fait différents tests avec la version 1.15.2xx1, cela me semble OK. Merci. Concernant l'ajout d'un éventuel bouton edit&run, je suis pour. Il y a bien la possibilité d'afficher le script (ce qui le génère sur disque), pour ensuite éditer avant lancement manuel avec siril en ligne de commande, mais un bouton edit&run permettrait d'éviter de se taper la ligne de commande. Cordialement, Stéphane

Bonjour, Effectivement ce logiciel est compilé uniquement pour Windows, mais personnellement je l'utilise sous MacOs (10.14 Mojave) en le lançant via Wine (qui existe aussi sous Linux). Cela me permet aussi de lancer L'Atlas Virtuel de la Lune, Registax, Autostakkert, etc... Oui, il fait cette simulation en 2D, pas en 3D Coelix n'est pas très coûteux, et c'est vraiment un soft avec plein de fonctionnalités, mais plutôt calcul d'éphémérides et modélisation 2D (pour tracer des cartes du ciel entre autres). Une des rares modélisations 3D (perspective) disponible dans le soft, c'est par exemple de modéliser la trajectoire d'une comète dans le système solaire (il y e a quelques autres) L'orbite de Venus est effectivement un peu inclinée par rapport au plan de l'écliptique (3.4° environ). Si toutes les planètes étaient strictement dans le même plan, on aurait pour Mercure et Venus des transits beaucoup plus souvent. Pour la modélisation en 3D du système solaire il faut utiliser des logiciels comme Celestia (gratuit et nativement multi OS) https://celestia.space Cordialement

Bonjour, La fente du Solex fait 4,5mm de hauteur. L'image projetée du soleil au foyer de la lunette (donc sur la fente) fait environ focale/100mm de diamètre (approximation). Donc pour avoir le soleil en entier il faut se limiter à une focale entre 420 et 450mm (avec un peu de marge) Personnellement j'ai une lulu 80/500, mais avec le réducteur x0,8 j'ai le soleil en entier, par contre je diaphragme l'entrée du tube pour remonter le rapport f/d à 7. Christian explique cela dans les derniers paragraphes de la page suivante http://www.astrosurf.com/solex/sol-ex-theorie.html Et comme vous j'ai fait en impression 3D un support pour le filtre ND, et qui me sert aussi à faire varier le diamètre d'ouverture pour ajuster le rapport FD. @Discret68tes filetages imprimés sont superbes. Le bouchon porte filtre pour la lulu Avec le capuchon pour protéger le filtre La vue coté intérieur avec les bagues empilables pour faire varier le diamètre d'ouverture (mais cela ne rend pas bien en noir...) Une vue globale du montage avec lulu et solex Cordialement

Bonjour, 1) L'élongation solaire de Venus (angle entre Venus et le Soleil, vus depuis la Terre), est actuellement de près de 38°, et va continuer à croitre jusqu'au 6 juin pour atteindre 45,34° 2) ci dessous l'emplacement de la Terre et de Venus sur leurs orbites respectives autour du Soleil à la date du jour (à noter que le Soleil, Mercure et Venus sont à peu près alignés, mais ce n'es pas l'objet du sujet) 3) La même chose pour le 6 juin (le max de l'elongation sera en fait le 4 juin) A cette date Venus sera a peu près au sommet d'un triangle isocèle rectangle (distance Terre-Venus égale à la distance Venus-Soleil, et vus de Venus la Terre et le Soleil seront à une distance angulaire de 90° environ) EDIT 3) ensuite, après le 6 juin et jusqu'au 13 août l'élongation solaire de Venus va décroître jusqu'a 0° (où venus passera entre la Terre et le Soleil) 4) Puis augmentera jusqu'au 24 novembre pour une élongation max de 46°, mais en novembre cela nous paraitre peut être moins spectaculaire car les journées seront plus courtes, et cette fois ci les observations devrons se faire le matin et pas le soir (Venus se lever avant le Soleil) note: ces schémas sont obtenus avec le logiciel Coelix EDIT 2: Et pour répondre précisent aux questions... a) quel est l'écart maximal entre Vénus et le Soleil --> toujours autour de 45° (pas exactement 45° car les orbites sont des orbites elliptiques et pas circulaires) b) en degrés d'élévation (hauteur --> les planètes ont à peu près leur orbite dans le plan de l'écliptique (je rappelle que Pluton n'est PAS ou plus une planète), donc leur élévation, comme celle du soleil sera maximale au solstice d'été, fin juin (or on va avoir une elongation max Venus Soleil le 6 juin, donc on est proche du meilleur des cas...) c) en temps (durée maxi de coucher de Vénus après le coucher du Soleil) --> vu que dans ces cas l'élongation max est proche de 45°, et comme la Terre tourne sur elle même d'environ 15° par heure, on a un max autour de 3 heures... d) Et ça arrive souvent, un si fort « décalage » on aura juin et octobre 2023, puis janvier et juin 2025 on connaît l'orbite de la Terre et celle de Venus, un matheux vas bien nous calculer la périodicité, mais là je déclare forfait... La table ci dessous générée par le logiciel Coelix, pour les elongations max de Venus et Mercure sur les 36 prochains mois Plus grandes Èlongations de Mercure et de VÈnus Les temps sont donnÈs en heure normale pour Juvisy (2∞ 22' 19" E, 48∞ 41' 30" N, zone A). Cliquez dans une cellule donnant l'heure pour voir le phÈnomËne ‡ ce moment. Date Heure PlanËte …longation A. D. DÈcl. Const. Lever Passage Coucher aaaa mm jj hh:mm ∞ gÈocentrique gÈocentrique hh:mm hh:mm hh:mm 2023 04 11 18:00 Mercure 19,3∞ E 2h 30m 11,1s +17∞ 38' 45" Ari 06:35 14:02 21:31 2023 05 29 06:00 Mercure 24,7∞ O 2h 46m 22,0s +12∞ 21' 21" Ari 04:10 11:11 18:13 2023 06 04 18:00 VÈnus 45,3∞ E 8h 7m 34,0s +22∞ 48' 42" Cnc 08:08 16:06 00:06 2023 08 10 00:00 Mercure 27,4∞ E 11h 0m 10,2s +4∞ 35' 19" Leo 08:15 14:37 20:59 2023 09 22 12:00 Mercure 17,8∞ O 10h 52m 25,5s +8∞ 3' 31" Leo 04:58 11:39 18:19 2023 10 24 00:00 VÈnus 46,4∞ O 11h 0m 18,3s +6∞ 12' 34" Leo 03:11 09:43 16:13 2023 12 04 18:00 Mercure 21,2∞ E 18h 15m 13,0s -25∞ 35' 52" Sgr 10:21 14:12 18:04 2024 01 12 18:00 Mercure 23,5∞ O 17h 53m 38,1s -21∞ 50' 53" Sgr 07:02 11:17 15:32 2024 03 24 18:00 Mercure 18,6∞ E 1h 21m 52,9s +11∞ 11' 8" Psc 07:08 14:02 20:57 2024 05 09 18:00 Mercure 26,2∞ O 1h 31m 8,7s +6∞ 9' 23" Psc 04:39 11:10 17:41 2024 07 22 06:00 Mercure 26,9∞ E 9h 54m 50,7s +11∞ 42' 37" Leo 07:46 14:43 21:39 2024 09 05 06:00 Mercure 18,1∞ O 9h 49m 31,3s +13∞ 13' 1" Leo 04:36 11:41 18:46 2024 11 16 12:00 Mercure 22,4∞ E 17h 2m 18,3s -25∞ 25' 17" Oph 10:16 14:09 18:02 2024 12 25 06:00 Mercure 22,0∞ O 16h 42m 52,2s -20∞ 11' 15" Oph 06:52 11:17 15:41 2025 01 10 12:00 VÈnus 47,2∞ E 22h 38m 10,9s -9∞ 18' 18" Aqr 10:48 16:08 21:29 2025 03 08 00:00 Mercure 18,2∞ E 0h 18m 20,4s +3∞ 57' 39" Psc 07:43 14:05 20:28 2025 04 21 18:00 Mercure 27,3∞ O 0h 20m 38,6s -0∞ 28' 34" Psc 05:11 11:11 17:12 2025 06 01 00:00 VÈnus 45,8∞ O 1h 35m 23,8s +7∞ 38' 18" Psc 03:09 09:47 16:26 2025 07 04 06:00 Mercure 25,9∞ E 8h 43m 23,5s +18∞ 8' 40" Cnc 07:13 14:44 22:13 2025 08 19 12:00 Mercure 18,6∞ O 8h 41m 23,9s +17∞ 23' 58" Cnc 04:13 11:40 19:07 2025 10 30 00:00 Mercure 23,7∞ E 15h 50m 46,2s -23∞ 3' 17" Sco 10:00 14:07 18:14 2025 12 08 00:00 Mercure 20,6∞ O 15h 34m 56,1s -16∞ 52' 45" Lib 06:36 11:18 15:59 2026 02 19 18:00 Mercure 18,1∞ E 23h 18m 14,2s -3∞ 12' 56" Aqr 08:23 14:10 19:59

@m27trognondepommeMerci pour ta réactivité. La correction permet bien l'ajout de la commande "setfindstar" dans le script, mais les paramètres ne sont pas les bon La ligne ajoutée est setfindstar 1.0 0.5 -layer=0 Ce qui génère une erreur la syntaxe devrait être setfindstar -sigma=1.0 -roundness=0.5 -layer=0 En fait cela devrait même être la ligne suivante vu que dans les options disponibles dans l'interface j'ai changé les valeurs pour la focale (modifiée de 0 à 500) et la taille de pixel (modifié de 0 à 3.7) setfindstar -sigma=1.0 -roundness=0.5 -layer=0 -focal=500 -pixelsize=3.7 EDIT (pas de dysfonctionnement, juste une demande d'amélioration): 1) dans le script généré, il serait bien d'insérer une commande "setfindstar" sans paramètres juste avant le register, comme cela cela farsait apparaitre dans la log d'execution les valeurs de paramètre en vigueur 2) concernant le paramètre de taille de pixel pour le setfindstar, il faudrait pouvoir saisir 2 digit apr!ès la virgule, actuellement l'interface limite à 1 digit Cordialement

@m27trognondepommeBonsoir, je confirme c'es OK pour les fichiers compressés et le drizzle. Par contre nouveau problème, dans l'onglet "propriétés", sous onglet "plus de propriétés", si je coche l'option "Détection d'étoiles" alors dans le script généré après la generation des masters dark/flat il manque les commandes register et stack Ci joint mon fichier projet et le script généré. A priori entre "#TAG#} [3]" et "#TAG#{ [4] ... Terminé ..." il manque des choses sirilic.ssfM81_M82_test.prj

Bonjour, - Dans la doc de la 294MC il est indiqué qu'il est préconisé d'utiliser une alimentation 12V 5A, mais dans les fait tu ne consommera jamais 5A, si on observe la courbe de consommation en fonction du refroidissement choisi on plafonne à 1.8A (peltier+ventilateur, sans la resistance chauffante anti buée), mais même avec l'anti-buée je ne pense pas que cela consomme au total plus que 2.5A sous 12V - Pour la 120mini, elles est alimentée en 5V via un port USB 2.0 (donc conso max 0.5A sous 5V), donc théorique max 2.5W (la doc indique une consommation réelle max de 1.85W) donc sur du 12V on sera à moins de 0.2A - Si par auto focuser tu parles de l'EAF, il est annoncé pour une consommation max de 0.5A en 12V Donc a mon avis avec une alimentation 12V 7.5A c'est largement suffisant Cordialement

Absolument, car en gardant les lights et DOF, on peut refaire les traitements et post traitements donc si on doit garder quelque chose ce sont bien les images sorties de l'APN/CAMERA-> du temps pour refaire les traitements informatique on peut en trouver, alors que refaire des captures c'est plus compliqué (surtout si on vit dans une coin avec une meteo aléatoire) Et éventuellement on peut faire du multi session si on reviens sur un même objet l'année suivante...

Bonjour, La problématique et les outils associés ne seront pas la même selon que l'on image avec un APN (raw/jpeg) ou avec une camera dédié astro (fits) (sans parler de ceux qui font de la capture video en planétaire) Comme toi pour les photos non astro j'utilise Lightroom pour cataloguer (et aussi pour importer et renommer les fichiers), avec des mots clés (puis je fais un grand usage des collections dynamiques) Pour la partie astro: 1) Au debut j'utilisais mon APN Canon avec soit un intevalometre filaire, soit via EOS Utility J'avais donc import des RAW+JPEG via lightroom, + mise en place de mots clés (CP/planetaire, nom de l'objet, type light/dark/bias/flat, etc...) Je garde les fichiers raw+jpeg, le résultat d'empilement siril (pas les fichiers intermédiaires) avant et après post-traitement (donc plusieurs si j'ai tenté plusieurs post-traitements). A noter que j'utilise l'option de compression sans perte des fits. 2) maintenant j'utilise kstars/ekos/indi pour piloter mes prises de vues, cela implique que EKOS m'enregistre les images en format FIT sur le disque dur du raspberry (avec infos d'astrométrie), mais sur la carte SD de ll'APN je conserve les RAW (pas les jpeg car le driver INDI les désactive) Pour les RAW je les catalogues via Lightroom comme pour le point 1) Pour les fits, non gérables dans lightroom, je les stockes dans une autre arborescence du type objet cible/ date session/[light|dark|flat|bias]/fichier exemple: M42/20230227a/light/M42_light_180s_800iso_001.fit Donc ici je garde les raw et les fit même si cela peut sembler faire double usage. Ici aussi je garde le resultats d'empilement de Siril et les tentatives de post-traitement 3) Dans le futur j'envisage de passer à une camera astro refroidie, je n'aurais donc lus les raw/jpeg à gérer, seulement les fits, et je resterais sur mon workflow utilisé pour les fit au point 2) Pour ce qui du problème de la volumétrie, oui tout cela prend de la place, j'utilise un NAS pour stocker les photos (et il se réplique sur un autre NAS à l'autre bout de la France(hébergé dans la famille 🙂 ) Je pense que le vrai problème de volumétrie c'et pour ceux qui font du CP pose courte avec plusieurs centaines voir millier d'images pour une session (moi perso une session c'est max 200 images DOF compris, avec es lots et darks variant de 120s à 300s selon les cibles), ou bien du CP avec CAM mono où les lights sont multipliées par le nombre de filtres, ou bien ceux qui font du planétaire avec des vidéos à forte cadence d'image EDIT: - pour les fits je n'utilise pas d'outil de catalogage, cela repose juste sur une organisation en "répertoires" de stockage - par contre pour leur visualisation j'utilise ASIFitsView (la suite logicielle ASIStudio est téléchargeable gratuitement sur le site de ZWO), et Siril - Une fois que je suis satisfait par mes traitements Siril, j'exporte en TIFF, je fais éventuellement un peu de retouche via GIMP sur les TIFF, puis enregistrement des versions finales en TIFF aussi, et ces TIFF sont catalogués dans LightRoom Cordialement, Stephane

Bonjour, Il faut rajouter la ligne suivante au debut de tes scripts Il me semble que c'était déjà obligatoire avec les versions 1.0.x requires 1.0.0 Edit: je viens de regarder dans le fichier de log que tu fournis, il est fait pour les versions SiriL 0.9, il faut mettre à jour les scripts Voir la doc ici https://siril.readthedocs.io/fr/latest/Scripts.html Cordialement

Bonjour, La nature nous offre des spectacles magnifiques C'est une belle prise, il y l'arc principal et l'arc secondaire, séparés pas une zone plus sombre appelée bande d'Alexandre Voir explications ici: https://fr.wikipedia.org/wiki/Arc-en-ciel Ci dessous, arc en ciel photographié en octobre 2021 depuis mon balcon Dommage pour le pilier au milieu du panoramique... Cordialement, Stéphane

Bonjour, Tout d'abord, malgré la trame, je trouve ton image superbe. Avec le guidage on veut éviter le "bougé" pendant les poses. Avec le dithering on veut générer un "bougé" entre les poses. Le problème c'est que si tu guide d'une part avec PHD et que tu prend les poses d'autre part avec un autre soft (Shutter ou EOS utility), alors le problème c'est: comment générer un bougé entre les poses que le guidage n'interprétera pas comme une erreur soudaine de suivi à corriger ? Avec le couple EOS Utility PHD il y a la possibilité d 'utiliser PHDMax comme le precise @krotdebouk. J'ai aussi commencé avec EosUtility + PHD , mais je n'ai pas utilisé personnellement PHDMax, car j'utilisais un MacBook sous MacOs, PHDMax et purement Windows et ms tentatives de le faire fonctionner avec Wine ont échoué... Si on utilise un un logiciel intégré qui prend les poses et fait le guidage et le dithering alors cela résoudra le problème, il suspendra le guidage pendant le dithering. Personnellement je suis passé à Kstars/Ekos cela gère la prise de vue, la mise au point motorisée, le guidage (avec dithering), et l'astrométrie, et en plus cela tourne sur une config minimale (un petit raspberry). Le macbook ne me sert d'en debut et fin de seance pour contrôler la session. C'est important en usage remote où l'autonomie électrique est un problème. Possibilité à tester: vu qu'il n'est pas nécessaire de faire du dithering à chaque pose, tu peux essayer de suspendre le guidage toutes les 5 ou 10 poses, puis déplacer légèrement le pointage en utilisant la raquette en donnant une courte impulsion (dans une direction différente à chaque fois), puis reprendre le guidage. Mais cela t'oblige à rester à coté du setup (et c'est galère de faire à la main ce que des softs font plus efficacement)

Bonjour, Cela me semble être une bonne alternative, avec un prix "mesuré" pour le package total. https://all3dp.com/2/rock-pi-vs-raspberry-pi-difference/ Par contre attention, le site de vente OKdo est en Angleterre, il faut ajouter la TVA en France (ceci étant on devrais alors payer le prix HT en Angleterre...) Le même kit est disponible sur la Zone à 193 euros (177 si on passe par un vendeur tier) Même à 193 euros pour le pack complet cela reste concurrentiel par rapport à un pi4 "nu" à plus de 200 euros... EDIT: 2 remarques 1) A priori il y a un site pour la france et un pour UK (choix en bas de page à droite) et a priori ils précisent que si on ne dépasse pas 180 euros sur la commande c'est bien du TTC pour nous sans frais additionnels 2) Le pack complet à 142 euros il est bien, mais pour l'usage que l'on cherche (seance astro nomade avec alimentation à base de batterie), les cables HDMI et l'alimentation on s'en fout. En fait ce dont on a besoin c'est d'une carte Rock 4C+, les radiateurs, le boitier et la carte SD, alors autant faire l'acquisition d'une carte nue à 80 euros sur le site OKdo, et pour le reste on se débrouille (d'ailleurs le Rock 4 C+ et le Raspberry PI 4 peuvent utiliser le même boitier !) Histoire d'être en totale contradiction avec mon message precedent, je crois que je ne vas pas attendre la baisse de prix du rpi4 et que je vais me laisser tenter par un rock 4 C+ et passer commande.... 🙂