Antiath

A noter aussi: j'ai encore 3 exemplaires vierges de chaque carte chez moi, sans composants. Je peux aussi les envoyer si besoin. Il faudra commander les composants à part et les souder soi-même. Il y a juste une petite erreur sur la carte principale qui est assez simple à corriger ( deux pin voisines sur un des capteurs de courant où il faut faire un pont de soudure). Les gerber en ligne sur le github par contre sont corrigés EDIT : A noter bis qu'il y a également un bon paquet de très petits composants. Du 0402, du qnf, du sot363 et d'autres petits packages mincuscules.

Merci pour les compliments Guardes bien à l'esprit que le carte principale a des parties avec beaucoup de masse thermique. Ne serait que le plan de masse en dessous. Qui plus est je fabrique cette carte avec une épaisseur de 2 oz au lieu du standard 1 Oz, ce qui rajoute encore plus de cuivre. Ca ne m'a jamais empêché de fait des retouches au fer mais je sentais bien qu'à certain endroits mon fer à souder souffrait un peu. Donc si il faut souder l'entièreté, il y en a pour pas mal d'heures de "fun". Rien que le gros connecteur XT90 ( le jaune) doit être particulièrement difficile à souder à la main. Mais je serais curieux de savoir si quelqu'un y arrive, je ne suis jamais essayé à cet exercice sur ce projet.

Entre 200 et 350 euros suivant les options choisies, pour un circuit préassemblé en usine. C'est sans compter le cout du plastique et des connecteurs mais ça ne fera pas beaucoup augmenter la facture finale. Une note tout de même pour JLC PCB, ils réclament un minimum de 5 pcb et si assemblage par leurs soins, 2 exemplaires minimum assemblés. Donc il faut faire attention à cela. Si on est équipé d'un four pour souder ( ou qu'on aime se faire violence au fer à souder) et qu'on a besoin que d'un exemplaire, c'est plus intéressant certainement de faire l'assemblage soi même en commandant les composants ailleurs. Et sinon avec un minimum de deux personnes intéressées pour un modèle particulier, je peux toujours passer la commande moi même et faire parvenir ensuite.

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.