FalCT60

Dans le cas présent, c'est le sens de la phrase associé à la règle de la concordance des temps qui imposent un futur simple. D'ailleurs, la tournure «Si il y a...» est totalement fausse : une condition impose un imparfait - c'est d'ailleurs sa définition. Donc «S'il y avait...» suivi de «il y aurait...». À notre époque, nous apprenions cela en première année de cours moyen.

Très joli poisson. Si, si. 🤣 Il fallait y penser.

Bonjour, Afin de fixer divers petits accessoires sur mon train optique, j'ai entrepris la création d'une sorte de caisson qui se fixerait autour de la webcam et de la bague de fixation à l'objectif. En deux demi-coquilles et munie d'une série de rails tous les 30 degrés, afin de pouvoir y attacher lesdits accessoires. Les deux rails supérieur et inférieur servent également de verrous. Je me suis ensuite demandé s'il ne serait pas plus judicieux de prévoir des ouïes d'aération pour la caméra, qui n'est pas refroidie. D'autant plus que j'ai dernièrement acquis un petit module de refroidissement à fixer à l'arrière de la caméra. Sur la représentation ci-dessous, de g. à d. : gris cendre : la bague intermédiaire de fixation à l'objectif, gris sombre : la bague de fixation de la caméra, rouge : la caméra et bleu : le module de refroidissement. Le tout assemblé dans le caisson vu en coupe donne ça : La turbine du module est bien dégagée à l'extérieur. Lors de mes tests, module simplement posé sur la caméra, j'ai noté une condensation non négligeable. Cela représente-t-il un risque pour le matériel dans ma conception telle qu’actuellement ? Des évidements entre les rails de fixation, autour de la caméra, sont-ils ou non utiles ou indispensables ? Merci pour vos retours et conseils avisés.

Bonsoir, J'ai acquis voilà quelques jours ce modèle-ci (à un bien meilleur tarif, heureusement, sacrée augmentation en moins d'un mois !). Testé en intérieur, juste posé sur la 183MC attachée à un objectif posé au sol à la verticale. Il a fallu environ une trentaine de minutes pour que la température descende d'une dizaine de degrés. Effet collatéral : l'ASI transpirait pas mal, du coup je n'ose imaginer ce qu'il en serait dans des conditions réelle, à l'extérieur. Il a tenu un peu plus de trois heures avec un accu d'environ 24 Wh 5V.

Finalement, pas besoin de me prendre le chou avec un GPS supplémentaire : contrairement à ce qu'il m'avait semblé (peut-être mauvaise manip de ma part), je peux ne me servir de la raquette que pour actionner les axes RA/ Déc et laisser l'application gérer le reste. Inutile dans ce cas de paramétrer la raquette. Ça fait un peu cher de boutons directionnels, mais en tout cas ça me convient.

Je précise : le problème de l'emballement est antérieur à l'achat de la raquette et ne se produit qu'avec l'application mobile. Par ailleurs, dans mon cas ce n'est pas le Goto qui est capricieux, mais le déplacement via les touches fléchées de l'application (pour centrage de l'objet, par exemple). Pilotée depuis la raquette, la monture se comporte parfaitement bien.

Merci @schizophrene, je n'avais absolument pas fait attention, mais effectivement on voit qu'il n'y a que deux fils de câblés. Et je suppose qu'il doit y avoir de l'électronique pour diriger tout ça. @macfly51, la saisie ne prend certes que quelques secondes, mais elle est source d'erreur, comme tout ce qui est manuel. Je ne pratique pas suffisamment souvent, d'une session à l'autre il se trouve toujours quelque chose que je fais de travers ou que j'oublie, de nature à me gâcher la soirée. Je suis passé voilà un an de la Star Adventurer à la GTI, et de l'APN à la caméra. Depuis, entre mes propres conneries et les défaillances en tous genres, j'ai dû me ruiner une vingtaine de soirées - soit la totalité de celles qu'il m'a été possible d'effectuer. Pour une raison que j'ignore, lorsque j'utilise l'application mobile pour piloter la monture, cette dernière se met soudainement à se déplacer indéfiniment jusqu'à ce que je la coupe électriquement. L'alignement sur trois étoiles qui devrait ne me prendre que quatre à cinq minutes au pire en arrive à me faire perdre plus d'une heure. J'ai donc investi 200€ supplémentaires dans la raquette, sans prendre garde que le port pour GPS n'a rien de standard. Enfin, disons dans ce qui se fait de standard actuellement. Devoir rallonger de plus de 200€ de nouveau pour un bidule qui se trouve à moins de 30 me ferait bien mal (le GPS lui-même est muni d'une micro-DIN, il est donc nécessaire d'acheter également l'adaptateur micro-DIN/RJ11) J'ai dû tomber sur un autre article, là je viens d'en voir un complet pour 165€. Et il ne m'est a priori pas possible d'utiliser la raquette uniquement pour actionner la monture, tout en continuant d'utiliser l'application mobile. Volià... 😞

Bonjour, Sujet très intéressant, étayé d'explications très détaillées. Malheureusement, les liens sont morts pour la plupart, ce qui empêche de suivre et de bien comprendre certaines choses. En particulier, le site d'@Argonothe me renvoie vers une jolie page d'erreur. Après avoir parcouru ce fil relatif à l'alimentation nomade de bout en bout, je me trouve dans la nécessité de recommencer, sans en avoir réellement le courage, juste pour m'assurer d'un point. J'ai bien compris que la meilleure stratégie consiste à partir d'une tension de 24 V qui sera ensuite abaissée à celle nécessaire aux équipements : nP6S, le BMS kivabien, et le ou les abaisseurs. J'ai lu également qu'il est possible moyennant l'utilisation de diodes spécifiques, de mettre en parallèle des blocs entiers ainsi constitués, tel que l'a fait @Daube-sonne. Mais je ne me rappelle pas voir lu s'il est possible de mettre en série deux blocs ayant chacun son BMS. Je clarifie : j'ai des BMS pour trois éléments que j'aimerais pouvoir utiliser plutôt que de devoir racheter un BMS pour six éléments. Ils sont donnés pour 20A, donc j'imagine qu'en limitant à 6P3S je ne prendrai pas de risque. Un truc du genre 2S(6P3S) est-il faisable simplement ? Merci d'avance,

Bonjour, Je possède un capteur GPS muni d'une prise USB mâle dans ce genre que j'aimerais pouvoir utiliser avec ma raquette Synscan. Après pas mal d'heures de recherches je n'ai pas trouvé grand'chose de probant, hormis peut-être cet adaptateur. Même si le prix est dérisoire, j'aimerais éviter un (autre) achat inutile. Ce bidule est-il, à votre avis, apte à me permettre d'utiliser mon GPS avec la Synscan ? Avez-vous connaissance d'autres adaptateurs plus à même de remplir cette fonction ? Merci d'avance,

Pour conclure et passer ce sujet en Résolu : un traitement sur la séquence dure plus longtemps que sur une seule image, en plus de générer un flux bien visible dans la console (lorsqu'elle n'est pas masquée par la boîte de dialogue).

Aïe ! aïe ! aïe ! tout est donc à mettre au cabinet, comme le disait ce cher Alceste. Le pire - cela m'est revenu dans la matinée - c'est que j'avais déjà lu cette page, et qu'à l'époque je me suis assuré que les deux valeurs en question correspondaient, n'ayant rien trouvé indiquant le contraire. Et d'ailleurs, si je clique sur le bouton Default, ce sont bien ces valeurs-là qui sont rétablies. Par curiosité, j'ai calculé WB_B x median G / median B ainsi que WB_R x median G / median R, et j'obtiens deux valeurs très proches de 50 : 50,059 et 50,079. Donc, oui, 50 pour les deux, ainsi que tu me l'indiquais. N'en demeure pas moins que le fait que les calculs donnent des valeurs différentes de 64 me perturbe toujours autant. L'une des raisons pour lesquelles je souhaite m'affranchir de l'obligation de faire les bias, ce sont des latences inexpliquées qui font planter mon système au bout de quelques images pour des poses inférieures à la seconde. Encore merci pour tout cet accompagnement.

Je ne suis décidément pas doué pour les recherches. Mais cela signifie que ce ne sont pas que les bias et dark qui sont affectés, contrairement à ce que j'avais cru comprendre, mais aussi les light, non ? Donc le résultat final du prétraitement devrait être cohérent et bien rattrapé par la balance effectuée lors de l'étalonnage des couleurs, non ?

Merci. Mais encore faudrait-il pour cela que le problème du pilote fût réglé. Sinon, je vais toujours me retrouver avec des valeurs faussées.😭

Alors, là, heureusement que je suis assis, sinon j'en serais tombé de cul par terre ! Je pensais que @lock042 déconnait, avec son histoire de balance, tant il était impensable pour moi que quelque chose pût être fait dans ce sens. Quant à m'en rendre compte par moi-même, j'aurais pu relire des millions de fois ce passage la doc que ça ne m'aurait même pas effleuré - pour la même raison que précédemment. Et, de toute façon, chaque fois je me suis arrêté à la vue de la série d'équations, sans même chercher à la déchiffrer ni aller au-delà. Trop complexe pour moi. Puis-je la jouer optimiste - j'ai juste à refaire les dark et je pourrai sauver les quelques sessions que j'ai effectuées depuis quelques temps - ou bien tout « est simplement bon à mettre au cabinet » ? J'ai évoqué EKOS, mais si j'ai bien compris c'est INDI qui se charge du pilotage au niveau profond, et EKOS gère la couche superficielle. Je vais donc devoir effectuer un signalement auprès des développeurs - ils vont être contents : ce n'est pas le premier dysfonctionnement que je leur signale. À croire que je n'utilise pas de la même manière que les autres. 😇 Pour le reste, je vais opter pour un offset de 15 au lieu de 13, toujours au gain 120, et utiliser 1024 en tant que valeur de calibration. Merci pour ton aide précieuse.

Bonjour, Dans ma quête de compréhension, j'ai voulu voir ce que ça donne avec un autre logiciel, dans un autre environnement. Petite rectification, tout d'abord : ce sont 9 bias que j'ai faits hier, de 10 à 50 et gain 120, mais je n'ai pas utilisé le premier pour les statistiques. Il y est à présent inclus. J'ai fait de même avec NINA, sous w10. Un peu galère, car je ne connais pas du tout ce logiciel. J'ai donc dû modifier l'offset entre chaque prise et déconnecter / reconnecter la caméra pour que ce soit pris en compte. Siril m'a analysé tout ce petit monde et m'a sorti les données qui m'ont totalement désarçonné tant elles sont différentes de celles obtenues précédemment.😱 Toujours aussi incohérentes, apparemment, mais néanmoins différentes. Je donne ici le lien wetransfer vers les fichiers issus d'EKOS et de NINA, en plus de la feuille de calcul jointe à la publication. Pour ma part, je n'y comprends plus rien du tout. Je me suis lancé dans quelque chose qui me dépasse totalement.😭 -=-=-=-=-=-=-=-= Edit =-=-=-=-=-=-=-=- Rectificatif : après avoir généré le graphe, les valeurs retournées par NINA semblent au contraire très cohérentes et montrent une progression quasi-linéaire de +320 entre chaque pallier, en plus de se situer à mi-chemin entre le min et le max.. offset.ods

Désolé @jDef, j'avais totalement raté ton intervention. Et j'aurais mieux fait de ne pas m'en rendre compte. J'ai déjà eu mal à la tête avec les explications de @Cissou8, mais les tiennes furent le coup de grâce.

Je sais qu'il m'arrive d'être distrait, et lorsque quelque chose ne va pas je considère que c'est forcément l'ICC qui déraille. Mes fichiers ont été générés avec la 183 fixée sur un objectif bouché que j'ai eu la flemme de sortir du sac. J'ai juste légèrement entrouvert la fermeture pour connecter le câble USB. Le logiciel de prise de vues est Stellarmate OS 2.6.60 qui fait tourner Kstars-Ekos 3.6.6 sur un rPI 4B/8Go. J'ai programmé dix séquences à 0,000032s au gain 120 en variant l'offset - et lui seul - de 5 à 50. J'ai transféré les images pour analyser sous Siril et, au vu des résultats, me suis longtemps demandé : «Mais c'est quoi ce binz ?» J'ai refait 8 bias ce soir, de 15 à 50, en utilisant la version tablette de Stellarmate, et j'obtiens rigoureusement les mêmes valeurs sorties de Siril. Je ne pense pas qu'un quelconque réglage inopportun soit venu mettre le souk, et je suis un peu moins inquiet quant à mes aptitudes. Mais toujours aussi perplexe quant aux résultats.

Merci @Cissou8 pour tes explications détaillées. J'avoue que j'ai toujours un peu de mal à comprendre certaines choses, ce qui peut parfois me conduire à faire totalement l'opposé de ce qu'il faudrait. J'espère toutefois n'avoir pas été con au point de rater les bias !

Effectivement, si ça doit tout déglinguer, mieux vaut éviter. Merci pour la précision.

Bonjour, Petit retour sur ce sujet que je croyais avoir parfaitement compris, mais là d'un coup je suis pris de sérieux doutes. Utilisateur d'une ASI183MC classique, j'ai pris l'habitude de renseigner la valeur ADU utilisée lors de l’acquisition en tant que master offset. Et, comme j'aime bien me compliquer l'existence, j'ai voulu couper un peu plus les cheveux en quatre. On ne se refait pas. J'ai repotassé le tuto sur le sujet, puis j'ai pris dix bias de 5 à 50. J'ai déjà dit que je suis un CCQ. Un convert offset suivi d'un seqstat offset offset.csv basic plus tard, j'ai mon tableau. Petite parenthèse rapide : ne serait-il pas possible de faire en sorte que Siril tienne compte des paramètres régionaux ? Il me sauvegarde les données avec des points au lieu de virgules. Fin de la parenthèse. J'ai donc mon tableau de valeurs dans lequel, après remplacement des points par des virgules, seule la colonne median m'intéresse ; et comme il s'agit d'entiers inutile de se compliquer (tiens, c'est moi qui écris cela ?) avec les median16. Cette courbe montre une progression apparemment linéaire, et si j'effectue le rapport median/offset j'obtiens des valeurs groupées entre 67 et 74 - exception faite de la première valeur à 83 qui se singularise. Pour pousser un peu plus la curiosité, la colonne Progrès indique le pas entre deux paliers avec, là aussi, des valeurs quasi-homogènes. Le capteur est censé être 12 bits (sauf erreur de ma part) pour lequel le tuto stipule qu'il faut utiliser un facteur 16. Au gain 120 que j'utilise, l'offset déterminé de façon empirique avec Sharpcap est 13. Et 120 est actuellement la valeur que j'indique en tant que master offset. Néanmoins, si à présent j'utilise 64*$OFFSET, je vais me retrouver avec une valeur de 832 et non plus de 120. Valeur qui, par ailleurs, serait bien cohérente avec les mesures effectuées, et en tout cas bien à sa place entre 736 et 1064, resp. offset 10 et 15. J'ai voulu voir si cela induisait un quelconque changement entre un prétraitement avec 120 ou 64x$OFFSET et n'ai rien remarqué qui semble anormal ni flagrant. Soit je ne sais pas regarder, soit ce ne sera visible que dans certaines conditions, par exemple de forts écarts thermiques, étant donné que ma caméra n'est pas refroidie. Quoi qu'il en soit, si je me suis planté, merci de me dire où, et pourquoi. Et j'espère que ça permettra d'éviter à d'autres de commettre les mêmes erreurs. ASI183MCnc.ods

Mauvaise nouvelle : il m'est à présent (depuis hier, en fait) impossible de reproduire ce comportement.😨 J'ai d'abord fait comme suggéré sans que cela ne se produise. Du coup, j'ai tout effacé et suis reparti du début : même chose. 🤔 Nouvelle purge des fichiers, redémarrage de Siril... rebelote : aucun problème lors de la sauvegarde. M'énerve ! 😠 Purge, fermeture de Siril, redémarrage du système : toujours aucun problème. Se moque vraiment de moi ! 🤬 Puis je me suis rappelé qu'entre mon dernier passage ici et mes nouveaux tests une màj du système a eu lieu. N'ayant pas plus que quiconque par ici ni le don de clairvoyance ni boule de cristal, je crains que ce mystère n'en demeure à jamais un.

Testé à l'instant depuis le site d'origine : aucun problème. C'est donc ton AV qui délire. Par contre, si tu l'as téléchargé à partir d'une autre source, de celles qui rajoutent leurs adwares aux paquets, c'est une autre histoire. Toujours préférer le site de l'éditeur - et se méfier des contrefaçons.

Bonsoir, Pas très sûr que mon approche soit très pertinente, mais de manière empirique j'ai opté pour 0,5 et ça ne semble pas trop mal. Mais c'est vrai que j'aimerais bien pouvoir déterminer la valeur à appliquer en fonction des cas.

Bonsoir, Non, strictement rien. Je me rends compte que ça part en vrille lorsque je tente de sauvegarder le résultat après le starnet. Je n'ai aucune raison de sauvegarder avant d'avoir joué avec les curseurs. Si je repartais du stade avant le starnet et, une fois celui-ci terminé, avant d'effectuer quoi que ce soit d'autre, ouvrais l'explorateur de fichiers et voir si c'est le starnet lui-même ou les ajustements sur le résultat qui causent ce comportement ?

Bonjour, Je viens de refaire une session afin de sortir le log. Une fois le traitement starnet exécuté, chaque tentative de Sauvegarder sous... échoue pour un problème apparemment lié au jeu de caractères. Je vous laisse examiner tout ce verbiage, en espérant qu'il mène à quelque chose. Bonne fin de week-end, output.log