mercredi 27 mai 2020

MAX7219 : affichage matriciel




MAX7219 : affichage matriciel



Nous allons parler aujourd'hui de modules MAX7219 permettant de réaliser un afficheur matriciel à 64 LEDs.
Nous allons examiner certains aspects que l'on ne voit pas dans les nombreux tutoriels qui foisonnent sur le WEB :
  • alimentation et découplage
  • affichage de caractères accentués
  • affichage clignotant
  • utilisation avec un ESP32 (y compris les touches capacitives)
  • éviter certains pièges
Ces modules existent sous forme unitaire comme ceci :
Module DIP

Module CMS


Dans le premier cas le circuit MAX7219 est un modèle DIP apparent.

Le deuxième module est équipé d'un circuit CMS situé sous l'afficheur, plus facile à organiser en panneau multi-modules jointifs.

Ils existent aussi sous forme de panneaux de 4 modules CMS ou plus :

Module quadruple


1. Le matériel

1.1. Pilotage

Ces modules se pilotent en SPI. ils sont équipés de 5 broches d'entrée (VCC, GND, DIN, CS, CLK).
Il peuvent être chaînés, ils possèdent donc également 5 broches de sortie (VCC, GND, DOUT, CS, CLK) que l'on reliera aux broches d'entrée du module suivant:


1.2. Alimentation

En fonction du nombre de modules et de la luminosité prévue il faut compter environ 250mA pour 4 modules alimentés affichant du texte avec la luminosité maximale.
La consommation dépendra aussi de la police de caractères utilisées (certaines polices allument plus de LEDs que d'autres).

Le câblage devra donc être réalisé avec des fils de section suffisante.

Bien entendu si les afficheurs sont amenés à afficher des bitmaps plus ou moins pleins, cette consommation sera également supérieure.

Le courant maximal par module (ce courant correspond à l'affichage de 4 carrés pleins à luminosité maximale) dépend de l'implémentation du constructeur, en particulier de la valeur d'une résistance ISET (voir la datasheet) qui fixe ce courant.

1.2.1. Alimentation par USB
Si l'on alimente un ARDUINO ou un ESP32 par son connecteur USB il faudra tenir compte de deux contraintes :
  • le courant maximal fourni par l'alimentation ou le port USB de l'ordinateur
  • la courant maximal admissible par la diode ou le fusible de protection de la carte
La diode de protection d'une carte ARDUINO ou ESP32 admet en général assez peu de courant :
  • ESP32 DEV-KIT : diode 1A
  • ARDUINO NANO : diode 1A
  • ARDUINO MEGA : fusible 500mA
On voit que la limite est assez vite atteinte si l'on désire utiliser plusieurs afficheurs.

1.2.2. Alimentation par VIN
Il est pratiquement impossible de piloter un grand nombre de ces afficheurs en alimentant un ARDUINO par VIN pour ensuite alimenter les afficheurs par la broche 5V.
Je vous renvoie à cet article :
Voir le paragraphe 3.2. Broche VIN.

Si l’on alimente l'ARDUINO en 7.5V, le courant maximal disponible sur la broche 5V sera de 480mA.

1.2.3. Alimentation dédiée
Pour piloter un grand nombre d'afficheurs il serait préférable d'alimenter les afficheurs directement en 5V à l'aide d'une alimentation dédiée de puissance suffisante. Le microcontrôleur pourra également être alimenté directement en 5V à l'aide de la même alimentation.

Sur les modules quadruples (256 LEDs) en ma possession le courant maximal (toutes les LEDs allumées à luminosité maximale) est égal à 650mA, c'est à dire 160mA par module, donc 2.5mA par LED. Pendant la phase de maquettage j'alimente les afficheurs avec une alimentation 5V séparée, afin d'éviter de surcharger le port USB sur lequel est branché l'ESP32.

Pour un projet définitif il faut faire un bilan sérieux des consommations. Exemple avec 2 afficheurs quadruples + ESP32 :
  • connexion WIFI ESP32 : 450mA maxi
  • ESP32 connecté : 120mA maxi
  • affichage plein sur un seul afficheur (test des LEDs au démarrage) :
    • 1 afficheur : 650mA
    • ESP32 : 120mA
  • affichage de texte sur deux afficheurs
    • 2 afficheurs : 500mA
    • ESP32 : 120mA
La consommation ne devrait pas excéder 770mA au démarrage pendant quelques secondes, et retomber à 620mA ensuite. Une alimentation 5V 1A sera nécessaire.
Si toutes les LEDs des deux afficheurs étaient allumés simultanément au démarrage il faudrait plutôt opter pour une alimentation pouvant débiter au minimum 1.5A.

Attention : une alimentation à découpage ne se comporte pas comme une alimentation linéaire.
Une alimentation linéaire peut encaisser une surcharge de faible durée sans problème car la protection de son régulateur est souvent thermique, donc lente.
Une alimentation à découpage provoque une coupure de sa sortie au moindre dépassement de son courant maximal, même bref.

1.3. Découplage

Il arrive qu'aléatoirement un ou plusieurs afficheurs n'affichent plus rien si la luminosité devient élevée, dans le cas où l'on conçoit un logiciel capable de régler celle-ci par exemple. Il s'agit probablement de pics de courant générant des baisses de tension d'alimentation et qui plantent le MAX7219.

Après différents essais, pour 8 afficheurs j'obtiens de bons résultats avec une luminosité moyenne en connectant un condensateur de 220µF en parallèle sur l'alimentation des afficheurs, entre VCC et GND.
La valeur de ce condensateur monte à 3300µF si je veux afficher sans problème des carrés pleins à luminosité maximale sur seulement 4 afficheurs.

Cette valeur est bien entendu à ajuster en fonction :
  • du nombre d'afficheurs
  • du type d'alimentation, de sa puissance
  • de la longueur des câbles d'alimentation, de leur section
Il est également possible de placer plusieurs condensateurs de plus faible valeur sur chaque afficheur ou chaque groupe d'afficheurs.

Après mise en place des condensateurs il faut tester le montage avec un petit sketch qui affiche des informations suffisamment représentatives de ce que l'on compte afficher.

2. Le logiciel

2.1. Orientation

Il faut faire attention lors de l'achat à choisir les modules en fonction de ce que l'on désire afficher. Classiquement lorsque l'on chaîne plusieurs modules en ayant l'intention d'y afficher du texte on a tendance à les aligner horizontalement, sur une ou plusieurs lignes.

On constate assez vite que l'on va se retrouver confrontés à deux problèmes :
  • un problème d'orientation de chaque module
  • un problème d'ordre des modules entre eux
La plupart des librairies considèrent que le pixel 0:0 se trouve dans le coin supérieur gauche, lorsque les broches d'entrée sont situées sur le dessus du module.
Mais il est parfaitement possible qu'un constructeur puisse choisir une orientation différente, et comme les vendeurs ne précisent pas ce genre de détail il est donc difficile de savoir comment orienter les modules sans les essayer.

Les librairies considèrent également que les modules sont chaînés de la droite vers la gauche. Si cet ordre est inversé, la chaîne ABCD sera affichée DCBA.

Pour résumer, lorsque l'on chaîne plusieurs modules ensemble, il est plus que probable que l'on obtienne un affichage mal orienté ou inversé.

Lorsque l'on dispose de modules unitaires il est facile de les disposer côte à côte et de les chaîner pour obtenir un affichage correct des caractères.

A noter que les modèles CMS offriront 4 possibilités d'orientation, ce qui ne sera pas le cas des modèles DIP. Les modèles DIP ne permettront pas non plus d'accoler les afficheurs sur plus d'une ligne, à moins de tolérer un interligne.

On ne peut donc que recommander l'achat de modules CMS simples et de les combiner selon la librairie utilisée.

Mais que se passe t-il avec un module quadruple ? Là aussi tout dépend du constructeur, et de la librairie choisie. Si ces modules sont chaînés de droite à gauche et que la librairie ne permet pas de changer l'orientation, le résultat sera celui-ci :


Il peut probablement arriver que la combinaison modules / librairie ne donne pas de résultat satisfaisant.

Il existe un certain nombre de librairies permettant de gérer ces afficheurs. Malgré tout la seule qui permette de choisir l'orientation des modules est celle-ci :

Cette autre librairie sera nécessaire :

La librairie MD_PAROLA permet de choisir entre 4 orientations :
  • PAROLA_HW : chaînage horizontal affichage inversé (en miroir)
  • GENERIC_HW : chaînage vertical
  • ICSTATION_HW : chaînage horizontal gauche-droite
  • FC16_HW : chaînage horizontal droite-gauche
La majeure partie des blocs de 4 afficheurs vendus sur ALIEXPRESS se pilotent en utilisant le paramètre FC16_HW :

La librairie possède pas mal de fonctionnalités utiles :
  • scrolling horizontal et vertical
  • justification à gauche, à droite, au centre
  • réglage de l'espace inter-caractères
  • gestion de zones d'affichage séparées
  • etc.
Une autre librairie fonctionne avec les blocs de 4 afficheurs chaînés de droite à gauche, celle de Nick Gammon :

D'autres librairies ne fonctionneront qu'avec des afficheurs simples chaînés de bas en haut avec des fils :

Il faut avouer que dans le monde des librairies MAX7219 c'est un peu la jungle.
Il est important d'évaluer les possibilités de quelques unes afin de ne pas s'engager dans une voie sans issue qui ne permettrait pas d'obtenir le résultat escompté.

2.2. Le bus SPI

La librairie MD_PAROLA permet de piloter l'afficheur en utilisant soit le bus SPI natif du microcontrôleur soit un bus SPI émulé (bitbanged SPI).
Dans le premier cas on reliera l'afficheur aux pins SPI du microcontrôleur :
  • DIN : MOSI (D11 sur un ARDUINO)
  • CLK : CLK (D13 sur un ARDUINO)
  • CS : SS (D10 sur un ARDUINO) ou un autre choix
Dans le deuxième cas, le choix des broches est libre, mais la communication sera moins rapide.

Exemple :
// Hardware SPI connection
MD_Parola P = MD_Parola(MD_MAX72XX::FC16_HW, CS_PIN, MAX_DEVICES);

// Arbitrary output pins
MD_Parola P = MD_Parola(MD_MAX72XX::FC16_HW, DATA_PIN, CLK_PIN, CS_PIN, MAX_DEVICES);

MAX_DEVICES représente le nombre d'afficheurs à chaîner.

Dernière chose, cette librairie fonctionne aussi bien avec un ARDUINO qu'avec un ESP8266 ou un ESP32.

2.3. Afficher des messages

La librairie MD_PAROLA, comme beaucoup d'autres d'ailleurs, ne recopie pas les messages qu'on lui demande d'afficher. Il s'en suit que ces chaînes de caractères doivent être impérativement stockées dans des variables globales ou statiques.
Une variable locale à une fonction ne conviendra pas, car son contenu n'est pas persistant.

2.4. L'UTF8

Moyennant la création d'une police de caractères adaptée et d'une petite fonction de conversion il est parfaitement possible d'afficher des caractères accentués.
Cette police est fournie dans l'exemple Parola_UFT-8_Display.

Le code de conversion :

2.5. Affichage clignotant

On pourrait bêtement penser qu'il suffit d'afficher un espace à la place des deux points d'une horloge toutes les deux secondes pour obtenir 2 points clignotants.
Il n'en est rien.
Cela marcherait avec une police de largeur fixe, celle de la librairie est à largeur variable.
Le caractère ':' fait 1 pixel de large, l'espace en fait deux. On obtiendrait donc un affichage dont la largeur change toutes les secondes, peu esthétique.

Il faut donc créer un espace simple dans notre police de caractères. J'ai utilisé le caractère 31 (0x1F) pour cet usage (l'espace étant le 32).

  1, 0,      // 31 - 'Small space'
  2, 0, 0,        // 32 - 'Space'


Il suffit donc d'utiliser ce caractère pour afficher un espace étroit à la place des 2 points, toutes les 2 secondes :

  static char timeString[10];
  struct tm timeinfo;
      // ...
      getLocalTime(&timeinfo);
      if (timeinfo.tm_sec % 2) {
        strftime(timeString, sizeof(timeString), "%H:%M", &timeinfo);
      }
      else {
        strftime(timeString, sizeof(timeString), "%H\x1f%M", &timeinfo);
      }
      hDisplay.displayText(timeString, PA_CENTER, 0, 0, PA_PRINT, PA_NO_EFFECT);


3. Le projet

Le petit projet exemple se propose d'implémenter une horloge sur la base d'un ESP32, avec les fonctionnalités suivantes :
  • affichage heure + minutes avec 2 points clignotants.
  • affichage de la date configurable :
    • jour de la semaine + jour du mois
    • jour + mois
    • jour + mois + année + saint du jour (avec scrolling)
  • luminosité réglable
  • gestion de l'heure par NTP avec changement d'heure été / hiver
  • configuration par 2 touches sensitives
  • configuration sauvegardée en FLASH
  • serveur WEB (brouillon)
La totalité des LEDs des deux afficheurs (afficheur de l'heure puis l'afficheur de la date) sont allumées au démarrage pendant une seconde chacun.

Le saint du jour est obtenu grâce au même moyen que sur le projet Afficheur TFT pour ESP8266 :
Voir paragraphe 5.1. Le service PHP.

Il conviendra d'adapter l'URL dans le fichier ephemeris.cpp si cette option est utilisée, sinon on la remplacera par une chaîne vide.

Le serveur WEB de l'ESP32 (vide pour le moment) pourra servir de page de configuration :
  • URL du serveur NTP
  • URL du serveur saint du jour
  • heure de réveil, d'alarme, etc.
  • etc.
Les deux afficheurs 4x8x8 sont câblés comme suit :
  • CLK : GPIO18
  • DIN : GPIO23
  • CS : GPIO26 et GPIO25

Les deux blocs d'afficheurs ne sont pas chaînés, ils sont simplement pilotés en parallèle avec deux pins CS différentes.

L'ESP32 est un classique DEV-KIT mais n'importe quel modèle peut convenir.

4. L'ESP8266

Attention : le hardware SPI de l'ESP8266 utilise les broches D5 D7 D8 (GPIO14 GPIO13 GPIO15) :

On a tendance à oublier, dans le code, que la broche 5 est la GPIO5 et non pas D5.

#define CLK_PIN    D5   // et non pas 5
#define DATA_PIN  D7
   // et non pas 7
#define CS_PIN      D8   // et non pas 8

5. Téléchargement

Ce projet est disponible ici : 

6. Conclusion

Il faut bien avouer que ces afficheurs matriciel sont très attrayants. Ils permettent de réaliser des affichages visibles de loin et des animations intéressantes.

Il va sans dire que ce projet n'est qu'une première version appelée à évoluer.


Cordialement

Henri


jeudi 7 mai 2020

Avril 2020 : Actualité des Blogs du Mois



Actualité des Blogs du Mois


Sur le blog d'Yves Pelletier :
Sur  Framboise 314 :
Sur  MCHobby :

Cordialement
Henri

Le SC16IS750 : UART avec 8 GPIOs



Le SC16IS750 : UART avec 8 GPIOs


Aujourd'hui je partage une petite découverte récente : le SC16IS750.

Il s'agit d'un circuit permettent d'ajouter une ligne série et 8 GPIOs à un microcontrôleur, un ARDUINO par exemple.

On ne trouve pas énormément d'informations à propose de ce circuit sur le WEB. C'est une bonne raison pour l'essayer et faire un tutoriel.

Il a les caractéristiques suivantes :
  • alimentation 3.3V
  • consommation 30µA en standby
  • entrées tolérantes au 5V
  • pilotage en I2C
    • I2C 400 kbit/s
    • 2 broches d'adresse I2C
  • pilotage en SPI
    • 4 Mbit/s
  • UART : RX / TX avec lignes CTS RTS
    • baud rate jusqu'à 5 Mbit/s
    • contrôle de flux RTS/CTS
    • possibilité de configuration de 4 pins en RI, CD, DTR, DSR
    • RS485
  • 8 GPIOs bidirectionnelles
    • courant de sortie 10 mA maxi
    • sans résistances de pull-up ou pull-down
Comme on le voit son baud rate maximal sera bien supérieur à ce que donnera un objet SoftwareSerial.

Il existe des modules sur AliExpress, coûtant environ 3€.

Ces modules comportent un régulateur 3.3V. C'est un MIC5219 (marquage LG33) qui accepte au maximum 20V sur son entrée.
Il peuvent donc être alimentés en 5V ou 12V sans problème.

1. Le fonctionnement en I2C



Sur ce schéma les deux broches d'adresse sont reliées au +5V. Le circuit possède 16 adresses possibles (voir paragraphe 10.3 Addressing de la datasheet).

Pour le test l'entrée RX est rebouclée sur TX, le SC16IS750 reçoit donc ce qu'il émet.

Le sketch suivant permet de tester le montage :

#include <SC16IS750.h>

SC16IS750 i2cuart = SC16IS750(SC16IS750_PROTOCOL_I2C, SC16IS750_ADDRESS_AA);

#define SIZE    64
#define LED     1

char xmit[SIZE + 1];
char rcv[SIZE + 1];

void setup()
{
  Serial.begin(115200);
  i2cuart.begin(230400);
  i2cuart.pinMode(LED, OUTPUT);
  i2cuart.digitalWrite(LED, LOW);
  if (i2cuart.ping() != 1) {
    Serial.println("device not found");
    while (1);
  } else {
    Serial.println("device found");
  }
  Serial.println("start serial communication");
  memset(xmit, 'A', SIZE);
  xmit[SIZE] = 0;
}

void loop()
{
  static int count;

  i2cuart.print(xmit);
  while (i2cuart.available() == 0);
  memset(rcv, 0, SIZE);
  i2cuart.readBytes(rcv, SIZE);
  rcv[SIZE] = 0;
  Serial.print(rcv);
  if (memcmp(rcv, xmit, SIZE)) {
    Serial.print("\nError");
  }
  Serial.print("\nInputs: ");
  Serial.println(i2cuart.GPIOGetPortState(), HEX);
  if (++count == 10) {
    i2cuart.digitalWrite(LED, HIGH);
    delay(100);
    i2cuart.digitalWrite(LED, LOW);
    count = 0;
  }
}


Le logiciel compare ce qu'il a reçu avec ce qu'il a émis. Je n'ai pas vu d'erreur à l'affichage.

La LED clignote à chaque fois que 10 messages ont été émis et reçus. L'état des entrées est affiché en continu.

2. Le fonctionnement en SPI


Attention la broche N°1 (I2C-SPI) passe à GND au lieu de +5V. A part cela le câblage SPI est classique.

La broche chip select (CS) peut bien sûr être reliée à une autre broche de l'ARDUINO (ici : la 10).

Voici le sketch :

#include <SC16IS750.h>

SC16IS750 i2cuart = SC16IS750(SC16IS750_PROTOCOL_SPI, 10);

#define SIZE    64
#define LED     1

char xmit[SIZE + 1];
char rcv[SIZE + 1];

void setup()
{
  Serial.begin(115200);
  i2cuart.begin(230400);
  i2cuart.pinMode(LED, OUTPUT);
  i2cuart.digitalWrite(LED, LOW);
  if (i2cuart.ping() != 1) {
    Serial.println("device not found");
    while (1);
  } else {
    Serial.println("device found");
  }
  Serial.println("start serial communication");
  memset(xmit, 'A', SIZE);
  xmit[SIZE] = 0;
}

void loop()
{
  static int count;

  i2cuart.print(xmit);
  while (i2cuart.available() == 0);
  memset(rcv, 0, SIZE);
  i2cuart.readBytes(rcv, SIZE);
  rcv[SIZE] = 0;
  Serial.print(rcv);
  if (memcmp(rcv, xmit, SIZE)) {
    Serial.print("\nError");
  }
  Serial.print("\nInputs: ");
  Serial.println(i2cuart.GPIOGetPortState(), HEX);
  if (++count == 10) {
    i2cuart.digitalWrite(LED, HIGH);
    delay(100);
    i2cuart.digitalWrite(LED, LOW);
    count = 0;
  }
}

Que dire de plus ? le sketch fonctionne comme le précédent, avec une vitesse bien supérieure, grâce au bus SPI comme on peut s'en douter.

3. La librairie

On peut télécharger la librairie ici :


4. Conclusion

Voici un petit module facile à mettre en œuvre qui pourra offrir une solution de choix aux personnes ne désirant pas changer leur ARDUINO UNO, NANO ou PRO MINI pour une MEGA, pour des raisons diverses et variées : encombrement, consommation, etc.
Ce test a été réalisé avec une PRO MINI 8MHz, alimentée en 3.3V et 5V. Les deux fonctionnent.

Quelques remarques :
  • ces tests ont été effectués à 230400 baud, mais rien ne s'oppose à ce que l'on adopte une vitesse supérieure (j'ai testé avec succès à 921600 baud).
  • les lignes SDA et SCL possèdent des résistances de pull-up internes
  • la méthode digitalRead() ne fonctionne pas (probablement un bug de la librairie)
    • la méthode GPIOGetPortState() permet de lire les 8 entrées à la fois dans un byte, et donc de s'en sortir.
  • il est possible de lire une GPIO si elle est configurée en sortie (comme sur un ARDUINO)
  • la limite de 64 octets des buffers du sketch est une limite de la librairie ARDUINO. Si l'on veut émettre ou recevoir plus d'octets, il faudra le faire en plusieurs fois.

Cordialement
Henri

dimanche 3 mai 2020

Porte Motorisée de Poulailler (3ème Partie)




Porte Motorisée de Poulailler (3ème Partie)


Ceci est la suite des articles précédents :
Porte Motorisée de Poulailler (1ère Partie)
Porte Motorisée de Poulailler (2ème Partie)

Nous allons parler aujourd'hui plus en détail de la réalisation électronique. Celle-ci va être découpée en deux parties :
  • la carte alimentation
  • la carte de commande
La carte alimentation regroupe tous les organes de puissance.

1. Les schémas

1.1. La carte de puissance

1.1.1. Alimentation sur batterie

Carte alimentation
Carte alimentation


Les schémas sont réalisés à l'aide de KICAD.

Pour récupérer le projet voir plus bas :  5. Téléchargements.

En fonction de l'option choisie (moteur continu ou servomoteur) cette carte sera pourvue de différents composants.

Les composants suivants sont communs aux deux solutions :
  • batterie
  • TP4056
  • MP1584 5V (sauf panneau solaire 5V ou 6V)
  • Q2 : transistor de commande de puissance
  • XR2981 : convertisseur 5V pour l'ARDUINO
  • P1 connecteur panneau solaire
  • P2 : connecteur pour la carte de commande
  • Q3 + Q4 :  transistors de commande du chargeur
1.1.1.1. Version à servomoteur
Les composants suivants sont prévus pour la version servomoteur :
  • FP6293-5V : convertisseur 5V pour le servomoteur
  • P3 : connecteur MG996R
1.1.1.2. Version à moteur continu
Les composants suivants sont prévus pour la version moteur continu :
  • MT3608 ou SX1308 : convertisseur de tension pour le moteur
  • L293D : pont en H 
  • R8 : résistance de mesure du courant moteur
  • P4 connecteur moteur
  • Q1 : transistor de commande de l'alimentation VCC1 du L293D
Dans sa version à moteur à courant continu la carte est prévue pour recevoir un convertisseur réglable au choix, soit un MT3608 soit un SX1308. Il sera réglé sur 12V ou une autre tension en fonction du moteur.
1.1.1.3. Détails
Comme on le voit sur le schéma j'ai prévu deux emplacements pour les batteries. Cela permettra d'utiliser soit 1 batterie de marque neuve, soit 2 batteries de moindre qualité ou même 2 batteries usagées.

Les deux transistors Q3 et Q4 permettent de connecter ou déconnecter le panneau solaire du chargeur TP4056. Le chargeur est coupé pendant la mesure de la tension du panneau solaire.Si l'option LDR est choisie ces deux transistors sont inutiles, on court-circuitera les pins 2 et 3 de Q3.

Un emplacement est prévu pour un circuit de mesure du courant du panneau, un INA138 suivi d'un amplificateur opérationnel :
Ce module me sera utile pour remonter les informations de courant de charge au serveur DOMOTICZ. Si cette option n'est pas envisagée il faudra court-circuiter les pins 5 et 6 sur la carte (U2 sur le schéma).

On voit également un jumper sur la borne + de la batterie. C'est un simple connecteur DUPONT mâle à deux broches. Celui-ci est utilisé pour la mesure du courant consommé à l'aide d'un câble relié au multimètre :


En fonctionnement normal un jumper doit être mis en place :
1.1.2. Alimentation secteur
Que ce soit dans sa version à moteur continu ou à servomoteur, le montage peut être alimenté par un simple chargeur de téléphone mobile 5V / 1A, à moins que le moteur soit très puissant, auquel cas il faudra adopter une alimentation adaptée.

Rappel : le moteur que je compte utiliser consomme 200mA sous 12V : 2.4W.

1.1.2.1. Version à moteur continu
Si l'on désire alimenter par le secteur il suffira d'un montage de ce type :
Ici aussi dans sa version à moteur à courant continu la carte est prévue pour recevoir un convertisseur réglable au choix, soit un MT3608 soit un SX1308. Il sera réglé sur 12V ou une autre tension en fonction du moteur.
Bien entendu ce montage peut être facilement réalisé sur une plaquette à pastilles.

Si le moteur choisi est un modèle 5V on pourra se passer de convertisseur et adopter tout simplement un module L293D du commerce :
Les branchements seront les suivants :
  • 0V de l'alimentation
    • GND du module L293D
    • GND de la carte de commande (broche 4)
  • +5V de l'alimentation
    • VCC et VIN du module L293D
    • +5V de la carte de commande (broche 6)
  • IN1 et IN2 du module L293D seront reliés à L293D-1A et L293D-2A de la carte de commande
  • le moteur sera relié à A- et A+ du module L293D

Par contre je déconseille totalement de relier un module L293D avec des fils DUPONT. C'est une source évidente de faux contacts. Il est préférable d'utiliser un boîtier DUPONT 8 contacts :

 
Avec des contacts appropriés (ci-dessous à droite) :


Il faudra une pince à sertir, ou bien souder les contacts sur les fils.

1.1.2.2. Version à servomoteur
Enfin, pour une version à servomoteur sur secteur, il n'y aura besoin d'aucune carte additionnelle. Les branchements seront les suivants :
  • 0V de l'alimentation
    • fil marron du servomoteur
    • GND de la carte de commande (broche 4)
  • +5V de l'alimentation
    • fil rouge du servomoteur
    • +5V de la carte de commande (broche 6)
  • orange : broche 11 de la carte de commande
Il faudra prévoir deux petits branchements en dérivation (un domino ou un petit bornier).

1.2. La carte de commande

Voici le schéma retenu pour la partie commande :

La carte de commande comporte tous les composants et modules basse puissance :

  • ARDUINO PRO MINI 5V 16MHz
  • SHT31D (optionnel)
  • DS3231 (optionnel)
  • NRF24L01 + régulateur HT7533-1 (optionnels)

Les entrées D2 et D3 sont réservées aux boutons d'ouverture et fermeture. Ce sont les seules à pouvoir réveiller le PRO MINI par interruption.

Sur l'entrée A3 on voit un capteur de fin de course pour la version à servomoteur, avec une résistance de PULL-UP de 1MΩ. Cette résistance remplace la PULL-UP interne de l'ATMEGA328, car la valeur de ces résistances internes est trop faible (20kΩ à 50kΩ) et cela occasionnerait une surconsommation lorsque le contact est fermé.

Sur l'entrée A0 un pont diviseur permet de mesurer la tension du panneau solaire. Ce pont est adapté à la mesure d'un panneau 12V (tension à vide environ 20V).

Sur l'entrée A1 un pont diviseur permet de mesurer la tension de la batterie.

La mesure sur ces entrées analogique est faite en utilisant la référence interne de l'ATMEGA328 : 1.1V. La valeur des ponts diviseurs est calculée pour obtenir une tension inférieure  1.1V :

  • 4.4V au maximum sur A0 : OK pour une batterie LITHIUM-ION 4.2V maxi
  • 24V au maximum sur A1 : largement suffisant pour un panneau 12V

Cette carte est reliée à la carte alimentation par un connecteur 11 points.

2. Les photos

La carte de commande (photo ajoutée récemment) :


Voici une photo de la carte de puissance :

En haut à gauche : le connecteur du panneau solaire.

Plus bas : le connecteur 11 points pour la carte de commande et le connecteur 3 points pour le MG996R.

Sur la photo la LED bleue du TP456 est allumée. La batterie est pleine.

J'utilise donc deux batteries chinoises. Elles sont vendues pour 6000mAH alors qu'elles n'en font que 1000, c'est dire le niveau de publicité mensongère.

La carte est équipée de tous les composants pour la version servomoteur, hormis la résistance noire 1W de mesure du courant moteur, inutile pour l'instant. Sous la résistance de 1W se trouve l'emplacement du futur L293D et du convertisseur MT3608 ou SX1308.

Les fonctionnalité suivantes sont assurées :

  • ouverture / fermeture
  • recharge de la batterie
  • mesure de la tension de la batterie
  • mesure de la luminosité (LDR)
  • mesure de la tension du panneau solaire
  • utilisation d'un capteur de fin de course haut

La coupure du panneau solaire pendant la mesure de la tension du panneau est particulièrement efficace. La luminosité pourra facilement être déterminée par ce moyen.

Par contre si un éclairage public est présent dans les parages cette solution sera inexploitable, qu'il s'agisse de mesure de luminosité par LDR ou à l'aide du panneau solaire.

Une sécurité a été ajoutée : après l'ouverture de la porte l'état du capteur de fin de course est contrôlé. S'il n'est pas vu en position haute, une deuxième tentative d'ouverture est lancée, et éventuellement une troisième.

Avec cette version sur PCB le couple moteur est nettement plus élevé qu'avec la version sur breadboard. Même en doublant le poids de la porte le moteur ne cale pas.

Ce n'est pas surprenant. La largeur des piste et les composants et connecteurs soudés contribuent grandement à ce résultat.

La tension de la batterie, qui est de 4.18V à vide, chute à 4.07V pendant l'ouverture de la porte. Sur breadboard il est impossible d'obtenir un résultat équivalent.

A noter : le routage de la carte est fait en double face, mais il est également possible de le graver en simple face (à la CNC par exemple) et de souder des straps pour remplacer les pistes de la face supérieure.

La carte se prête particulièrement bien à la gravure à l'anglaise côté recto. Elle est pourvue d'un large plan de masse.

Il est également possible de la réaliser sur une plaquette à pastilles d'environ 100mm x 100mm, avec des fils rigides de section suffisante pour la partie puissance :

  • batteries
  • TP4056
  • convertisseur FP6293
  • transistor Q1
  • etc.

Les parties faible puissance peuvent se contenter de fil à wrapper.

La carte de commande également peut éventuellement être réalisée sur une plaquette à pastilles, mais elles est plus complexe.

4. Mesures

D'après les premiers essais avec ce servomoteur, j'observe que la batterie fournit une pointe de courant de plus d'1A à mi-ouverture de la porte, lorsque le bras de levier se trouve à l'horizontale, la position où il force le plus. Cela équivaut à environ 4W puisque la batterie a une tension de 4V pendant l'ouverture. Sous 5V le courant moteur devrait donc être de 800mA, c'est qui est très raisonnable.

Comme dit plus haut : même en doublant le poids de la porte le moteur ne cale pas. Il consommera plus de courant mais le temps d'ouverture est suffisamment court pour éviter un échauffement excessif.

Contrairement à ce qui se passait sur breadboard je n'ai pas observé de blocage moteur lors de l'ouverture de la porte.

4. Avancement

4.1. 04/05/2020

Le module RTC DS3231 a été ajouté.

Le calcul de l'heure de lever et de coucher du soleil et donc d'ouverture et de fermeture de la porte est effectué à l'aide d'une API disponible dans la librairie standard ARDUINO :

#include <time.h>
    time_t          sun_rise(const time_t * timer);

    time_t          sun_set(const time_t * timer);

C'est simple et efficace, et cela peut éviter les aléas liés à une variation de luminosité indésirable, due à un éclairage public par exemple.

Bien entendu on peut changer l'heure et la date à l'aide de la console ou d'un terminal quelconque. Il faut donc un convertisseur USB / série branché sur l'ARDUINO MINI.

Comme l'ARDUINO est en sommeil, pour changer l'heure ou la date il faut le réveiller. Pour cela j'utilise une petite astuce :
Si la porte est ouverte appuyer sur le bouton ouvrir. Si la porte est fermée appuyer sur le bouton fermer. Comme la porte est déjà ouverte ou fermée, le logiciel entre dans un mode éveil pendant un certain temps : 30 secondes, le temps nécessaire pour entrer une petite commande sur la console :

date May 04 2020
time 16:25:00

Attention : bien respecter le format. Le jour doit être sur deux chiffres, tout comme l'heure, les minutes et les secondes.

Le mois doit être entré en abrégé :

Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, ou Dec

L'heure doit être entrée en valeur UTC (GMT). C'est important car il n'y a pas de gestion de changement d'heure été / hiver. De plus la librairie calcule les heures de lever et de coucher du soleil en temps UTC, donc le DS3231 doit obligatoirement donner l'heure UTC.
Il faudra donc entrer l'heure courante moins 2 heures en été, et l'heure courante moins 1 heure en hiver.

Le DS3231 est très précis, il possède un oscillateur interne calibré et compensé en température. Il dérivera très peu. On peut parier que l'heure restera exacte même après un an d'utilisation, à quelques secondes près.

Je n'envisage pas d'alternative du genre PCF8523, DS1307 ou autre. La précision de ces modules est trop dépendante de leur fabrication, en particulier du quartz utilisé, et de plus ils dériveront forcément beaucoup plus qu'un DS3231 en fonction de la température.

Un détail : certains modules DS3231 sont équipés d'une LED allumée en permanence. Elle doit être retirée afin d'éviter cette consommation inutile, environ 4mA. On peut la dessouder ou la faire sauter à l'aide d'une pince coupante.

Après retrait de la LED le module DS3231 consomme tout de même 800µA, ce qui va porter notre consommation totale à environ 1mA.
Cela ne m'inquiète pas étant donné que cela nous laisse tout de même 2500 heures d'autonomie avec une batterie de 2500mAH, c'est à dire plus de 3 mois.

4.2. 06/05/2020

4.2.1. Le NRF24L01
Le module NRF24L01 a été ajouté.

Le système remonte bien les informations :
  • porte ouverte ou fermée
  • état de charge de la batterie
  • tension du panneau solaire
Il reçoit également la date et l'heure de la part du serveur DOMOTICZ.

La mauvaise nouvelle est que la librairie time standard C ne gère pas l'heure de manière automatique, il faut la mettre à jour toutes les secondes à l'aide d'un appel à la fonction system_tick(). Comme l'ARDUINO est endormi pendant de longues périodes, cela ne sera pas possible.

Il est à noter que la fonction millis() ne fonctionne pas non plus pendant les périodes de sommeil. J'ai déjà été contraint de gérer certains aspects temporels en comptant le nombre de secondes d'endormissement à l'aide d'un compteur.

Le circuit RTC DS3231 doit donc être conservé. On pourra récupérer l'heure du serveur DOMOTICZ une fois par mois pour mettre à jour le DS3231, ce sera amplement suffisant.

Ici deux copies d'écran DOMOTICZ :

Historique des ouvertures et fermetures

Dispositifs

Sur la page dispositifs on voit la porte, la tension du panneau, le capteur de température & humidité, avec la capacité de la batterie.


4.2.2. Le SHT31D
Un capteur de température et humidité SHT31D a été également ajouté.
Ces informations sont également remontées au serveur.

5. Options

Le logiciel étant bien avancé il est largement utilisable.

Le fichier options.h regroupe toutes les options. Actuellement la configuration par défaut est :
  • servomoteur
  • pas de capteur de température
  • ouverture et fermeture en fonction du panneau solaire
  • réveil toutes les 30 secondes
  • utilisation du capteur de fin de course haut
Les options sont facilement modifiables. Il suffit de changer quelques constantes :
  • moteur :
    • #define MOTOR             SERVO_MOTOR : version servomoteur
    • #define MOTOR             DC_MOTOR : version moteur continu (non disponible actuellement)
  • capteur de température :
    • #define SENSOR      NONE : aucun
    • #define SENSOR      HDC2080 : utilisation d'un HDC2080
    • #define SENSOR      SHT31D : utilisation d'un SHT31D
    • #define SENSOR      HTU21D : utilisation d'un HTU21D
  • ouverture et fermeture :
    • #define OPEN_CLOSE_METHOD USE_PANEL : utilisation du panneau solaire comme capteur de luminosité
    • #define OPEN_CLOSE_METHOD USE_LDR : utilisation d'une LDR comme capteur de luminosité
    • #define OPEN_CLOSE_METHOD USE_RTC : utilisation d'un circuit RTC
    • #define OPEN_CLOSE_METHOD USE_DOMOTICZ : utilisation d'un circuit RTC + DOMOTICZ
  • réveil
    • #define SLEEP_TIME        30 : réveil toutes les 30 secondes
  • utilisation du capteur de fin de course haut :
    • #define USE_LIMIT_SWITCH : avec capteur
    • //#define USE_LIMIT_SWITCH : sans capteur
La LDR sera reliée à la carte par un connecteur, donc facilement exposée à la lumière à travers un trou de 5mm dans la paroi extérieure.

L'option RTC nécessite l'approvisionnement d'un circuit RTC DS3231.

L'option DOMOTICZ requiert un module NRF24L01 (avec son régulateur HT7533-1) et également un DS3231.

Le capteur de température qui sera implanté sur la carte sera un SHT31D alimenté en 5V.
La modification du schéma et du routage pour implanter un HDC2080 ou un HTU21D est minime. Ce sont tous des composants I2C.
Attention à l'alimentation du HDC2080 ou un HTU21D qui est de 3.3V (le régulateur HT7533-1 sera nécessaire).
Si la carte est réalisée sur une plaquette à pastilles la modification sera encore plus aisée.

Il y a d'autres options moins importantes :
  • les horaires été / hiver (France par défaut)
  • la latitude et longitude ( à renseigner si l'option RTC est utilisée)
  • TIME_REQUEST_PERIOD : la période de demande de l'heure au serveur DOMOTICZ (30 jours par défaut)
  • MANUAL_TIMEOUT : le temps maximal au bout duquel l'ouverture et fermeture automatique reprend le contrôle après une action manuelle
  • MANUAL_WAKEUP : le temps de réveil pour la saisie de l'heure avec un terminal

6. Téléchargements

Cette troisième version est disponible ici : 

https://bitbucket.org/henri_bachetti/mysensors-gate/src/v0.3/

Le code prévu pour un moteur continu n'est bien entendu pas finalisé.

7. Liens utiles

La quatrième partie : le moteur continu
https://riton-duino.blogspot.com/2020/06/porte-motorisee-de-poulailler-4eme.html

8. Conclusion

Il me semblait indispensable de ne pas continuer à faire du prototypage sur breadboard pour la partie puissance. Le résultat est là et il est très encourageant.

Les différentes options fonctionnent et donnent un résultat très satisfaisant.
J'ai une légère préférence pour la solution à horloge RTC avec calcul du lever et coucher du soleil, qui sera forcément moins tributaire de la luminosité ambiante, éclairage de rue en particulier.

Je recommande particulièrement l'utilisation du capteur de fin de course haut. Depuis que je l'ai mis en place le comportement est plus rationnel, en particulier lors des redémarrages.

L'occupation mémoire de la PRO MINI est assez rassurant (avec les options DOMOTICZ + capteur de température activées) :
  • 74% de l'espace en mémoire FLASH
  • 51% de l'espace en RAM
C'est fou ce que l'ont peut faire avec ces petites cartes.


Cordialement
Henri

6. Mises à jour

04/05/2020 : ajout du DS3231
06/05/2020 : ajout du NRF24L01 et SHT31D