FalCT60

Bonsoir, Gros déterrage, mais d'une part j'ai de plus en plus besoin de temps pour assimiler et, d'autre part, les possibilités d'imager ont été rarissimes. C'est à l'occasion de nouvelles sessions très récentes que j'ai dû me remettre en question. Et tout reprendre du début. En reprenant mes résultats (obtenus avec une BdB et BdR correctes) et en divisant les valeurs median par 64, je me suis rendu compte qu'elles résultaient offset +1. Il me semble donc évident que si je souhaite des résultats corrects il me faut renseigner dans siril 64*$offset, car avec 1024 ce n'est bon que pour un offset de 16, or j'utilise 12 lors de mes prises de vues (pour laquelle 768 conviendrait mieux). J'ignore si l'écart peut être significatif au point d'expliquer le bruit très important que j'ai relevé sur mes traitements récents. Ou si je me triture une fois de plus les neurones inutilement.

Pour faire suite à mon dernier message, j'ajouterai que je n'ai rien trouvé sur ces batteries dans la base, ni même sur MegaCellMonitor, ainsi que je le craignais. Par contre, j'ai trouvé ça sur AE, où il apparaît qu'il s'agit de cellules à 1200 mAh, donc 4800 mAh pour 11,6 volts. Je vais tâcher de tester, mais quoi qu'il en soit déjà Li-Ion au lieu de LiFePo4, c'est de l'arnaque.

Bonjour, Je vais mettre fin au suspens insoutenable. J'ai reçu ladite batterie. 728 g à la pesée : Je passe tout de suite au démontage, curieux de voir les entrailles de la bête. Les trois premières vis sortent sans trop de résistance malgré le frein-filet rouge dont elles sont enduites de l'extrémité à la tête, mais la quatrième casse net au bout d'un tour et demi. Du bon me*de in China, visiblement. À l'intérieur, douze cellules 18650 4p3s estampillées HONGLI - j'irai faire un tour sur la bdd pour voir si une correspondance existe, mais je me doute que ça aussi doit être du me*de in China. L'adhésif double-face, de la même facture, n'a pas supporté le transport, le bloc n'est plus tenu. On distingue, dans l'angle inférieur droit, le reste de la vis cassée. Dernière photo : le BMS qui gère la chose et l'afficheur. 64€ pour ce machin-là, j'ai de sérieux doutes.

Bonsoir Cyril, La raison du rejet massif, j'ai fini par la comprendre : montée de brume chargée de particules fines en haute altitude peu après le début. Nous étions en alerte rouge jusqu'à mercredi, il faut croire que les prévisions étaient erronées et trop optimistes. Je m'en suis réellement rendu compte samedi soir, après avoir lancé deux heures d'acquisition à 30 s, le temps de voir un film. J'ai mis mes difficultés à effectuer la map sur le compte d'une fatigue extrême accumulée ces trois derniers jours et de l'objet lui-même très faible - dans le voisinage immédiat de M51. C'est en examinant les vues après-coup que j'ai commencé à comprendre : fond du ciel tirant sur le caca-d'oie et bord inférieur très lumineux, comme si quelque chose avait amplifié la pollution lumineuse de la ville. Je suis tout de même allé jusqu'à l'alignement des brutes, pour voir : seules 27 photos ont été retenues, 213 ont été écartées, et dans la foulée, j'ai détruit l'intégralité des prises y compris celles des deux précédentes soirées. Ceci étant, je serais content si le cas se reproduit de pouvoir trouver une liste des photos originales correspondant à celles rejetées, histoire de ne pas rajouter encore plus à mes conneries habituelles...

Bonjour, Lors de l'alignement des brutes, certaines peuvent être écartées. Elles sont indiquées dans le log de la console, mais je ne suis pas parvenu à faire le lien entre le numéro indiqué en rouge et l'image originale. Par exemple, j'ai l'indication «... image 34 écartée». Dans le fichier LightConversion.txt je vois que la n° 39 correspond au fichier 234921.fits. Mais si je supprime ce dernier et que je recommence toute la procédure depuis la conversion des light jusqu'à l'alignement (dois-je préciser que j'ai bien pris son de supprimer tous les fichiers précédemment générés ?), j'ai de nouveau une image écartée - qui peut être le même numéro que précédemment ou un autre. Accessoirement, je peux même me retrouver avec des images écartées non listées dans la console. J'explique : je démarre l'alignement avec 64 images dans la séquence pp_light, deux sont déclarées écartées, et je me retrouve avec 51 une fois l'alignement terminé. Où sont passées les 11 autres ? C'est du concret, j'ai recommencé dix fois avec deux lots de photos différents après m'en être aperçu tandis que je rédigeais ce message, les dix fois j'ai obtenu les mêmes résultats. Mon souhait serait de pouvoir éliminer à la source les photos écartées, donc trouver quelque part dans les logs un fichier listant les images originales correspondant à celles écartées lors de l'alignement. Un grand merci par anticipation si cela peut voir le jour. J.-Luc

Depuis 20h45 que je bataille avec mon système il est définitivement acquis qu'il est impossible d'utiliser à la fois StellarMate sur la tablette, Synscan sur le mobile et la raquette. Synscan mobile provoque des emballements de la monture et, si en même temps que StellarMate perd totalement le nord. La raquette utilisée en même temps que StellarMate arrête le suivi - de l'argent jeté par la fenêtre -. Il me faut donc apprendre à dompter la tablette. Par chance, les développeurs de StellarMate abattent un boulot formidable, l’application devient de plus en plus facile à utiliser et stable. Encore quelques efforts de ma part, et je devrais pouvoir commencer à imager en moins de quinze minutes - contre quatre-vingt-dix ce soir, par exemple.

Bonjour @sebseacteam, D'accord, là je comprends mieux. Et de fait je ne suis pas concerné. Merci pour ces précisions.

C'était vraiment trop beau pour durer : je viens de me rendre compte que lorsque je me sers de la raquette pour modifier la position en déclinaison, cela provoque immédiatement une dérive selon ce même axe. Seul moyen pour l'arrêter : couper puis rétablir le suivi. Ça risque d'être coton de trouver ce qui provoque ce phénomène...

Bonsoir @nico1038, Si j'ai bien compris, le champ d'action des flat se situant très près du capteur fait que cela laisse une certaine marge. Cela me paraît logique, après tout, même si cela reste très intuitif - et comme je subodore que les explications risquent d'être de nature à me flanquer une migraine carabinée, je m'en passerai. Pour ce qui est de la hauteur sur l'horizon, j'ai lu des interventions qui faisaient état de la nécessité d'ajuster la map selon que le pointage s'effectuait à 30° ou vers le zénith. Et comme je préfère poser une question idiote que rester dans le flou... Merci pour ton intervention.

Bonjour, Les flat doivent être produits exactement aux mêmes focale et map que les brutes. Ça, je l'ai compris depuis assez longtemps. Néanmoins... La map doit être modifiée en fonction de la température ambiante et de la hauteur dans le ciel. C'est ce qui me pose problème : comment peut-on concilier ces deux règles ? Il y aura forcément des photos dans une soirée qui auront nécessité un ajustement de la map, et pour lesquelles la map utilisée pour les flat ne sera pas correcte. Non ? Qu'est-ce qui prévaut, dans ce cas ?

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