Antiath

Bonjour à tous, Je partage ici un projet de power box DIY dédiée aux setups d’astrophotographie : Open Power Box. https://github.com/Antiath/Open-Power-Box L’idée est de proposer un boîtier de distribution d’alimentation 12 V open-source et open-hardware, capable de gérer proprement l'alimentation de setup photo de taille conséquente, comme par exemple des configurations multi-instruments sur une seule monture, ou des configurations plus classiques mais avec de nombreux accessoires gourmands en courant. Il existe de nombreux projets similaires déjà mais j'ai constaté qu'ils se concentrent surtout sur des configurations nomades où l'économie de moyens est de mise afin de préserver sa batterie. Je propose donc une solution DIY plus adaptée à de l'equipement d'observatoire où le courant peut couler à flot. Le projet inclut les schémas électroniques, les PCB (gerber), le firmware, les drivers et les fichiers d’impression 3D, afin que chacun puisse la construire, la modifier ou s’en inspirer. Les specifications du projet sont : - 7 sorties 12 V commutables individuellement (avec mesure de courant et fusibles logiciels) - 3 sorties PWM pour résistances chauffantes, avec possibilité de gestion automatique basée sur température / humidité - 1 rail 12 V de 3 connecteurs groupés et allumé par défaut. Pour les équipmement peu gourmands qui peuvent rester allumés sans arrêt. - 1 relai permettant do commuter une source d'alimentation externe de tension quelconque - Une capacité en courant total de 20A minimum (détails par sortie donné dnas le github) - En option: 1 hub USB2 à 7 ports commutables individuellement. Les fonctionnalités : - Driver ASCOM avec GUI dédié fonctionnant sur le même principe que EQMOD ou GSS - Interface Alpaca via le réseau local/wifi, qui permet d'établir une liaison entre le client ASCOM ( NINA) et l'appareil au cas où le cable USB n'est pas souhaitable ou instable. - Driver INDI - Interface "web" sur le réseau local via votre browser favori. - Pilotage via USB ou Wi-Fi au choix - Protection contre l'inversion de polarité - Fusibles sur les sorties PWM et le rail 12V - Fusibles "logiciels" grace à la présence d'un cpateur de courant sur chaque sortie. Les limites de courant sont configurables dans les diverses interfaces et, par défaut, assez conservatrices. - Possibilité de renomer chaque sortie à votre convenance pour mieux identifier vos équipements. L’objectif est d’avoir une solution robuste, flexible et totalement ouverte, adaptée en particulier aux installations en postes fixes et en remote. Il s'agit d'un projet que je met en partage pour la communauté. Etant donné l'existence d'une pléthore de produits sur le marché, je n'ai aucune intention de me lancer dans la commercialisation de ce projet. Je peux éventuellement fabriquer quelques exemplaires pour les intéressés mais cela reviendra plus cher que certaines produits chinois plus ou moins équivalents. Il faut compter entre entre 200 et 300 euros de coût suivant les options choisies. Possiblement moins si vous réalisez le projet vous même mais on restra loin de ce que SV Bony propose par exemple. Les cartes électroniques peuvent être réalisées par exemple chez JLCPCB qui a l'avantage d'avoir son propre stock de composants et donc de pouvoir permettre l'assemblage des cartes et de vous épargner la soudure des composants. Restera encore à souder les connecteurs qui ont été guardé séparé à dessin, afin de laisser le choix, et à imprimer le boitier. NB1: Si le driver ASCOM , pour le moment, est prévu pour les spécifications ci dessus, le reste du code (firmware et driver INDI) est plus souple et peut s'adapter à un nombre de sorties différent. Il va de soi que cela requiert de tout nouveaux PCB mais la possibilité existe. NB2: Cela n'est pas visible sur les photos ici mais un capteur de températeur et d'humidité SHT31 peut etre ajouté au projet afin de permettre l'automatisation des bandes chauffantes. Une version des boitiers sera fourni dans le github pour permettre d'attacher un modèle spécifique de ce capteur sur le côté des boitiers. NB3: des trous sous les boitiers sont prévus afin de pouvoir y mettre divers systèmes de fixation comme des pinces à queue d'aronde. Je finirais par quelques images du projet réalisé. Comme spécifié plus haut, une option est proposée afin d'inclure un Hub USB contrôlable dans le boitier. Cela signifie que le projet se décline essentiellement en deux versions : 1) Celle que vous voyez dans la première image de ce post et ci dessous , qui correspond à la version de base. 2) La version avec le hub usb qui est en fait constituée de la même carte électronique + d'une seconde carte fille réservée au hub. Et voici quelques photo du driver ASCOM en action: Côté NINA Et côté GUI custom ( qui se lance automatiquement une fois le driver ASCOM connecté) N’hésitez pas si vous avez des questions !

Je partge tes frustrations ouai... Je crois que ce qui m'énerve le plus c'est cet encart sur leur stie : En particulier le point où on te dit de ne surtout pas réutiliser du code existant. Comme si tout le monde savait exactement quoi écrire rien qu'en lisant leur doc, certes extensive, mais obscure et totalement dépourvue d'exemple concret et de snippet de code. Ouai ben...je vais me gêner hein.

Haha, je suis aussi en train de développer un nouveau driver ASCOM en ce moment. Heureusement je suis habitué au C# ( et pas au C 😅, la distinction est importante) donc c'est moins douloureux mais ouai je n'ai pas particulièrement apprécié non plus les derniers changements effectués sur la chaine d'outils d'ASCOM depuis la version 7. Je n'ai pas de soucis en soi avec ALPACA, c'est très bien comme initiative parce qu'ils continuent de supporter le développement de drivers pour Windows. Par contre l'abandon des drivers DLL classiques pour ne supporter plus que les drivers à serveur local... Je trouve cela vraiment très mal avisé...ça rajoute de la friction supplémentaire au développement de petits drivers simples qui n'ont pas besoin des fonctionnalités d'un serveur local. Bref. Je vois que tu as finalement résolu tes soucis mais je me permet quand même quelques conseils: 1) si ce n'est pas déjà fait, passe en .NET framework 4.8 minimum. 2) pour débugger le driver, normalement avec un driver DLL tu devais dire au débuggeur quel executable lancer, typiquement tu ajoutais un client ASCOM à la solution pour ça et comme ça tu pouvais mettre des breakpoint dans ton driver. Pour le serveur local c'est un peu différent, tu n'as pas besoin de rajouter de client dans la solution. Le serveur/driver lui même est l'exécutable que le débuggeur pointera. Donc après avoir build la solution, et fait cette petite étape dand cmd.exe pour enregistrer le driver ( ...m'énerve aussi ce truc), tu lances l'execution dans Visual studio en pointant le projet du driver, il executera le serveur local et après celà tu ouvres à part, en dehors de Visual studio, n'importe quel client que ce soit NINA ou autre. et tu lui demandes d'ouvrir ton driver. Tes breakpoint fonctionneront sans problème. C'est finalement assez simple mais j'ai quand même buté là dessus pendant quelques heures. 3) Ils le précisent bien dans le readme mais je vais le répéter quand même : le seul fichier qu'il est réellement nécessaire de modifier c'est SwitchHardware.cs. Ton driver il est là dedans et sa structure est essentiellement la même que les drivers DLL classique. Le reste, à moins que tu ais besoin d'autre chose qu'un port série (qui est déjà implémenté dans Sharedressources), pas la peine d'y toucher. Donc au final une fois qu'on sait où on doit mettre notre code et comment débugger, c'est pas beaucoup plus difficile qu'avant.

L'avantage si tu fais le client toi même et que tu éxecutes tout au sein même de VS en cliquant sur le triangle vert, si il y a un bug, VS va s'arrêter sur la partie problématique, pointer la ligne de code et afficher la sortie du debugger.. Tu peux même utiliser des breakpoint ( en cliquant sur le côté d'une ligne de code pour faire apparaitre un cercle rouge) où le code pausera et tu pourras examiner le contenu des variables. C'est magique.

Oh et une chose à faire une seule fois avant de tester le driver et de le compiler. Dans l'explorateur, cliques droit sur le projet ( jusque en dessous de la solution..désolé le vocabulaire de VS est particulier ...) , puis propriétés. Sur l'onglet Générer ( Buil en anglais chez moi), tu pourras lui préciser quelle plateforme viser. Par défaut ce sera probablement x86. Il vaut mieux mettre en x64 si ta machine a un processeur x64. Nina sera pas content sinon et je pense que les autres clients non plus.

Si tu penses pouvoir tester le driver, et bien le plus simple c'est de le compiler. Dans VS, cliques sur Générer puis Nettoyer la solution, puis une fois fini, Générer la solution. S'il n'y a aucun problème de compilation, alors le driver est automatiquement créé et enregistré par ASCOM sur ce pc. Il te suffit d'ouvrir ton client favori, genre NINA par ex et d'aller le trouver et te connecter. C'est le plus simple mais comme ça, ça t'aidera pas si il y a un bug ( et il y en aura avec ce que tu as actuellement écrit). Pour mieux débugger, le mieux c'est de faire un client toi même dans la même solution que le driver et demander à VS d'éxécuter la solution en pointant ce client. Tu va dans l'explorateur de la solution, cliques droit sur la solution, Ajouter, Ajouter un projet, choisir un template ASCOM Windows form et là tu devras te débrouiller pour faire l'interface graphique, mettre des boutons, des zones de textes et du code qui appèlera le driver et affichera tes données. C'est trop long pour tout expliquer ici, il y a pléthores de tutoriels pour apprendre à faire ça sur VS, et probablement même des tuto spécialisé pour ASCOM qui expliquent exactement ça. C'est exactement ce que j'expliquais plus haut. Comme ça, plus besoin d'envoyer GETDATA.

Si tu mets arduinoport.Write("GETDATA") dans la fonction arduinoport_DataReceived, à chaque fois que tu vas recevoir des données , il va renvoyer " GETDATA" à l'arduino. Je crois pas que ce soit le comportement que tu souhaites. Ca va saturer sur le port série. Je vois dans ton firmware arduino que tu attends cette requête "GETDATA" pour répondre, donc effectivement de cette manière là, il faut que cette requête soit envoyée régulièrement par le driver. Il faut savoir à quel endroit l'exécuter. Cela doit être fait à intervalle régulier... - faut-il mettre en place un timer alors qui enverra la requête tous les x milisecondes ? Comment on fait ça en c# ?( jamais fait ça donc j'ai pas la réponse mais ça doit être possible) - ou est-ce qu'on peut profiter du fait que le client va interroger le driver de façon régulière pour envoyer GETDATA à chaque fois ? Par exemple, le client va appeler régulièrement la fonction Temperature pour avoir la dernière valeur. Est-ce qu'on peut pas mettre la un arduinoport.Write("GETTEMPERATURE") ? Et si on fait ça est-ce qu'on bloque le driver tant que la réponse est pas arrivée ? Si oui comment ? Si non, que faire à la place ? Faut répondre à tout ça pour savoir quoi faire... Perso je trouve ça trop compliqué pour pas grand chose ... Une autre stratégie c'est de simplement dire à l'arduino d'envoyer ses données tous les x secondes ( tu remarqueras que ASCOM prévoit une grandeur nommée AveragePeriod...peut etre on peut se servir de ça pour déterminer la fréquence à laquelle envoyer les données ?) . Côté driver, on se contente de récupérer ça dans arduinoport_DataReceived, de stocker les valeurs dans des variables non statiques et de dire au driver de retourner ces variables quand le client l’interroge. On a plus à se demander comme ça comment gérer les timing depuis le driver, quelle fonction est bloquante ou non, c'est l'arduino qui mène la dance. Bien plus facile. Par exemple private void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { string a = port.ReadLine(); //Supposons que le string soit juste constitué de la température, rien que le nombre, aucun autre charactère. Pour simplifier _temperature= double.Parse(a); } private double _temperature =0; //j'initialise à 0. Cette variable me sert à sotcker la dernière valeur de température. port_DataReceived la met à jour à chaque fois que l'arduino lui envoie une valeur. /// <summary> /// Temperature at the observatory in deg C /// </summary> //Cette fonction est déjà incluse dans le template, il suffit d'enlever les lignes qui disent que c'est pas implémenté et mettre ton code à la place //C'est elle qui est appelée par le client quand il veut savoir la température. internal static double Temperature { get { return _temperature; } }

Et concernant la gestion du port Série, il te faudra probablement un EventHandler ( je sais pas si ça existe en VB) qui permettra d'appeler une fonction dès que de nouvelles données sont reçues sur le port Série. Perso j'instancie le port Série dans la méthode Connected ( la partie set pour être précis), plutôt dans le constructeur de la classe comme toi. Et juste après ça, tu va utiliser l'EventHandler du port "DataReceived" et le faire pointer vers une fonction à toi ( chez moi je la nomme port_DataReceived). public bool Connected { get { LogMessage("Connected", "Get {0}", IsConnected); return IsConnected; } set { tl.LogMessage("Connected", "Set {0}", value); if (value == IsConnected) return; if (value) { connectedState = true; LogMessage("Connected Set", "Connecting to port {0}", comPort); port = new SerialPort(comPort, 9600);//Set your board COM port.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived); port.Open(); } else { connectedState = false; LogMessage("Connected Set", "Disconnecting from port {0}", comPort); port.Close(); } } } Et ensuite la fonction callback "port_DataReceived", elle sera comme cela par exemple private void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { string a = port.ReadLine(); //Et là à toi de voir comment manipuler le string pour en sortir tes données, c'est toi qui décide comment c'est mis en forme dans l'arduino. }

Concernant VS2022, si tu n'as pas envie de faire un driver en mode "local server" comme ASCOM veut nous forcer à faire maintenant (😒 )... tu peux toujours installer VS2019 et là tu pourras faire une driver classique. C'est à toit de voir ce dont tu as besoin. Si tu as besoin du serveur local, je pourrai pas aider là là dessus. J'ai jamais eu à implémenter cela dans mes drivers ASCOM. Si je dois faire un petit driver, je le crée sur VS2019 et après j'en fais ce que je veux. Néanmoins, si je créée rapidement un driver Observing conditions sur VS2022, je vois dans l'explorer un dossier "ObservingConditionsDriver" avec deux fichiers .CS dedans. En regardant les commentaires dans le code, ils disent clairement qu'il veut mieux ne pas toucher à "ObservingConditionsDriver.cs" et que tu dois juste implémenter tes fonctions principales dans "ObservingConditionsHardware.cs". Donc si on ouvre ce dernier, tu peux déployer les sections pour avoir accès à ce que tu as besoin avec tous les fonctions typiques qu'on retrouverait dans un driver ASCOM à l'ancienne. Entre autres, la région "IObservingConditions Implementation" expose toutes les grandeurs que tu veux utiliser ( des choses comme la température, la pression, l'humidité etc, à toi de voir) et c'est ça que le client appellera pour récupérer ses données ou en envoyer à l'appareil. Donc ce fichier se code comme un driver ascom normal à priori. Voilà