pch

Wine "pollue" moins qu'une machine virtuelle puisqu'il ne nécessite aucun code de Microsoft, c'est simplement des utilitaires et des librairies Linux qui exportent les même fonctions que celles de Windows.

L'Atlas Virtuel des Planètes est dans le même cas et ne fonctionne plus avec un Linux récent.

Mais aucun risque pour Cartes du Ciel ou CCDciel puisqu'il n'utilisent pas OpenGL.

Patrick

Bonjour Maurice,

Malheureusement nous avons du arrêter de distribuer les versions Mac et Linux à cause du mauvais support des anciennes extension d'OpenGL sur ces systèmes.

C'est pas faute d'avoir chercher puisque je développe le programme sous Linux mais la solution passerait par une réécriture complète de la librairie graphique et je n'ai pas le temps pour ça. (le code est libre si ça intéresse quelqu'un 😉 )

La bonne chose est que le programme fonctionne parfaitement avec Wine, il faut juste regarder la configuration de Wine pour avoir des couleurs et boutons plus jolis que ceux par défaut.  Personnellement j'ai installé le thème Breeze: https://store.kde.org/p/1259774/

Patrick

Oui c'est bien ça, il faudra que je regarde pour mettre mon Eqmod en français

Si il y a toujours un décalage ça serait intéressant d'avoir l'échelle de l'image pour estimer l'a valeur de l'erreur. Car avec ce genre de monture (EQ6 ?) il est difficile de faire mieux que 30" en raison des jeux mécaniques divers.

Inscrit aussi pour profiter du camping. L'an dernier c'était quand même un peu galère de rentrer à la maison tout les soirs ...

Avec Eqmod il faut faire attention comment le nouveau point est utilisé après un Sync.

Par défaut il l'ajoute au modèle de pointage, ce qui fait que son influence est diluée parmi tout les autres points déjà existant.

Avec ça on arrive jamais à une correction optimum avec le plate solving et il vaut mieux changer les options d'Eqmod pour n'utiliser que le point le plus proche.

Dans Eqmod il faut ouvrir le panneau de droite, dans la boite Alignment/Sync faire un clic sur les deux boutons avec une croix rouge pour effacer les données du modèle, puis régler "User interface" à "Dialog based" et "Alignment behavior" à "Nearest point".

Patrick

Je vois vraiment pas pourquoi se casser la tête avec une réinstallation complète pour chaque version alors que la mise à jour d'Ubuntu marche vraiment sans problème.

Perso j'ai pas réinstallé Kubuntu depuis 10 ans et je fais les mises à jour tous les 6 mois.

Dans ce temps le système est passé d'un disque à un SSD et le PC à été complètement changé, sans qu'il soit nécessaire de réinstaller.

Mais bien sure toute règle à ces exceptions

Le problème de FrancoisP avec la mise à jour de Lubuntu est à cause d'un très gros changement dans cette version 20.04: le bureau passe à LXQt. 

L'annonce de Lubuntu 20.04 indique:

Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install.

Ça ne sert donc a rien d'attendre quoi que ce soit et la réinstallation est la seule solution.

On peut retourner la question, pour quelle raison exécuter des programmes astro en administrateur?

En fait aujourd'hui il n'y en a aucune, sauf que si on a commencé c'est difficile de s'en sortir.

Le mode administrateur n'a été utile que quelque temps, il y a 20 à 25 ans, lors du passage de DOS/Windows 3 vers Windows 95 et 98.

Sous DOS/Windows 3 il n'y avait pas de drivers, les programmes écrivait directement à l'adresse du port série ou parallèle pour communiquer avec le télescope ou la caméra. Windows 95 a interdit cela sauf pour l'administrateur. C'est de là que vient la légende "si ça marche pas essaye en administrateur".

Mais depuis Windows XP, il y a 20 ans, ces opérations sont aussi interdites à l'administrateur. Dans tout les cas on est obligé de passer par un driver pour accéder au télescope ou à la caméra.  Je ne parle pas du "driver" ASCOM, qui est en fait une application, mais du driver du port USB ou autre qu'on voit dans le gestionnaire de périphérique.

Donc depuis XP ça ne sert plus a rien de lancer les programmes d'astro en administrateur.

Windows n'est pas forcément mono utilisateur et on ne voudrait pas que d'autres utilisateurs du PC puissent voir ce qu'on est en train de taper dans un traitement de texte. Il y a donc une séparation forte entre les applications des différents utilisateurs.

Comme les drivers ASCOM sont des applications il y a une séparation entre l'utilisateur normal du PC et l'administrateur qui ne vont pas pouvoir utiliser le même driver en même temps.

Par exemple on lance un premier programme en utilisateur normal et on connecte le télescope par le driver ASCOM. Ensuite on lance un second programme, toujours en utilisateur normal, on peut sans problème se connecter au même driver ASCOM qui va gérer le partage du télescope entre les deux applications.

Mais si le premier programme est lancé en administrateur,  quand le second programme exécuté en utilisateur normal essaye de se connecter au même driver ASCOM ça ne marche pas car c'est une instance indépendante qui est exécutée et on reçoit un message d'erreur que le port série est déjà occupé par la première instance.

La solution de facilité est de lancer la seconde application en administrateur et d'en déduire que c'est la solution magique à tout les problèmes informatiques.

Alors que la vraie solution était de faire attention que le premier programme ne se lance pas en administrateur.

Après il y a tout les problèmes que ça pose à cause des droits d'accès sur les répertoires et fichiers créer par une application en administrateur et qu'on ne peut plus accéder avec l'utilisateur normal. Ça peut faire planter l'application car elle ne peut plus accéder à sa configuration.

Remettre droit tout ces fichiers peut être un gros boulot et si le PC n'est utilisé que pour l'observation et n'est jamais connecté au réseau il vaut peut-être mieux continuer de l'utiliser comme ça.

Mais y penser lors de l'installation de son successeur et surtout ne pas conseiller au autres d'utiliser le mode administrateur.

Patrick

Merci Serge.

Ange, il vaut mieux ne rien exécuter en administrateur, ça marche la même chose et c'est beaucoup moins dangereux.

Des fois ça donne un peu de boulot pour revenir à un mode d’exécution normal non administrateur car il faut corriger ce qui a été cassé par ce mode.

Le mieux est de ne jamais rien lancer en administrateur.

Patrick

Non, on ne peut pas le faire pour l'impression.

Uniquement à l'écran en créant plusieurs cartes comme sur cette très vielle copie d'écran.

L'erreur 0x800A0037 signifie qu'un fichier est déjà ouvert et donc il ne peut pas être réutilisé. Excuse moi mais j'avais pas remarqué que tu mentionne l’erreur 55 dans ton premier message, c'est un peu la même chose.

Avec EQMOD ça vient souvent d'un fichier de configuration pourri.

Il faut effacer toute la configuration d'EQMOD.

Voir ici: https://www.pierro-astro.com/images/fichiers/FichePratiqueEQMODErreur55.pdf 

Ce message dit qu'Eqmod ne s'est pas enregistré dans ASCOM. En général ça indique que le registre d'ASCOM est tout pourri.

Il faut désinstaller tout ce qui concerne ASCOM, la plateforme et tous les drivers surtout tout ce qui concerne Eqmod.

Ensuite télécharge, dézip et exécute le programme RemoveAscom en bas de la page https://github.com/ASCOMInitiative/ASCOMPlatform/releases/tag/Build_2695

Puis redémarre le PC, installe la plateforme ASCOM 6.4sp1.

Et ensuite la dernière version Eqascom V200q depuis https://sourceforge.net/projects/eq-mod/files/EQASCOM/

Je peux te confirmer qu'Alpaca est quelque chose d’intéressant et qui marche bien.

Ça fait un petit moment que j'ai ajouté le support natif d'Alpaca dans Cartes du Ciel et CCDciel.

Comme ça on peut utiliser des périphériques connectés en ASCOM à une machine Windows depuis l'application qui tourne sous Linux ou Mac ou encore en Windows à Windows en remote. Avec CCDciel tu peux avoir une partie des périphériques connecté par INDI et une partie par Alpaca. Pourquoi pas si ça permet d'utiliser du matériel qui n'a pas de pilote INDI.

Mais on peut aussi faire des pilotes natif sous Linux, c'est juste du HTTP/JSON. Il y a du monde qui commence à faire des pilotes Alpaca en python sur RPi pour du matos maison.

Personnellement je l'ai fait pour mon ancien pilote d'encodeur que je ne voulais plus voir directement dans Cartes du Ciel. C'était pas facile d'en faire un pilote INDI puisqu'il est codé en Pascal qui ne peut pas être linker avec du C++ (c'est un des intérêts d'Indigo qui est en C). Donc maintenant c'est un pilote Alpaca qui peut tourner sur Linux, Mac ou Windows: https://github.com/pchev/alpaca_encoder/wiki

Concernant la licence Indigo on s'est déjà bien engueulé avec Peter donc je vais pas recommencer. Je pense qu'il vaut mieux se poser la question est-ce qu'on tient plus à Indigo ou à la GPL? C'est pas la mort de publier du code en BSD ou MIT et c'est compatible avec Indigo. Mais c'est compliqué pour un projet existant de changer de licence.

Oui, la protection des applications commerciales et de leur publication sur l'Apple store est une des motivations principale du développement d'Indigo.

Mais il y a en plus la volonté d'exclure toute application GPL. C'est fait par le point 5 de la licence qui autrement est une bête BSD: https://github.com/indigo-astronomy/indigo/blob/master/LICENSE.md

Cette close non-commerciale, même si elle apparaît très limitée, est totalement incompatible et t'empêche d'utiliser du code Indigo dans une application GPL. Entre autre le code client qui est nécessaire pour profiter des avantages d'Indigo.

Bien sur ça n'empêche pas de se connecter à un serveur Indigo depuis une application GPL en utilisant le protocole INDI. Mais dans ce cas tous les avantages relatifs d'Indigo sont ignorés.

il y a 23 minutes, rmor51 a dit :

Mais Indi c'est aussi pire, le développeur ne veut pas qu'on touche à son code d'après ce que je crois savoir.

Ah bon??? sur la page github de Indi il y a 110 contributeurs différent pour le projet et personnellement les quelques patch que j'ai envoyé ont toujours été pris en compte.

C'est un peu le problème avec Indigo qui est open-source mais pas libre, le développeur principal ayant volontairement pondu une licence incompatible avec la GPL.

Tout ça est bien dommage car techniquement il y a des très bonnes choses dans Indigo.

Merci pour l'image.

Pour que ça marche il faut changer le signe de CDELT2, CROTA1, CROTA2.

En plus avec Siril v0.99.1 il ajoute une matrice CD qui est bien pratique. Ça vaudrait la peine d'avoir une nouvelle version compilée pour Windows.

Salut,

CdC lit les fits a l'endroit, la première ligne est en bas de l'image.

Je viens d'essayer avec une de mes images en PNG, astrométrie par Siril du ppa, sauvegrade en fits et affichage dans CdC et ça correspond parfaitement a la carte.

Est-ce que c'est possible de mettre le fits sur un site quelque par pour qu'on puisse le télécharger pour voir?

Il ne faut pas utiliser en même temps le simulateur avec une monture réelle. Ça ne peut pas marcher car le simulateur de camera n'a pas d'interaction avec la monture donc les étoiles ne bougent pas.

Pour s'amuser avec PHD2 en intérieur il faut choisir Camera=Simulator et Monture=On-camera. Mais en aucun cas ça permet de tester le matériel.

Si tu as le même message avec une vraie monture et caméra c'est un tout autre problème, soit avec les câbles,  les réglages du driver de la monture ou les réglages de PHD2.

Avec EQmod c'est important de faire les réglages recommandés ici: https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings

Quand je le fait sur mon HEQ5, je bouge l'axe de déclinaison à la main en faisant des petit aller-retour, on sent très bien le jeu de la vis. Il faut arrêter de serrer dès qu'on ne sent plus le jeu.

Il faut surtout pas trop serrer car ça fait avancer l'axe par à-coup, pour le guidage c'est encore pire que le jeu .

Ce réglage est le même quand tu as des courroies car elles sont entre le moteur et la vis sans fin. Ce jeu est entre la vis sans fin et la couronne dentée de l'axe.

Oui n'importe quel logiciel peut guider avec un gros jeux en déclinaison, mais seulement si les corrections sont toujours dans le même sens ou si il n'y a pas besoin de correction en déclinaison ...

Pour guider toujours dans le même sens il suffit une erreur d’alignement polaire de 5 minutes.

Si par contre ça oscille entre nord et sud et que tu vois des corrections qui semblent corriger la position c'est probablement que l’alignement polaire est bon mais que l'axe de déclinaison ne bouge pas du tout, c'est simplement les fluctuations du seeing qui bougent l'étoiles autours de la position moyenne.  Si tu es dans ce cas tu peux en être sur en coupant le guidage en déclinaison, choisir Off pour "Mode de guidage Dec" et vérifier que ça dérive pas plus qu'avec le guidage.

Mais pour un bon guidage dans toutes les situations il faut que l'axe de déclinaison réponde rapidement aux changements de direction. Et pour ça la seule solution c'est de régler la position de la vis sans fin sur la monture.

La différence que tu observe maintenant est probablement du a la température plus basse qui rend le jeux plus important.

Pour l'EQ6 il y a des info sur la page suivante. Tu dois probablement trouver les deux mêmes petites vis opposée sur l'EQ6R.

http://www.astro-baby.com/EQ6 rebuild guide/EQ6 worm alignment.htm

Le lien est en bas de la page de téléchargement:

https://www.ap-i.net/skychart/fr/download#images

Commence par contrôler la version d'INDI que tu utilise. Dans un terminal entre indiserver sans paramètre ça va afficher la version. La dernière est 1.8.3.

Ensuite pour revenir aux valeurs par défaut du driver, ferme kstar et indiserver, va dans le répertoire ~/.indi  il doit y avoir deux fichiers "ASI EAF_config.xml" et "ASI EAF_config.xml.default" ou quelque chose de similaire. Efface les.

Pour tester le fonctionnement de base ouvre le "Panneau de contrôle INDI", a l'onglet du focuser clic Connecter, attend que les autres contrôles apparaissent.

Entre 100 dans le champ "Position absolue" et clic Définir.  Est-ce que le moteur bouge? est-ce que le champ de gauche passe à 100?

Je ne connais pas du tout l'EAF mais je viens de jeter un coup d'oeil au code source.

L'erreur 5 ça veux dire: EAF_ERROR_MOVING,//focuser is moving

Le driver croit que le focuser est en cours de déplacement et c'est pour ça qu'il refuse de modifier reverse et max position.

C'est aussi pour ça que ça va mieux après Interrompre car il doit faire un reset de "focuser is moving"

Ce qui est bizarre c'est la corrélation des sursauts en RA et DEC et le fait que dans la fenêtre "Cible"  tous les mouvements sont en diagonale.

Ces sursauts sont dus à une cause externe au logiciel et ça ne sert a rien d'essayer de changer des paramètres. Je trouve même que le programme se débrouille plutôt bien pour ramener l'étoiles après ces sursauts.

Pour sur c'est un problème mécanique, mais c'est difficile de dire quoi sans être a côté du télescope.

Regarde par exemple si la lunette guide ne flotte pas dans son support, ou la caméra dans le porte oculaire, ou un câble trop tendu qui fait bouger le tout.

Ça peut être quelque chose de très faible, avec 200mm de focale un mouvement de 10" c'est environ 1/100 de millimètre.

Je peux te répondre pour CdC.

La valeur des magnitudes disponibles pour une étoile donnée dépend en effet de la bande passante ou la mesure est faite.

Ce qui est affiché dans CdC dépend bien sur des mesures disponible dans le catalogue d'origine mais j'essaye toujours d'ajouter une valeur de V ou approchant ainsi qu'un indice de couleur.

Par exemple pour GAIA DR2 on peut voir en cliquant sur un étoile:

Magnitude G: 12.798

Magnitude BP: 13.084

Magnitude RP: 12.362

Magnitude visuelle: 12.91

Indice de couleur B-V: 0.56

Les valeurs de G, BP et RP sont les magnitudes mesurée directement par GAIA dans la bande passante de ses instruments.

La magnitude V et l'indice de couleur B-V sont calculé en utilisant les formules données dans la documentation de GAIA.

La même chose est faite pour les étoiles brillantes avec Hipparcos et la comparaison avec GAIA marche assez bien malgré qu'a la base les mesures sont différentes.

Hipparcos : V=7.59 B-V: 1.005

GAIADR2 : V=7.58 B-V: 0.99

Mais si pour la même étoile on regarde la magnitude Vt de Tycho on a 7.69 car Vt n'est pas exactement égal à V. 

Le GSC donne 7.43 et USNO-B  R=7.0 et B=8.7. Il s'agit de magnitude photographique très imprécises et a peu près impossible a ramener a un système standard. Il faut vraiment se méfier des magnitudes de ces anciens catalogues photographiques.

J'oubliais un truc, la référence pour les magnitudes est l'APASS fait par l'AAVSO mais malheureusement pas encore disponible en version définitive.

Pour l'étoile ci-dessus il donne V=7.566 et B-V=1.003. Ca donne une idée de la précision des transformations depuis GAIA et Hipparcos mais bien sur à condition que l'étoile ne soit ni très rouge ni très bleue.

Patrick