Aperçu

Hello Je ne pense pas que ce soit anodin : je vais creuser, mais l'intervention de Jasem ci-dessous laisse entrevoir qu'il va falloir changer nos habitudes https://indilib.org/forum/ekos/16017-ppa-noble-24-04-kstars-bleeding-3-8-2-qt5-broken-after-libstellarsolver-2-8.html Et en effet, tout a disparu : https://launchpad.net/~mutlaqja/+archive/ubuntu/ppa Tout ce qui était dispo sur les versions autres que Resolute / 26.04 a été supprimé, par exemple sur Noble / 24.04 : Là comme ça à chaud ça signifie quoi ? Si je veux faire joujou avec indi sur autre chose que Resolute c'est cuit. Je ne sais pas trop ce qui a motivé ce grand ménage, je suis convaincu qu'il y a de très bonnes raisons. Et si on lit entre les lignes le message de Jasem, ils doivent manquer de temps et/ou de ressources pour continuer à tout maintenir d'un seul bloc. Seulement moi je suis incapable de contribuer à un truc pareil, mais j'aurais bien aimé 🙂 En attendant ça change vachement la donne, la seule option qu'on nous laisse pour garder nos habitudes est de passer sur Resolute, c'est pas rien. Ou alors d'utiliser leur flatpak mais ça j'aime pas trop, en particulier si je ne veux utiliser que la partie serveur sans KStars/Ekos (situation à laquelle je suis confronté directement sur mon projet OST ... bref ...) Je suis preneur de toute suggestion, et j'ai déjà mis mon ami Claude sur le coup. Je vous tiens au jus. A+ Gilles.

Bonjour, Oui c'est possible, cf le chapitre de la doc : https://kstars-docs.kde.org/en/user_manual/ekos-guide.html#dithering Edit: pour la version française : https://kstars-docs.kde.org/fr/user_manual/ekos-guide.html#dithering A+

Bonjour, Je viens d’apprendre un nouveau mot: "dithering"... Question: Dans KStars, y a t-il la possibilité de faire de la dithering pendant la prise de photos pour éviter les pixels chauds ? Merci, JM

J'ai pu me connecter en maintenance avec Jasem. Il a fait un tas de trucs dans un terminal, au final ça fonctionne ! Je peux me connecter avec rustdesk, KSTARS est fonctionnel. Ouf !

Après avoir fait la mise à jour en V2.2.1, ça n'a rien amélioré. Crash de KSTARS, au redémarrage de celui-ci ne peut charger indiserver, pas de connexion avec l'app smartphone. Donc je ne peux même pas me mettre en mode support ! La cata intégrale ! La seule chose qui fonctionne c'est VNC pour les connexions en wifi, internet box ou internet lien local. Rustdesk a fonctionné 2 fois et depuis rien !

J'ai une réponse de Jasem. Je dois lui envoyer les logs.

Salut, @rmor51, as tu essayé de poser la question sur le Discord de Stellarmate? Ils sont assez réactif. ++

Pas de pot, j'ai posé mon problème sur le site et .... Rien ! Je vais insister. .

A part poser la question au support Stellarmate je ne vois pas... Profites en pour leur lister tous tes problème? ils m'ont résolu les miens rapidement... ils prennet la main à distance sur les RPI avec Russtdesk...

Sur le RPI, oui pas de problème. Mais sur le SM PRO ça ne le fait pas ! D'où la question. Y aurait-il une astuce pour démarrer sur un système externe, SSD, clé USB ?

j'ai écrit l'image directement sur un SSD que j'ai branché, j'ai allumé le RPI5 qui a booté dessus je pense que le RPI5 essaie sur ce qui se présente : cartes SD, clé/disque USB,... pour Rustdesk je pense qu'il faut que tu attaque l'ID de la srellarmate directement? celui que le support utilise?

J'ai un "!" sur l'icône réseau. Qu'est-ce que cela veut dire ? En passant dessus j'ai vu fugitivement le mot airport. J'ai activé ce mode et le "!" a disparu. C'est quoi ce mode airport ? Hier, j'ai refais des tests. Avec VNC la connexion s'établit par wifi Par Rustdesk, nada ! Avec des prises CPL en mode lien local, ça fonctionne. Mais globalement le passage à Archlinux me gave ! Y aurait-il moyen de booter sur un SSD externe ou une clé USB ? Je pourrais ainsi démarrer sur un version 1.9 sous Raspbian.

bon finallement ça ne marchait pas parce que dans mon profile j'avais mis locale au lieu de remote... (?) sinon en cas de problèmes on peut lancer la commande : pkill indi puis relancer indi pour le profile et tout est ok...

Merci Patrick.

Salut, D'après la doc INDI c'est indi_celestron_gps. En tout cas le SLT est indiqué ici: https://drivers.indilib.org/mounts/celestron/celestron-gps/celestron-gps/

La question est dans le tire.

Pour le clavier, j'ai rajouté une ligne dans le fichier .bashrc: setxkbmap fr

pour le clavier, une fois connecté en VNC je l'ai configuré ici : Pour les ports ça n'a pas marché... ?

Oyez, Oyez Comme disait l'oncle Sam : "J'ai besoin de vous" Dernière fournée d'amélioration et de corrections. J'arrête de tripatouiller et je ne m'occupe plus que de la doc, qui a pris du sérieux décalage avec les derniers changements : Améliorations Retrait des pixels chauds : réduction de temps de traitement de 75% et prise en compte convenablement des brutes couleurs Changer de profile ne nécessite plus de redémarrer ALS Panneau principal : Nouvel affichage détaillé des infos de session, avec détails sur la brute courante et son alignement Correctifs Changer le chemin du dossier web nécessitait un redémarrage pour prendre effet Il était impossible d'accéder au Bureau sur les systèmes OSX "récents" Le démarrage du serveur d'images bloquait l'interface Je passe pas mal de temps à simuler des sessions avec mes séries de brutes, me mettre dans la peau de l'utilisateur, vraiment. C'est ce qui a amené tous les changements et correctifs des dernières semaines : être facile à utiliser / lire / contrôler. En gardant la qualité en priorité. Les perfs, on le sait, reste un point faible... Mais ALS v2 réglera ça... Dans 4 ans Pour l'heure, si vous voulez bien emmener cette "dernière" version de test de la v1.0 en sortie et me dire... tout ce qui vous passe par la tête, ça m'aidera vraiment à figer les choses avant de refaire les captures d'écran de la doc une 5ème fois, haha Téléchargement version 1.0-dev-946e8898-bld1134: https://als-app.org/nightlies/2026-06-22-946e8898/ La doc, en chantier de la v1.0 : https://preprod.als-app.org/fr/docs/v1.0/ D'avance un grand merci pour le temps que vous pourrez prendre pour qu'ensemble on trouve le dernier bug avant de sortir cette version La bise et bon ciel à tartousses

Je reviens à mes soucis de connexion. Je ne réussi à établir une connexion distante qu'en passant par le réseau de la box et en outre ce doit être la seule connexion opérationnelle. Si une connexion wifi est active en même temps, ça ne fonctionne pas ! Avec une connexion par lien ethernet local, j'ai une erreur 21116. Par ailleurs, que faire pour être en AZERTY dans le teminal ?

J'essaie ça dès que je rentre du pays Basque 😉

Bonjour, Le champ ATTS(serial) sert à distinguer les devices qui ont le même champ idVendorID:idProduct. Dans ton cas le champ serial est en effet le même pour la monture, l'EAF et le GPS, mais pas les champs idVendor:idProduct (10c4:ea60 , 03c3:1f10 et 1546:01a8 respectivement), il est donc possible de faire un mapping. Pour la monture par exemple, quelque chose de ce genre devrait fonctionner : SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0001", MODE="0666", SYMLINK+="EM35Pro" A+

Bon les résultats ne sont pas clairs 🙂 j'ai allumé le RPI 5 avec tous les USB débrancés sauf le disque SSD sur lequel je boot... J'ai fait le "lsusb" puis la commande "udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1" chaque fois que je branchais un port USB... Pour le disque SSD et les 2 cameras ZWO je n'ai pas de résultats pour la commande udevadm... Je suppose que c'est parce qu'ils n'utilisent pas le tty pour communiquer 🙂 Pour la monture EM31 Pro, l'EAF ZWO et le GPS j'ai le même résultat pour tous... lsusb à la fin : Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub Bus 001 Device 003: ID 2109:8888 VIA Labs, Inc. USB Billboard Device Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge Bus 001 Device 005: ID 03c3:1f10 ZWO EFF Bus 001 Device 006: ID 1546:01a8 U-Blox AG [u-blox 8] Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 03c3:178c ZWO ASI178MM Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 04e8:4001 Samsung Electronics Co., Ltd PSSD T7 Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 03c3:585b ZWO ASI585MC EM31Pro : Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge ATTRS{serial}=="0001" ZWO EAF : Bus 001 Device 005: ID 03c3:1f10 ZWO EFF ATTRS{serial}=="0001" GPSD : Bus 001 Device 006: ID 1546:01a8 U-Blox AG [u-blox 8] ATTRS{serial}=="0001" Donc impossible de les mapper...??? J'ai fait la commande " udevadm info -a -n /dev/ttyUSB0 > devices.txt" pour voir si je passais à côyé de qqchose mais je n'y ai trouvé que la monture (?) je mets le fichier en pj... au début j'y ai rajouté le résultat des commandes... Guillaume devices.txt

Merci j'essaie ça dès que je peux! 🙂

Bonjour, Ce problème de connexion se règle en faisant un mapping persistant des ports USB grâce à udev. La méthode est décrite ici : https://indilib.org/support/tutorials/157-persistent-serial-port-mapping.html Plus aucun souci une fois les règles udev sauvegardées 😉 A+