Microcontrolleur - Alimentation pile

[inviteb421e572]

Bonjour,

Je vous écris car je souhaite alimenter un microcontrôleur (atmega328P) par le biais de 3 pile AA de 1.5V

J'ai quelques capteurs qui doivent être alimenter, et qui peuvent l’être entre 3V et 5.5V.

J'ai besoin de prolonger l’autonomie au maximum.

Ma question est : dois je tout alimenter en 4.5V (3*1.5V) ou je prends un régulateur type buck converter (TPS560200) afin de rabaisser ma tension à 3.3V et réduire ainsi mes consommations.

Sinon quel composant ou type de montage me conseillez vous pour alimenter mon micro à partir de trois piles AA 1.5V.

Je vous remercie d'avance.
-----

[jiherve]

Bonjour et bienvenue.
Je te conseillerais plutôt une alimentation par accu NiMh (4) au final cela sera plus économique.Il faudra prévoir un petit LDO pour limiter la tension à environ 4,2V pour encaisser la tension à pleine charge des accus.
JR

[vincent66]

Bonjour et bienvenue sur futura!
Le micro aura besoin d'une tension régulée stable et constante...
Comme suggéré par jiherve il faudra un ldo...
Vincent

[inviteb421e572]

Tout d'abord merci pour vos réponses rapide.
Je vais vous expliciter un peu mon projet parce que je bloque pour l'alim.
Je veux réaliser une station météo à base de microcontrôleur.
Je dispose d'un microcontrôleur atmega328p et mes capteurs sont :

• Une LDR (entrée ADC du micro)
• Un capteur de monoxyde de carbone MQ-7 (entrée ADC du micro)
• Un capteur numérique de température et humidité HTU21D (bus I2C pour liaison au micro)
• Un potentiomètre de réglage (entrée ADC du micro)

Un emetteur RF433 modulation ASK (sur TX du micro)
Un connecteur ISP 6 broche pour la programmation.

J'ai la contrainte imposée d'utiliser 3 ou 4 pile AA

Avec un LDO si je sors du 3.3V je pourrais alimenter mon micro, ma RF et les entrées analogique (via diviseur de tension) ?
Quand au mq7 après avoir vu 5 datasheet j'ai l'impression qu'il faut l'alimenter en 5V
Et j'aimerais par la suite couper l'alim des capteurs pour un envois de données toutes les 5 minutes.

Je sais pas trop comment m'y prendre, j'aurais un schéma a vous présenter en fin de journée, mais je suis prêt à recevoir vos conseilles.

Cordialement,

[A voir en vidéo sur Futura]

[PA5CAL]

Bonjour

En l'état, on ne peut pas évaluer l'autonomie des piles, ni le gain (ou la dégradation) que pourrait apporter un convertisseur à découpage.

En effet, on ne connaît pas la consommation globale de courant de l'appareil, ni la tension minimale à fournir (elle est au moins de 3V, mais pourrait être plus élevée du fait de la fréquence d'horloge de l'ATmega328P par exemple). D'ailleurs, on ne sait même pas si l'application nécessite que la tension d'alimentation soit contrôlée, et le cas échéant avec quelle précision (note qu'assez souvent, on peut se contenter d'une alimentation filtrée mais non régulée).

Si le choix doit se porter sur autre chose que des piles alcalines, alors selon la technologie de la source d'énergie, la température d'utilisation et les courants de fuite peuvent avoir une influence plus ou moins marquée sur l'autonomie.

Il est peut-être aussi nécessaire de garantir un minimum de sécurité (risques d'incendie ou d'explosion en cas de défaut).

Bref, le choix raisonné d'une source d'alimentation dépend énormément du contexte d'utilisation, lequel n'est absolument pas précisé ici.

Il faudrait donc donner plus de détails sur le projet pour pouvoir répondre sérieusement.

[PA5CAL]

D'après la doc du capteur MQ-7, il faut fournir une tension de 5V±0,1V durant 60s et de 1,4V±0,1V durant 90s pour alimenter une résistance de chauffage de 33 Ω. Celle-ci consommerait environ 350mW.

Ce seul capteur fixe déjà un bon nombre de contraintes.

Si l'on se limite effectivement à 4 éléments AA, un convertisseur Buck ne convient pas, puisque 4 piles alcalines ne pourront pas fournir bien longtemps la tension requise par le convertisseur/régulateur, et 4 batteries au nickel ne l'atteignent même pas.

Il faudrait donc plutôt s'orienter vers un convertisseur "step-up" pour le 5V, et étudier de plus près la façon de fournir d'une part la tension de 1,4V et d'autre part l'alimentation des circuits numériques.

[jiherve]

Bonsoir,
@Pa5cal : quel calcul fais tu?
Supposes tu une alimentation permanente du capteur?
JR

[inviteb421e572]

Merci encore pour vos réponses.
Je pense que je vais me passer du MQ-7, cela me permettra de tout alimenter en 3.3 V et de réduire considérablement ma consommation.
Ainsi un simple LDO me permet de passer des 4.5V de la pile à une tension de 3.3V garantie stable. C'est bien ça ?
Sinon je pensé que le buck (régulateur à découpage ?) était plus efficace (meilleur rendement => plus d'autonomie pour mes piles) qu'un LDO pour abaisser la tension de 4.5V à 3.3V

Les piles AA sont imposé dans mon cahier des charges (car les personne lambda en on souvent et elles sont pas cher mais c'est sur que à long terme ça reviens plus cher bien sur)

Désolé pour mes faibles connaissances je suis en formation et je débute..

Merci

[PA5CAL]

@Pa5cal : quel calcul fais tu?
Supposes tu une alimentation permanente du capteur?

Un cycle de chauffage prend 2,5 mn, et les données sont émises toutes les 5 mn. Que l'alimentation soit permanente ou périodique, à un facteur 2 près l'autonomie va rester du même ordre de grandeur.

La tension obtenue avec 4 piles alcalines AA de 1,5V est de 6V quand les piles sont neuves, mais passe au-dessous de 5V et devient donc insuffisante après une heure et demie (fonctionnement intermittent) ou trois quarts d'heure (fonctionnement continu).

[jiherve]

Re
oui tu as raison.
JR

[PA5CAL]

Ainsi un simple LDO me permet de passer des 4.5V de la pile à une tension de 3.3V garantie stable. C'est bien ça ?

Le régulateur garantit une régulation, c'est-à-dire le fait que la tension de sortie restera dans un intervalle très réduit. On lui adjoint des condensateurs pour absorber les pointes de courant et éviter son entrée en oscillation. On peut donc dire qu'il participe grandement à la stabilité de la tension de sortie.

Mais la stabilité, c'est le fait que la tension ne varie pas rapidement. Il n'est pas besoin d'utiliser un régulateur pour cela, le filtrage de la tension par condensateur pouvant être suffisant.


Réguler la tension peut être intéressant si l'on a besoin d'une référence de tension (cela peut éviter d'en rajouter une dans le montage).

Par ailleurs, abaisser la tension permet de réduire la consommation de courant des circuits numériques. Toutefois, les régulateurs consomment eux-mêmes du courant, et nécessitent une différence de tension minimale entre l'entrée et la sortie pour pouvoir fonctionner (elle est plus faible sur les LDO que sur les modèles classiques, mais non nulle). Il faudrait donc choisir un régulateur LDO de sorte que le gain réalisé par l'abaissement de la tension ne soit pas annulé par sa consommation de courant et pas la perte d'autonomie des piles résultant de la chute de tension entrée-sortie.

De plus, pour l'ATmega328P, il faut veiller à choisir une horloge inférieure à 13,3 MHz, qui est la fréquence maximale autorisée pour une alimentation de 3,3V.

Sinon je pensé que le buck (régulateur à découpage ?) était plus efficace (meilleur rendement => plus d'autonomie pour mes piles) qu'un LDO pour abaisser la tension de 4.5V à 3.3V

Un régulateur à découpage peut avoir un rendement exécrable si le courant est trop faible ou trop fort, ou si la différence de tension entre l'entrée et la sortie est trop faible. En certaines circonstances, un régulateur statique "low power" peut donner de biens meilleurs résultats.

Quoi qu'il en soit, on ne peut rien dire a priori. Il faut calculer les conditions réelles de fonctionnement (consommation de courant, évolution des tensions) pour pouvoir faire la comparaison, puis conclure en connaissance de cause.

[PA5CAL]

(il faut lire "... et par la perte d'autonomie des piles résultant ...")

[inviteb421e572]

Bonjour,

Merci PASCAL pour vos réponse. Je suis donc en train de définir les différents régimes de fonctionnement avec les consommations, mais celle de mon microcontrôleur me pose problème, j'ai réalisé qu'un dès paramètres fondamental pour réduire la consommation de mon système et la fréquence de fonctionnement du micro. Et après avoir décortiqué les datasheet de ma puce RF 433 (MICRF112) et du capteur Temp/Hum i2C (HTU21D) je ne voit pas de limite basse de fréquence fournis par le CPU. Les infos que j'ai vu sont Freq SCL max 0.4 Mhz pour le capteur et un oscillateur de référence pour la RF compris entre 9.375MHz to 14.0625MHz.
Moi qui ai toujours travaillé avec un quartz externe 8 Mhz, je pense que la bataille ce joue la, mais j'aurais grandement besoin de piste pour déterminer une fréquence optimale.

Je suis conscient qu'il manque beaucoup d'info, je ne souhaite pas qu'on me fasse le travaille mais si vous pouviez me donner des méthode d'investigation ou des pistes...
Je pense que les deux éléments contraignant sont cités ci dessus, à savoir la RF433 connectée sur Tx pour communiquer en RS232 et le capteur en I2C.

En sachant que j'ai 5 valeurs à envoyer (température /100iem, humidité 0 à 100, lumière 0 à 100, potar 0 à 100, alerte faible tension 0 ou 1) toute les 5 minutes.

Ensuite j'ai trouvé ça pour piloter (on/off) les périphériques : cf image



Merci d'avance..

[PA5CAL]

Je suis donc en train de définir les différents régimes de fonctionnement avec les consommations, mais celle de mon microcontrôleur me pose problème, j'ai réalisé qu'un dès paramètres fondamental pour réduire la consommation de mon système et la fréquence de fonctionnement du micro. Et après avoir décortiqué les datasheet de ma puce RF 433 (MICRF112) et du capteur Temp/Hum i2C (HTU21D) je ne voit pas de limite basse de fréquence fournis par le CPU. Les infos que j'ai vu sont Freq SCL max 0.4 Mhz pour le capteur et un oscillateur de référence pour la RF compris entre 9.375MHz to 14.0625MHz.
Moi qui ai toujours travaillé avec un quartz externe 8 Mhz, je pense que la bataille ce joue la, mais j'aurais grandement besoin de piste pour déterminer une fréquence optimale.

Avec un oscillateur externe, le microcontrôleur a une limite de fréquence de 0 Hz. En d'autres termes, on peut le faire fonctionner aussi lentement que souhaité, voire l'arrêter durant de longues périodes, sans qu'il perde son état interne.

Toutefois, l'application exige certainement une fréquence minimale de l'oscillateur pour réaliser chacune des opérations dans les temps qui leur sont impartis. Et en règle générale, on n'envisage pas de faire varier cette fréquence parce que cela rendrait le circuit beaucoup plus complexe.

La fréquence recherchée étant fixe, on évalue d'abord les durées d'exécution des différentes parties du programme (en nombre de cycles) et les durées maximale imposées (en fractions de seconde) qui leur correspondent, puis en se basant sur le cas le plus contraignant on trouve la fréquence la plus faible qui peut convenir. Il suffit souvent de s'intéresser aux fonctions de communication et de conversion analogique-numérique pour trouver la fréquence minimale requise.

Pour réduire au maximum le courant, chaque fois qu'il est possible on peut placer momentanément le microcontrôleur dans l'un des modes dits de « réduction de consommation » (Idle, Power-down, Power-save, Standby, etc.), lesquels permettent de suspendre d'un coup et de façon plus ou moins indépendante l'état de certaines fonctions de la puce. Le microcontrôleur peut ensuite sortir de ce mode pour reprendre un fonctionnement à cadence normale.

On peut également choisir la nature de la source de l'horloge (six possibilités offertes), en trouvant un compromis entre la consommation du microcontrôleur, la précision de la fréquence et la sensibilité aux perturbations extérieures.

Toutes les informations et les explications nécessaires se trouvent dans la datasheet du microcontrôleur.

Quand c'est envisageable, on peut aussi placer les sorties dans des états qui réduisent la consommation des circuits extérieurs.

Ensuite j'ai trouvé ça pour piloter (on/off) les périphériques : cf image

Concernant le transistor MOSFET, il est important de choisir un modèle compatible avec la tension de commande (i.e. la tension d'alimentation du microcontrôleur).

En effet, les modèles classiques réclament généralement une dizaine de volts pour commuter correctement. La valeur importante à vérifier dans la datasheet du transistor est celle de V_GS donnée pour la résistance R_(ON).

Une erreur courante consiste à se référer à V_GS(th), qui n'est que la tension au-dessous de laquelle le transistor est bloqué.


Sans indiscrétion, quel appareil connecté à ta station météo exige-t-il d'utiliser cette interface de puissance ?

[PA5CAL]

Pour info, la datasheet de l'ATmega328P est par ici.

[bobflux]

Pour piloter les périphériques il est d'usage de mettre la coupure dans leur alim plutôt que dans leur masse. Il faut faire attention à la manière dont ils communiquent avec le micro.

Par exemple, si tu coupes l'alim (mais pas la masse), les lignes qui relient le périphérique au micro doivent être maintenues par le micro à 0V ou bien configurées en haute impédance, ceci afin d'éviter que le micro alimente le périphérique à travers les diodes de protection présentes sur les IO des puces en question... de même pour baisser la conso, il faut faire la chasse aux pullups et autres résistances.

Pour couper l'alim tu peux utiliser un PMOS ou bien un LDO avec une entrée ENABLE.

Si tu coupes la masse, il faudra de même s'assurer que le micro ne sort aucune tension sur les lignes en commun avec le périphérique qui pourrait induire la circulation d'un courant. Donc il faut que les sorties du micro soient à VCC (ou en haute impédance) et que le micro et le périphérique aient la même alim...

Pour augmenter l'autonomie il faut que tout ça passe le max de temps en veille, vérifie donc que ton module RF et autres capteurs sont aptes à entrer et sortir rapidement de veille (si il a besoin de plusieurs secondes pour se réveiller, c'est autant de consommation en trop à chaque fois).

[inviteb421e572]

Bonjour,
Désolé pour la réponse tardive, j'avance à mon rythme. Alors j'ai fais une note de calcul concernant les différents temps d’exécution.
J'ai donc choisi une fréquence hypothétique de 921.6 kHz qui me permet de choisir un bit rate "élevé" de 19200 kbps (cf AVR Baute rate calculator).
Ainsi qu'une fréquence SCL de 51.2 kHz.
Pour ce qui est des données à transmettre j'ai donc 6 octet à envoyer toute les 5 minute, repartis comme suit :

- 2 octets pour la température (résolution 11 bits)
- 1 octet pour l'humidité (résolution 8 bits)
- 1 octet pour la LDR
- 1 octet pour la valeurs du potar
- 1 octet pour le niveau de batterie

Avec un octet d'adressage + 6 octets de data + 1 octet de checksum
Ma trame est donc de 8 octets, avec 1 bit de start et un bit de stop, et un bit rate de 19200 kbps, j'ai donc 4.16 ms d'envois RS232, ma puce RF à un data rate max 50kbps donc la liaison me semble ok, donc je déduis 4.16 ms d'activité pour la RF avec 12.5mA de conso
Ensuite pour l'ADC avec la fréquence choisie, un prescaler de 8, je suis à 115.2 kHz, et donc 2.46 ms d'activité à 0.09 mA pour 5 minutes (20 mesures)
Puis maintenant pour l'I2C, avec prescaler 1 et TWBR à 1, j'ai une fréquence Fscl de 51.2 kHz donc avec les temps de mesure + les temps de commande et réception de data, je suis à 110 ms à 0.5 mA (10 mesures de chaque)
Consommation du micro à 3.3V et 921.6 kHz de 0.55 mA et en Idle 0.09 mA
La LDR avec une résistance série de 1Mohm consomme 3.5uA max (valeur LDR 20kohms)
Le potar sera de 1Mohm avec une résistance série de 1Mohm soit une conso de 3.3uA max (potar à 100ohms)
Sur l'alim TPS62203 avec un quiscient curent max de 30uA

Et la je bloque un peu sur le calcul de l'autonomie...

Si je pars sur consso en sleep : 0.12 mA
- Micro : 0.09mA
- Alim : 0.03mA

consso en activité : 14.9 mA
- Micro : 0.55mA
- Alim : 0.03mA
- Temp/hum : 0.5mA
- RF : 13mA
- ADC : 0.09mA
- LDR : 0.004mA
- Potar : 0.004mA

Donc d'après ce calculateur avec capacité pile AA 2700 mAh, et si je considère que mes périphériques sont tous allumés en activité (alors que RF allumée pendant - de 10ms, capteur pendant - de 150ms) alors dans ce cas je peux monté jusqu'à 300ms d’activités simultané des périphériques pour une autonomie de 2 ans.

Liens du calculateur : http://oregonembedded.com/batterycalc.htm

Donc tout me parait correct, je voulais donc votre avis sur tous ça. Notamment sur la conso de la RF MICRF112 que je comprends à moitié :

conso_rf.png

Puis pour terminer et revenir sur la coupure d'alimentation des périphériques via le microcontrôleur

Sans indiscrétion, quel appareil connecté à ta station météo exige-t-il d'utiliser cette interface de puissance ?

En fait c'était pour couper tous les périphériques hors usage (RF, capteurs temp/hum, LDR), hormis le potar car j'aimerais une interruption lors du changement d'état.
Afin donc d'économiser de l’énergie si précieuse pour mon projet. Mais d'après vous est ce une bonne solution ? Je n'ai pas trop compris les réponse à ce sujet...

J'ai trouvé ici : http://www.ermicro.com/blog/?p=423

trsw03.jpg

J'aurais voulu remplacer "non inductive load" par mes différents capteurs et les couper après envois des datas et rallumer au moment du démarrage.

Je vous met la note de calcul en pj (désolé c'est un peu brouillon ) pour les conso ce n'ai pas à jour je préfère le battery life calculator

Merci encore.

Cordialement,

Raphael

[inviteb421e572]

En fait j'ai vu qu'on pouvait alimenter directement jusqu'à 20 mA via les GPIO, est ce une solution viable et économiques (en consommation) ?