astrolivier

Merci pour ce retour. Jouer du fer sur du cms ne me fait pas peur. J'en parlerai au club car je trouve ce travail remarquable et digne d'un niveau pro. De plus c'est le genre de matériel indispensable pour automatiser un observatoire Olivier

absolument génial. Une idée du prix de revient final entre les pcb et les composants?

salut fred, j'ai téléchargé ca sur le site https://magnitude78.astrosurf.com/strock-parametrable/ Je pense que la mise à jour dont ils parlent ne t'embête pas car cela parle du barillet ^^. Je vois ce que ca peut donner.

Je vais retrouver les fichiers pour voir ca

Salut Fred, je ne veux pas me lancer sur ce projet bien que c'est quelque chose qu'un jour je viendrai à réaliser je pense. En revanche, m'étant un peu renseigné, je sais qu'il est possible de récupérer des fichiers pour faire un paquet d'éléments à la découpe laser. Je peux te proposer soit de le faire si les pièces ne sont pas trop épaisses, soit je te conseil de passer par un fablab (Le Havre dispose d'un laser CO2 de plus 100W et l'heure de découpe était à 10€ à l'époque). Olivier

Une version apple serait elle envisageable ? Je n’ai pad andoid

Merci pour vos retour. Pouvez vous me dire ce que vos pensez des modes suivant dans le paramétrage de la caméra dans NINA: - mode ULTRA - usb limit sur 9? - mode pour augmenter le fullwell Merci

Merci beaucoup pour tout. En effet le mieux sera de tester sur des cibles réelles quand il fera beau......

Merci @krotdebouk pour ce message. Je testerai cette solution avec pix Juste une dernière question: j'ai lu à gauche et à droite que prendre des poses aussi courtes que des bias (donc 0 dans NINA) pouvait poser des problèmes liés à l'éléctronique. Vu que tu as une caméra similaire (d'un point de vu capteur puisque la Player One est un cran au dessus électroniquement) tu n'as jamais rencontré de problème comme cela?

Sur les tuto de @Colmic, ma foi très bien réalisés, on peut y voir que les bias dont il parle dans la partie I sont des dark de flat... ou alors je n'ai strictement rien compris http://colmic.astrosurf.com/Traitement_SiriL/brutes/Tuto-SiriL1_Introduction.pdf

merci @rmor51 pour toutes ces infos. Je vais aller voir la galerie

@Ant-1 Merci pour ce retour. Comme je le disais en intro je pratique depuis de nombreuses années à l'APN. Avoir donc une caméra refroidi avec bruit thermique très faible, sans ampglow change pas mal la donne. Pour mes FLAT mon panneau scintille. Je suis obligé de faire des poses (que ce soit avec ou sans filtre par ailleurs) assez "longues", au moins de 1s voir plus. Pour le reste du matos je suis sur une EQ6 que j'ai beaucoup modifiée et qui me donne satisfaction, la lulu est une TS apo 80/480 avec correcteur, j'utilise NINA pour piloter mon installation, SIRIL / PIX pour le prétraitement / traitement. Je fais du dithering toutes les 2 images sur plusieurs pixels. Alors surement oui, je me pose beaucoup trop de questions Mais j'ai tellement lu et vu de choses que je m'en suis moi même perdu. A priori, l'utilisation du bias synthétiques est excellente si on fait des flats très court. Je partirai donc plus vers le calcul de l'offset à soustraire via la méthode fournie par SIRIL. Mais, avec des flats aussi long, j'ai cru comprendre qu'au lieu de faire des bias il fallait faire des dark de flat. Ensuite, dans le processus de prétraitement: - création du master dark - création du master dark flat - on calibre les flats avec le master dark flat - on calibre les brutes avec le master dark et le master flat

En fait j’ai regardé ces deux videos de Cuiv: ces deux videos expliquent ce que je disais plus haut. Apres toutes infos sont bonnes a prendre! donc je me constituerai une banque de dark, de bias a très haute vitesse et des flats. qu’en est il des dark de flat si je prends des dark de plusieurs secondes? ps: mon panneau flat n’est pas parfait, donc pour éviter des motifs je prends des poses de plusieurs secondes pour moyenner la trame

Merci pour vos réponses si précises et avec exemples Donc si je résume bien, je fais - les darks avec temps de pose, gain, température et offset identiques aux brutes, - les flats (durée de 1s ou plus) avec gain et offset identiques aux brutes.: le L-extreme est donné pour des bandes de 7nm. Mon panneau est dimmable via NINA donc je peux choisir un peu ce que je veux! luminosité ou temps de pose. - les bias (temps de pose le plus court comme sur APN). Pour les 1s de temps de pose c'est justement en regardant une vidéo de CUIV que j'ai vu qu'il paramétrer ainsi sa caméra. J'avais cru comprendre qu'en faisant des dark de flat ca compensait l'absence de vrais dark... bon... j'avais mal compris et j'ai donc bien fait de venir demandé Olivier

Bonjour à tous, après plus de 15 ans à faire de l'astrophoto avec un APN Canon 1000d refiltré astrodon, j'ai l'opportunité d'accéder à un rêve: m'offrir une belle caméra moderne Cette caméra sera une RisingCam IMX571 couleur. En plus de la caméra j'aurai un filtre 2" L-extrem HaOIII. 1) Question sur le prétraitement: Ayant toujours fait de l'APN et après avoir pas mal lu d'articles ou regarder de tuto sur les prétraitement, je me pose encore des questions. Aussi, je suis désolé si les questions ont déjà été abordées mais je n'ai pas réussi à convertir à 100% mes doutes en réponses. D'après ce que j'ai pu comprendre, étant donné que cette caméra n'a pas d'amp-glow, je n'aurai besoin que des images suivantes pour réaliser les fichiers de calibration, en sachant que de base, j'utiliserai 100% du temps le mode "high gain" - flat avec un temps de pose de 1 à 2s, avec le même gain et le même offset, à la même température que les brutes - bias avec un temps de pose de 1s, avec le même gain et le même offset, à la même température que les brutes. Vu que je compte imager avec une température de -10°C, le bruit thermique devient complètement négligeable fasse au bruit de lecture. Ne pas avoir à réaliser de dark est quand même un sacré gain de temps! Egalement, pas besoin de dark de flat si j'ai bien compris. Pouvez vous me confirmer ou pas cette démarche? 2) Question sur la caméra elle-même: a) Cette caméra dispose d'un anti buée intégré. Pour régler la puissance de chauffe on a dans NINA 4 valeurs de puissances disponibles. Comment faite vous savoir quelle valeur mettre? je veux dire par là que si je ne mets pas assez de chauffe je risque la buée et si je mets trop je surchauffe donc potentiellement de la turbu? J'avoue que je trouve cet ajout génial mais encore faut il savoir comment bien le régler Ca me fait penser au résistances chauffantes à variation de puissance manuel par une télécommande!! complètement empirique! b) J'ai pu lire que pour trouver le meilleur gain il ne suffit pas de lire les caractéristiques de la caméra sur le net. Il vaut mieux utiliser SharpCap et son "sensor analyse" pour les determiner. Vous avez des suggestions? c) même question mais pour trouver la meilleure valeur d'offset. Ou simplement faire des images à la même vitesse que le bias (1s) et régler par tatonnement et l'histogramme . Bon, pour commencer je pense que ca fait déjà pas mal. Mais je pense que j'aurais d'autres questions plus tard Merci à vous. Olivier

Bonsoir. je suis partant comment procède t-on? Petite question bete: puis je utiliser n’importe quel boitier imprimer en 3d? j’ai une imprimante 3d? J’ai vu des modeles 3d sympa sur le net

@pachytriton54 quand tu dis que tu as des pcb de dispo, ca m’intéresse est ce disponible avec onstepX que je compte installer ? si je comprends bien ca fonctionne en wifi. C’est a dire se connecter au hostpoint de la fysetc e4?

Je suis partant, je viens d’acheter une fystec e4. j’ai une eq6 de 2013 goto dont j’avais modifié en poulie courroie. elle fonctionne tres bien mais je me dis qu’avec ce onstepX elle serait revigorée je compte faire la modif d’ici l’ete, la je profite (enfin tres…trop…rarement des nuits claires de Normandie ) Olivie

@jduffas J'ai repris votre commentaire sur le detecteur de gouttes. J'ai apporté les corrections suivantes: void updateGOUTTES() { // 1. Alimente le capteur digitalWrite(capteur.alimPin, HIGH); // 2. Attend la stabilisation (50ms pour plus de fiabilité) vTaskDelay(pdMS_TO_TICKS(50)); // 3. Lecture avec validation sur 2 échantillons static int lastReading = HIGH; int currentReading = digitalRead(capteur.pin); if (currentReading == LOW && lastReading == LOW) { capteur.valeur = 1; DEBUG_PRINTLN("pluie (confirmée)"); } else if (currentReading == HIGH) { capteur.valeur = 0; DEBUG_PRINTLN("sec"); } lastReading = currentReading; // 4. Coupe l'alimentation immédiatement digitalWrite(capteur.alimPin, LOW); } J'ai augmenté le délai de lecture afin d'être certain du délai de stabilisation. Je fais la vérification de la présence de gouttes sur le capteur en réalisant deux mesures (le code vérifie la valeur précédente pour confirmer ou non la présence de gouttes). Il faut donc 1s pour être sur de la présence de gouttes. Je n'ai pas modifié le main.ino. La quantité de pluie peut ne pas être visible en cas de très faible pluie, mais comme je disais je ne me sert pas de cette variables dans les conditions de fermeture. Merci pour votre apport. Olivier

Bonjour, Merci pour ton message. Concernant les variables pluies et gouttes, malheureusement NINA n'offre pas la possibilité d'afficher les deux. Par défaut c'est la quantité de pluie. J'avais par ailleurs codé pour que ce soit la valeur du détecteur de pluie (donc 0 ou 1) qui soit envoyée vers NINA, mais j'ai fais un pas en arrière. Il m'a fallu faire un choix et, bien sûr cela n'engage que moi, je n'attends pas que la pluie soit tombée pour que le safety monitor ferme l'observatoire. De fait l'affichage de la quantité de pluie calculée n'est là que pour avoir une donnée. Elle sert d'ailleurs plus sur la page web que pour NINA. Pour ma part, dans le safety monitor je n'utilise que la variable vent et nuages pour fermer le toit En effet je n'ai pas précisé qu'il fallait aussi le commenter dans MLX90614 si non utilisé. Je vais ajouter le commentaire. Je vais regarder le code pour le détecteur de pluie. Surement quelque chose qui ne va pas lors de lecture successives. Pourquoi même reprendre votre code si cela fonctionne Olivier

En fait tu as des limites qui sont forcement mises quelque part. Le but étant que la monture ne puisse pas allez trop loin après le méridien pour ne pas risquer de faire taper le matériel. parfois on peut laisser quelques minutes après ce qui peut éviter de perdre du temps. Mais généralement les gens dise a NINA de s’arrêter avant, attendre disons 10min après le méridien, et la NINA lance le retournement. Mais cette histoire n’est jamais aussi simple qu’on le croit. Lors de mes essais j’assistais avec grande attention a ces moments la. Peut être que quelque chose cloche dans ton retournement si cela provient bien de cela.

Salut. désolé je n’ai pas accès a mon pc pour comparer 😕 weekend different de celui prevu si les moteurs s'arrêtent avant chaque méridien en effet il y a peut être une option qui désactive les moteurs avant le passage. C'est peut être dans NINA. Comment est géré ton flip? Si les moteurs s’arrêtent le bruit au niveau de la vsf devrait être clairement différent de celui en fonctionnement.

Update finale 6.1.3. A telcharger sur la 1ère page. Ceci marque la fin du developpement de ce projet, qui je pense est largement abouti, fonctionnel, modifiable, upgradable à souhait pour chacun. Je reste bien évidement disponible pour échanger au besoin avec les personnes nécessiteuses. Olivier

Bonjour @pyrou61 je n'avais pas eu de notifications Je regarde et compare aux miennes ce soir. Je te redirai si je vois quelque chose. Mais à priori il n'y a pas d'étrangeté ou de bizarreries qui saute aux yeux. Si le problème ne vient pas de la configuration, as tu l'occasion de tester avec un autre pc sur lequel tu auras installé les mêmes logiciel avec les mêmes paramètres. C'est un peu ennuyant mais cela permettra de valider que le problème n'est pas logiciel. Dans ce cas ce serait plus hardware.

Je vais regarder ca de plus près