Open yoangp opened 5 years ago
Ouuuh... c'est excitant ça! Ça fait popopopopop dans ma tête!
Relais : l'alarme doit être sur un relais parcequ'elle fonctionne en mode normalement fermé. J'ai cherché désespérément l'an passé une façon de faire un circuit normalement fermé avec des transistors et j'ai rien trouvé. Un avantage d'avoir un relais c'est qu'on peut installer une alarme plus beaf sans se soucier des limitations de courant. On doit prévoir un input de batterie sur le board aussi, peut-être un barrel jack avec qqchose comme ça :
switchs de version : 100% d'accord de les enlever, en plus je m'étais trompé dans les footprints... si on veut garder le circuit compatible sans pièces supplémentaires (d'un coup que...), on peut utiliser les pins SDA-SCL communes au mega et au uno, en haut à droite du board. Je vois surtout ça utile si quelqu'un veut ajouter un shield arduino au circuit, autrement ça va déconnecter les pins sda-scl situées au bas du mega.
switchs manuelles : je trouve que c'est vraiment une bonne idée que les switchs soient situées à droite du board! Comme ça, ça évitera que de la terre tombe sur d'autres composantes si quelqu'un taponne sur le circuit. De la même manière, toute les pièces qui entrent en contact avec les doigts devraient être en bas ou sur les côtés du board. Pour cette raison je déplacerais le bus de connecteurs située en haut du circuit plutôt à gauche mettons en face des relais.
SMT : d'accord pour enlever ces pièces, surtout le logic level shifter. C'était pour communiquer avec des devices 3.3V mais finalement on peut communiquer avec le raspberry Pi via USB donc c'est plus tant nécessaire. Au pire adafruit vendent des LLS très bien faits qui pourraient être soudés à l'extérieur du board. La seule pièce plus touchy c'est le sensor de courant(ACS723), qui est aussi SMT. On pourrait la remplacer par un socket pour un module chinois de current sensor, mais faudrait mettre un renfort mécanique pour le tenir en place, parceque ça tiendrait juste sur 3 pins. Je me disais peut-être des trous dans le board pour passer un ti-wrap? Je garderais ce feature-là par contre, les fusibles 1.5A, c'est une solution moyennement fiable actuellement je trouve. Ça serait beaucoup mieux avec un fusible électronique et tous les fermiers à qui on en a parlé trouvent que c'est une bonne idée.
DC-DC : ça sera pas de problème à changer dans le code... par contre, ça introduit un risque électronique qu'on pourra difficilement tester sans oscilloscope... et même là ça pourra différer selon la longueur de la serre. D'ailleurs, le driver de relais sur le board sert à isoler le 24V du 5V, si on les connecte ensemble par l'alimentation ça diminue la pertinence d'une telle protection. J'ai fouillé intensément le sujet l'hiver apparemment c'est impossible d'isoler complètement deux parties de circuit qui ont un contact galvanique (fancy word pour contact physique via un conducteur) sans un circuit filtre fait sur mesure. Ça laisse les transfos et les optocouplers pour une séparation fiable. C'est pour ça que deux alimentations, c'est une bonne solution je trouve, vu qu'il y a un transfo qui sépare physiquement les deux circuits. Et un bloc d'alimentation 5V que tu branches dans le mur ça coute genre 5$, je pense que c'est une bonne alternative au power supply qui nécessitait de faire entrer le 120V dans le boitier. Faudrait juste ajouter un barrel jack au circuit.
pour la limitation de courant, la solution la plus facile que j'ai trouvé à date c'est d'intégrer une chip LM317 en amont de l'alimentation des relais. C'est une chip super vieille donc probablement jamais obsolète et le circuit est très simple : http://www.bristolwatch.com/ccs/LM317.htm Par contre, faudra booster le voltage d'entrée parcequ'il y a un voltage drop de quelques volts. À tester sur le breadboard évidemment.
switchs sensors : ce sont des switchs pour activer/désactiver les pullups des sensors, pour diminuer la consommation en courant du board de quelques mA... pas très utiles finalement on pourrait les enlever.
petite nouveauté apprise aujourd'hui : une des causes principale de corrosion sur les circuits apparemment, ce sont les fuites de batteries de RTC. Je la placerais donc le plus possible en bas du circuit.
Je vais regarder ca moi aussi pour le keyboard
Sinon dc-dc converter isolé 3kV et protégé si court circuit en sortie: https://www.digikey.ca/product-detail/en/mean-well-usa-inc/SCWN06B-05/1866-5077-ND/8702750
On Thursday, January 17, 2019, LoupHC notifications@github.com wrote:
- Pour le clavier sur le PCB, on dirait que j'ai un doute... c'est quand même la partie du circuit qui sera utilisée la plus régulièrement, contrairement aux overrides switchs, donc ça implique beaucoup d'ouvertures de boitiers... en faisant quelques recherches ce matin je suis tombé sur ce module et je trouvais l'idée pas pire, peut-être qu'on pourrait la reproduire sur notre board? Le circuit est super niaiseux... https://www.amazon.com/Arduino-Keypad-Shield-16- Button-Matrix/dp/B06XGSYP1C Sinon faudrait au moins traiter l'ensemble du circuit avec un conformal coating ou qqchose du genre, je sais pas si ça peut être compatible avec les morceaux montés sur des sockets? Ou encapsuler d'une certaine façon la partie du circuit où les gens ont pas d'affaire à mettre leurs doigts.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LoupHC/controleur-CAPE/issues/62#issuecomment-455297099, or mute the thread https://github.com/notifications/unsubscribe-auth/AgxG_Hr1rAN1MUqqLgMBdVhif6gTcVgPks5vEMyjgaJpZM4aESYw .
En format DIP! You got me... Ça veut dire quoi l'isolation de 3000V?
Comment tu pensais faire pour potentiellement brancher un shield pour Arduino uno sur le PCB de l'Otomate? Il me semble que physiquement c'est assez coincé, en dessous du PCB c'est pas une super bonne idée, à côté du mega il y a pas ben ben de la place, sinon au-dessus du mega il faut des headers 2 fois la hauteur normale... Aussi, quels shields avais tu en tête pour un développement futur? WiFi?
Je pense à certains shields comme le shield de carte SD ou un shield LoRa, qui seraient assez minces pour glisser entre le MEGA et le board... c'est du hardware qu'on n'aurait pas besoin de développer dans le futur. Par contre ça impliquerait qu'on n'utilise pas directement les pins spécifiques au MEGA, mais à date on en a pas vraiment besoin, c'est surtout pour sa mémoire qu'on en a besoin.
Mais les shields qui pourraient se glisser entre le Mega et le PCB du contrôleur sont presque tous avec un pinout pour Arduino uno...
En regardant tout ça, je me dit que mettre des headers en extra ailleurs sur le board pour faire un pinout pour shields standard Arduino serait peut-être la meilleure option. On peut déja sauver un peu d'espace si on utilise un shield RTC + SD card qui fait une pierre deux coup (https://www.adafruit.com/product/1141).
En fait le pinout du UNO est compatible avec le MEGA mais pas l'inverse... (ou l'inverse?... en tout cas c'est un peu comme l'histoire du rectangle et du carré...) La seule contrainte c'est qu'il faut utiliser les points de connexions communs aux deux, par exemple utiliser les connexions sda-scl situées en haut à droite du board et le connecteur SPI situé au milieu du board, et ne pas utiliser les ios spécifiques au MEGA (pins 14-53 et A6-A15).
Ok, je commence à comprendre l'affaire, donc plusieurs pins du Mega ne pourraient pas être connectés au pcb du contrôleur s'il y avait un shield entre les deux.
Est-ce que tu penses qu'à ce moment-là on devrait utiliser le plus possible le bus I2C pour étendre le nombre de pins de communications sur le pcb du contrôleur? Une autre option serait de mettre des headers male-femelle pour faire la liaison des pins du mega avec ceux du pcb du contrôleur. Genre de même mais à la bonne place sur le mega..:
Oui ça peut-être une option au besoin! Par contre en ce moment, vu qu'on utilise I2C pour les sorties de relais, on utilise seulement les IOs pour les entrées de sondes, et donc on rentre encore dans le pinout du UNO. Si on stick avec cette idée là (utiliser i2c pour les relais) je pense qu'on n'aura pas à se soucier de ça!
Allo!
Diagramme fonctionnel du pcb: https://drive.google.com/file/d/1FTgodYRJLH3-fwumSEWBMR_UVwzgNT04/view?usp=sharing
Nice!
good thread. and sweet functional diagram!
for conformal coating, if we put any, we wont be able to replace and DIP parts! it's like epoxy, super nasty to remove and solder around. I think it's better to either choose SMD and reduce production costs, while keeping all 'burnable' components DIP, thereby keeping production costs low (DIP = way more expensive to have subcontracted) and use some epoxy coating OR use DIP, no epoxy, keep repairability high and easy of assembling a 'kit' and prototypes, (although really SMD soldering is not too hard, as long as parts sizes are not super small. 0805 and SOIC are ok by hand!
If no epoxy, we must limit opening the box as much as possible. so keep the keypad on the outside.
for the screen, I like it on the board. we can get a box with a window perhaps...
i found some cool options that can fit more info perhaps and give loup a sweet programming challenge!
found the number pad! https://www.aliexpress.com/store/product/4x4-Matrix-Keyboard-Keypad-Module-Use-Key-PIC-AVR-Stamp-Sml-4-4-Plastic-Keys-Switch/2130127_32831963425.html?spm=2114.12010615.8148356.15.64ca172cI3QwR5
I would like to propose in future how we can share the weather station data to other greenhouses to avoid needing weather station at each greenhouse in the case of a farm with 2-4+ GH's...
I ordered some Lora radios for future tests...
On Sun, Jan 20, 2019 at 12:05 PM yoangp notifications@github.com wrote:
Allo!
Diagramme fonctionnel du pcb:
https://drive.google.com/file/d/1FTgodYRJLH3-fwumSEWBMR_UVwzgNT04/view?usp=sharing
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LoupHC/controleur-CAPE/issues/62#issuecomment-455883574, or mute the thread https://github.com/notifications/unsubscribe-auth/AZfkJ6rpxJ2fxE5YhWnOZpDXTkEGi2zYks5vFKHdgaJpZM4aESYw .
Je vais commencer à ouvrir des issues pour chaque élément afin de faciliter le suivi.
Allo!
Ça avance, ça avance!
Bon, mise à jour:
Le dossier du projet KiCAD zippé à jour est dans dropbox.
J'ai remis exactement le même circuit crow bar + régulateur de l'ancien Otomate. Le LDO dont tu parlais Loup avait pas mal de pièces à mettre autour et j'étais vraiment pas convainçu que ça marcherait du premier coup le circuit. J'ai fouillé pour autre chose, rien d'intéressant. Pour une différence de drop out de genre 0.1V, trop de trouble pour rien je trouve. Je pense que j'ai juste changé la Zener pour une 5.6V sur le circuit crow bar. Je voulais plus bas, mais en dessous c'est 5.1V et avec le % de tolérance ça peut donner 4.99V... Donc tant pis, 5.6V.
J'ai mis le connecteur pour le module Lora
Pas vraiment d'importance mais j'ai finalement compris comment fonctionne les librairies et j'ai fait un ménage. La seule chose, c'est que j'ai l'impression que tu avais 100% des pièces dans ta librairie custom l'année passé right? J'imagine l'idée c'est d'éviter qu'une mise à jour des symboles de KiCAD fassent le bordel. Pour l'instant j'ai encore quelques pièces des librairies globales de KiCAD.
J'ai pas encore mis un header pour le ACS723. Je me demande si ça va être du trouble de demander à PCBWay de souder les chip sur les mini pcb que j'ai trouvé vu qu'on peut pas vraiment faire de stencil.. En tout cas, je vais faire ce changement et on verra.
Prochaine étape: Associer les bons footprints, placer et router. J'ai bon espoir que je vais pouvoir réutiliser pas mal de ton design de l'année passée pour le pcb, j'ai fait un test et KiCAD essaie autant que possible de garder le layout des pièces commes avant.
Ciao!
Début du BOM dans différents feuillets du document Otomate V2 - BOM.xlsx sur dropbox...
Allo Loup,
Je pourrais être rendu à faire le routing du PCB. Est-ce qu'on attend pour d'autres features ou pas? Je vote pour qu'on avance et que je passe tout de suite au routing dès que j'aurais un peu de temps dans les prochaines semaines.
Ben d'accord avec ça!! Si j'ai le temps cette fin de semaine j'ajouterai un circuit à pushbutton pour le module d'alarme, ça marche assez bien sur le breadboard chez nous. Mais oui ben partant qu'on commence ça!
Le jeu. 28 mars 2019 à 21:23, yoangp notifications@github.com a écrit :
Allo Loup,
Je pourrais être rendu à faire le routing du PCB. Est-ce qu'on attend pour d'autres features ou pas? Je vote pour qu'on avance et que je passe tout de suite au routing dès que j'aurais un peu de temps dans les prochaines semaines.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LoupHC/controleur-CAPE/issues/62#issuecomment-477829408, or mute the thread https://github.com/notifications/unsubscribe-auth/AXPiKERxQu97Z5V4AwxEBDLHnLKv8xkIks5vbWsZgaJpZM4aESYw .
Ok, je te laisse regarder ça en fin de sem, moi je vais continer à partir de la sem prochaine. Ciao!
On Thursday, March 28, 2019, LoupHC notifications@github.com wrote:
Ben d'accord avec ça!! Si j'ai le temps cette fin de semaine j'ajouterai un circuit à pushbutton pour le module d'alarme, ça marche assez bien sur le breadboard chez nous. Mais oui ben partant qu'on commence ça!
Le jeu. 28 mars 2019 à 21:23, yoangp notifications@github.com a écrit :
Allo Loup,
Je pourrais être rendu à faire le routing du PCB. Est-ce qu'on attend pour d'autres features ou pas? Je vote pour qu'on avance et que je passe tout de suite au routing dès que j'aurais un peu de temps dans les prochaines semaines.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LoupHC/controleur-CAPE/issues/62# issuecomment-477829408, or mute the thread https://github.com/notifications/unsubscribe-auth/ AXPiKERxQu97Z5V4AwxEBDLHnLKv8xkIks5vbWsZgaJpZM4aESYw .
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LoupHC/controleur-CAPE/issues/62#issuecomment-477829951, or mute the thread https://github.com/notifications/unsubscribe-auth/AgxG_C8HMHrH6cGck019g0_-6s3JRaXPks5vbWu3gaJpZM4aESYw .
Allo Loup et Jason,
Première ittération, juste pour le placement des affaires. Des commentaires?
Je sais que c'est pas encore le bon moment de faire ça, mais ça me tentait :-)
Pour l'instant il y a 6 relais, mais dans le fond, pour la ventilation forcée, ça peut être juste une sortie 24V pour un SSR à l'extérieur du board et pour l'alarme sonore à première vue le chip ULN2075 pourrait aussi supporter l'activation de l'alarme sonore. Ce qui veut dire qu'on a besoin de 4 relais pour les côtés ouvrant, 1 pour le chauffage .. et 1 de spare pour l'instant.
Sw man sur le dessin c'est pour les switch d'ouverture manuelle des côtés ouvrant en cas que l'Arduino est caput.
Je propose d'enlever les pièces pour qu'un arduino uno puisse fonctionner.
D'autres choses qui pourraient être enlevés d'après toi?
Est-ce que tu as eu besoin de faire un stencil pour les pièces SMT sur le PCB de 2018?
Est-ce qu'on pourrait se débarrasser de tout le SMT? On pourrait peut-être laisser faire les chip de mesure de courant et est-ce que tu peux me dire c'était quoi déjà les pièces SMT pour le SPI et Serial. Pour convertir à 3,3V? C'était quoi ton idée avec ces ports de communication, quelle était l'utilisation prévue?
Aussi, je propose qu'on fasse le software de manière à ce qu'il n'y ait jamais plus qu'un moteur qui roule à la fois. Cela ferait réduire la charge du power supply et on pourrait mettre un DC-DC converter 24V à 5V sans trop avoir de craintes que les moteurs fassent une drop de tension trop élevée sur l'alimentation 5V.
Aussi, pour le circuit de protection avec la grosses résistance, est-ce que tu avait vu une alternative intéressante qui n'utilise pas de résistance? Si je me souvient bien l'idée c'était d'éviter de bruler de quoi en cas de court-circuit sur les sorties 24V de l'ULN2075 right?
Quelle est la nécessité des switchs sur les sorties digitales D4,5,6,7 pour le capteur de température?