![]() |
![]() |
![]() |
![]() |
Recherche de l’autonomie maximum d’une balise Page en construction |
![]() |
Introduction |
Maj : 22/06/21
|
Dans un dispositif de domotique comme celui décrit par exemple ici Domotique via Internet Divers modèles de LiPo 18650 |
![]() |
Pour commencer, voici le circuit de base des balises indépendantes qui dialoguent avec le maitre en ESPNow ou WiFi. La plupart des périphériques BMP280, DS3231, AHT41, OLED, etc.. , sont en I2C, les autres OneWire, SPI, radio, etc.. seront rajoutés à la demande et prévus sur le circuit imprimé final mais ne figurent pas ici pour simplifier. Schéma de la carte balise | ![]() |
Le circuit choisi est le ESP32 monté sur platine carrée et non le classique DevKit, car en fonctionnement il faut supprimer le circuit FTDI très gourmand en énergie et que l’on ne peut pas passer en sommeil. Vous voyez sur l'image quelques périphériques I2C cités au dessus en tests de consommation. Vue du premier prototype avant production du circuit | ![]() |
La recharge annuelle de la LiPo se fait par un module à TP4056 indépendant. |
![]() |
|
![]() |
Voici les oscillogrammes autour des signaux DTR et RTS qui commandent les deux transistors pour produire <EN> et <IO0> afin de passer en programmation et démarrage automatique. Vous vérifiez que les signaux sont bien conformes à la table de vérité que j'ai indiquée sur le schéma. Timings ESP32 FTDI : RTS _ DTR _ Enable (reset) _ IO0 |
![]() |
Une autre manière de voir les mêmes signaux (plus TX et RX), avec l’excellent analyseur Salae qui permet de capturer en une seule fois huit voies, alors que l’oscilloscope ne peut en capturer que deux. Timings ESP32 FTDI : RTS _ DTR _ Enable (reset) _ IO0 |
![]() |
L'alimentation du ESP32 est très critique, les valeurs données par Expressif sont de 3.3 +/- 0.3V. Cette page montre le comportement d'une 18650 à faibles courants : Décharge lente d'une LiPo 18650 |
![]() |
Mesures sur le MCP1700 330e
Tests sous Vin = 3.6 V
Première mesure à vide Iout = 0, Iin = 4.5 µA : C’est très décevant, la moitie de la consommation de l'ESP32 en sommeil, alors que le datasheet annonçait 1.6 µA
Deuxième mesure : Iout = 6 µA, Iin = 10µA, rendement 60% , c'est le cas de l'ESP32 nu (sans périphérique) en sommeil, ce" qui représente la quasi totalité du temps....
Troisième mesure: Iout = 959 µA, Iin = 992 µA, rendement 97%
Quatrième mesure : Iout = 82.6 mA, Iin = 82.7mA, rendement presque 100%
Donc, pour résumer :
Le dropout de 250 mV est bien plus important que prévu, le datasheet annonçait 128 mV à 250 mA.
Le rendement est bon à fort courant, mais la perte à très faible courant est trop importante, la moitié de la consommation de l’ESP32 en sommeil (pas de courbe constructeur disponible).
Pourquoi ce composant est-il aussi loin des spécifications ?
Faut-il estimer que les composants chinois sont de mauvais clones ?... Il faudrait en tester un vrai.
Alternative douteuse
On peut remplacer ce régulateur problématique par une simple diode Schottky qui étalera le surplus quand la batterie est à pleine charge, mais qu’il faudra court-circuiter par un interrupteur quand la batterie tombera en dessous de 3.6 V
Une SS4 chutera de 200 mV à courant quasi nul, mais de 350 mV à 150 mA. Ce n’est pas encore l’idéal car en pleine charge, les spécifications sont dépassées en sommeil.
Créer ce court-circuit par un MosFet dont la gate est commandée par le programme est risqué car l’état des GPIOs est indéterminé au démarrage.
Autour du microcontrôleur, divers périphériques sont nécessaires pour mesurer l’environnement, les valeurs principales seront :
Le temps : Une horloge temps réel donnera le top précis d’émission de la trame de données (sans qu’il soit utile de connaitre l’heure complète).
La tension batterie : Par un convertisseur Analogique –Digital externe ou interne, indispensable pour savoir quand recharger.
La température : AHT21, BMP ou BME280...
La pression : AHT21, BMP ou BME280...
L’humidité éventuellement : AHT21, BME280, et tout autre facteur : GPS, accéléromètre, luxmètre, courant, vent, hauteur de liquide, comptage, bruit, intrusions, etc.
La partie émission est soit interne (WiFi) soit externe avec un module radio supplémentaire.
Les capteurs I2C sont privilégiés et il faudra prendre en compte la consommation en sommeil, le temps de réveil et de réponse à une demande de mesure (certains ont une longue phase d’initialisation), donc le bilan en énergie.
Quelques exemples sont détaillés pour voir les temps machine et les bilans énergétiques.
La valeur typique pour une balise est d’émettre brièvement sa trame à un moment précis toutes les deux minutes et passer en sommeil le reste du temps pour ne pas interférer avec les autres.
Elle n’écoutera pas, car cela consomme trop de temps machine et ruine l’autonomie.
Les chapitres suivants détailleront chacune des phases avec leur bilan énergétique.
Moyen trivial pour économiser l'énergie
Evidement, si l'on augmente la période, la consommation moyenne diminuera d'autant, mais ce n'est pas vraiment jouable car trop peu de données dégradent les courbes.
La période de 2 minutes, qui donne 720 points de mesure par jour s'avère bien adaptée pour de la domotique.
Le nombre de cycles annuel sera de 365 * 24 * 30 = 262800, chiffre que nous retrouverons par la suite.
Calcul du bilan énergétique sur l'année:
Pour calculer la dépense énergétique d'une phase sur une année il suffit de multiplier : Courant en mA * Temps d'activation en mS par cycle * 10-3 *262800 /3600 = mA * mS * 73 * 10-3 en mAh |
![]() Il faudra étudier soigneusement les paliers de courant en phase réveil pour tenter de tout réduire. Nous pourrons faire les mesures avec un oscilloscope, en mettant en série une résistance dans l’alimentation négative 3.3 V. Avec une consommation de 150 mA, une résistance de 1 Ohm donnerait une chute beaucoup trop importante de 150 mV, Le problème est qu’il y a deux grandeurs de magnitude très différente à mesurer, il faudra délicatement commuter la résistance de charge pour alterner les deux mesures. Pour les mesures en phases travail est préférable d'utiliser une résistance de charge de 0.1 Ohm avec un amplificateur d'instrumentation de gain 500 pour un courant en réveil de 150 mA, une chute acceptable de 15 mV, avec une sortie oscilloscope de 7.5 V, ce qui montrera parfaitement les paliers de courant. En phase sommeil, la sortie serait bien trop faible pour s’extraire du bruit, on commutera provisoirement sur une résistance de charge de 100 Ohms ; on retrouvera les valeurs ci-dessus pour un courant en sommeil de 15 µA, Evidement si l’on oublie de court-circuiter la 100 Ohms avant la fin du sommeil, l’ESP32 ne pourra pas redémarrer. Il est préférable d’utiliser un ampli d’instrumentation moderne avec résistance de gain fixe interne calibrée, et de soigner l’alimentation. Deux batteries LR22 de 9V rechargeables sont un excellent choix d'alimentation à faible bruit. |
Autre solution, l' INA250A4, capteur de courant sort en tension, 2 volts par ampère. avec shunt intégré 0.002 Ohm. Il sera câblé sur un petit Arduino indépendant qui enverra ces mesures sur une carte SD, qu’il sera ensuite facile d’exploiter sur un PC dans une feuille Excel. |
|
Commençons par le plus facile, chercher à réduire le plus possible à consommation en sommeil bien que nous ayons vu qu'elle était faible par rapport au réveil, mais c’est un exercice de style.
Pour les modes de sommeil, il y a de très bonnes pages sur le Net, cherchez dans votre moteur «esp32 sommeil», je ne le reprendrai pas ici.
A titre indicatif, l'ESP32 avec un programme vide consomme 75 mA.
ESP32 nu
Les tests seront faits sur un ESP32-S nu, monté sur la carte carrée blanche. Il faut simplement câbler les deux résistances et le condensateur indispensables à repérer sur le schéma.
Pour le programmer, il faut 4 fils fournis par la carte FTDI, l’alimentation et RX/TX (à croiser !), plus DTR/RTS avec le démarrage automatique, comme le montre le schéma Eagle.
Pour se faire une première idée, commençons par lancer le petit programme dans les exemples ESP32 "TimerWakeUp.ino" ou "Beacon_sleep.ino" dans mes fichiers joints, directorie "LowPower".
Il utilise le mode UART wakeup (light sleep only) avec la commande esp_sleep_enable_timer_wakeup().
Pour les premiers tests, et établir une base, regardons uniquement le mode sommeil.
La carte FTDI reste branchée, mais débranchée coté USB. L’alimentation est en 3.3 V. Un milliampèremètre en série montre un courant de 12 mA, c’est énorme.
Il ne faut donc pas monter les éléments de démarrage directement sur le circuit de la balise, mais ajouter les deux transistors+résistances (R1 ,R2,T1,T2) sur une petite carte intermédiaire amovible et de rentrer directement avec EN/IO0 à la place de DTR/RTS Cette page montre le comportement d'une 18650 à faibles courants : Décharge lente d'une LiPo 18650 |
![]() |
ESP32 + circuit de charge de la batterie
On rajoute la carte du circuit de charge de la batterie, basée sur le TC4056A, qui permet de charger proprement la batterie LiPo sur une prise USB 5V.
En branchant cette petite carte (non alimentée) sur la batterie, la fuite est d'environ 0.6 µA.
Bien qu'elle ne devrait être alimentée qu'une fois par an, il serait possible de la laisser branchée, cette consommation du dixième de l'ESP32 nu est faible, mais l'alimentation externe par prises 3 pins l'isole de la batterie hors charge et il n'y a plus aucune perte.
Note liminaire sur les cartes I2C : charge des bus
Dans les nombreuses cartes implantant un périphérique I2C, les résistances de tirages de 4.7 ou 10 kOhms sont systématiquement ajoutées sur SDA et SCL.
Le problème avec plusieurs périphériques est qu’il ne faut pas surcharger le bus. Nous éliminerons systématiquement toutes ces résistances pour n’en garder qu’un seul jeu.
Ce n’est pas toujours facile car les composants sont minuscules.
On rajoute l'horloge DS3231 en I2C
La balise doit connaitre l'heure pour émettre à un moment précis du cycle afin d'éviter les collisions avec les autres balises. Sans cette RTC externe, l'heure glisse trop avec l'horloge incorporée et pourrait varier de quelques secondes par jour ce qui provoquerait un conflit aves les autres balises.
L'horloge DS3231 en I2C est extrêmement stable et il ne sera utile de la remettre à l'heure que tous les mois en prenant le temps en WiFi sur un serveur, opération couteuse en énergie.
Premier test avec la carte de base, DS3231 non initialisée, led rouge en place, la consommation en sommeil augmente de plus de 2 mA, c'est énorme.
Enlevons la led rouge inutile, la consommation passe à 957 µA, il n'y a aucun courant sur la diode de la pile CR2032, c'est encore bien trop.
D'après le datasheet des EEProms, le standby current est de à 0.1 µA, et en enlevant la AT24C02 de base, qui ne sera pas utilisée dans l'application balise, le gain est imperceptible.
Dessoudons les deux réseaux de résistances, et câblons en volant deux 10 kOhms de tirage SDA /SCL. La consommation en sommeil passe alors à 98 µA, c’est mieux, mais encore beaucoup trop.
Cela correspond bien au datasheet qui indique un standby current est de à 110 µA
Comme vous le voyez sur le montage, il faut alimenter les 3 Vcc par une sortie GPIO pendant le réveil pour désactiver la RTC en sommeil au lieu de tout tirer directement à Vcc.
Attention, il ne suffirait pas de commuter le Vcc, car les circuits I2C se réalimentent par SDA/SCL !
Première mauvaise méthode, isoler par le positif Il faut prendre la précaution de laisser un temps entre la commande haute du GPIO et la lecture, car à très faible courants, les capacités parasites sont importantes et le signal met longtemps pour se stabiliser. C'est encore pire si l'on passe par un Mosfet (N ou P, coupure par le + ou le -), inutilisable pour des courants aussi faibles, sauf à le charger par une résistance supplémentaire pour consommer plus de quelques milliAmpères. Ecran du haut, temporisation de 500 µS entre la commande GPIO et la lecture de l'horloge, écran du bas temporisation 1500 µS. Les courbes montrent qu'avec 500 µS, c'est très limite, l'I2C se déclenche à 1.3 V, gros risque d'instabilité en batterie basse, avec 1500 µS ce n'est que 1.8 V. |
Violet: commande GPIO |
Deuxième bonne méthode, isoler par le négatif qui sera seul commandé par un GPIO (voir mesure tension batterie) . SDA/SCLA sont déjà au Vcc, ce qui est moins critique. Il faudra toutefois ajouter une temporisation d'au moins 1000 µS après l'état bas du GPIO pour stabiliser. Evidement, sur le firmware balise, cette temporisation sera utilisée pour traiter les autres périphériques avant de passer à l'envoi de la trame, gros consommateur d'énergie. Résultats des tests : L'opération dure moins de 2.43 mS, plus la temporisation. En ne comptant pas la temporisation qui dera utilisée pour les autres fonctions, le bilan énergétique de la lecture RTC serait :. 50 mA * 2.43 mS * 73 * 10-3 = 9 mAh, mais il est très facile de réduire fortement cette consommation, par exemple en ne lisant l'horloge qu'une fois sur dix. La consommation de la RTC en lecture est quasi nulle. |
![]() |
Première initialisation de la RTC
Pour initialiser l'horloge sur le serveur de temps, sans se préoccuper des consommations pour le moment, lancez une seule fois, "Beacon_RTC_init.ino". Il faudra auparavant rentrer le SSID et le mot de passe de votre box.
Si vous avez le message "Brownout detector was triggered", cela signifie que l'alimentation s'écroule lors du violent appel de courant du WiFi, revoir l'impédance des fils, de l'alimentation, supprimer le milliampèremètre, vérifier es condensateurs (10µF + 100 nF sur l'alimentation), la qualité des soudures...
Plus grave, cela peut être dû à un mauvais clone à bas prix de l’ESP32, il faut re-tester avec un authentique. Vous devez obtenir sur le terminal :! _ Connecting to myBox _
..... CONNECTED _ Monday, April 04 2022 13:50:12 _ ...
L'horloge est initialisée, par la suite, les appels au serveur de temps se feront automatiquement par le programme.
Recalage de la RTC sur un serveur de temps Internet.
Très longue séquence de connexion en WiFi, de 2550 milliSecondes, environ 150 mA,
Energie pour un appel : 2.55 * 150 = 282 mAs. Avec 12 appels par an, 282*12/3600 = 0.2 mAh, ce qui est absolument négligeable. Les longs appels WiFi vers le serveur de temps consommeront beaucoup, il faudra les limiter à quelques uns dans l'année. Le passage heure été/hiver n'intervient pas car la balise n'a à connaitre que les minutes et secondes pour se déclencher par interruption.
Elimination des temporisations
Il existe une solution un peu tordue pour supprimer cette temporisation d’au moins 1 mS, coûteuse en temps CPU (qui consomme inutilement 50 mA), c’est de déclencher la commande au début, mais ne lire la RTC qu’après la longue séquence d’émission de la trame.
Ce n’est pas un problème car la seule chose qui nous intéresse est le calage précis au top 2 minutes pour synchroniser la balise avec les autres, la trame n’envoie pas l’heure qui est connue par le Master.
Remarque préalable Il existe deux versions de cette carte à schéma identique, l’une avec le chip dessus, l’autre dessous. Sans rien modifier, la comsommation permanente de cette carte AHT21 est du même ordre que la consommation de l’ESP32 en sommeil, 6.8 µA, alors que le datasheet donne 0.25µA !
Consommation réveil L’appel des lectures température + humidité dure 2 fois 80 mS ce qui est très long. Le courant du AHT21 est donc d'environ 1 mA pendant la demi-période soit 40 mS, comme l'indique le datasheet, mais il faut tenir compte de la consommation de l'ESP32 de 50 mA sur tout le cycle, soit une dépense énergétique annuelle pour une seule mesure de (temp ou hum) : Malgré la réduction drastique de consommation en enlevant le régulateur, l'AHT21 est donc peu adapté pour une balise à faible consommation. |
|
Remarque préalable Attention sur les sites chinois lors de la commande, à la confusion BMP/BME ! Si le composant n’est pas cher, c’est un BMP malgré qu’il ait été commandé comme BME280. Le montage est ici beaucoup plus simple que pour l'AHT21 : 4 résistances de 10 kOhms, 3 en tirage SDA, SCL une pour CSB (seulement pour mode SPI), l'autre à la masse pour SDO (Bit d'adresse). Le BMP280 lit la pression + la température Consommation du BME280 Pour les tests de consommation à l’oscilloscope, une résistance de 1 kOhm est provisoirement insérée dans le négatif du BME280, moyenne sur 16 cycles. Le bilan énergétique annuel de la lecture du BME280 est : (50 + 0.3 mA) * 25 mS * 73 * 10-3 = 98 mAh, soit 2 % de la capacité batterie, ce qui est très acceptable. |
Ce capteur de température très répandu n’est pas un composant I2C, il utilise le bus One Wire de Dallas. Son inconvénient est de nécessiter un long intervalle entre la commande et la lecture.
Le circuit utilise le mode d’alimentation parasite, avec une 4.7 kOhms entre Vcc et DQ.
Pour les tests de consommation à l’oscilloscope, une résistance de 1 kOhm est provisoirement insérée dans le négatif du DS18B20.
Le TSL2561 est un circuit I2C de conversion digitale de l’éclairement. Un étalonnage délicat permettrait d’en faire un luxmètre, sinon les valeurs lues ne seront que relatives. |
|
Comme pour l’AHT21, en 3.3V, il faut enlever le régulateur inutile qui consomme beaucoup, mais la consommation permanente reste encore de 650 µA, il est donc indispensable de couper l’alimentation en sommeil, la fuite tombe alors à 0.7µA ce qui est quasi nul. La trace violette est la porte d’alimentation du négatif. Le bilan énergétique annuel (incluant l'attente) de la lecture du TSL2561 est : Le TSL2561 ne peut pas être envisagé pour une balise faible consommation sans éliminer l'attente. |
ESP32 + Option afficheur Oled SSD 1306
Cas particulier : Le Oled est branché, sans être initialisé, en mode sommeil, la consommation augmente de 7 µA.
S’il est initialisé, suivant le texte affiché, la consommation passe à 7 mA, et en effaçant l’écran retombe à 0.7 mA.
Pour revenir au 7µA non initialisé, il faut le débrancher puis le rebrancher.
Ce bilan énergétique montre qu’il sera impossible de le laisser branché en permanence sur la balise.
Solution : Isoler par le négatif (voir mesure tension batterie) pendant le réveil pour désactiver l'Oled hors debug.
Cette led à sa pleine utilisation maintenant. Il est difficile d'obtenir une valeur stable de la tension batterie en dépensant peu d'énergie, et le sur-échantillonnage prend beaucoup trop de temps. C'est un gros problème, car les convertisseurs Analog-digital de l'EP32 de 12 bits sont très bruyants, i
|
|
L'anode de la led rouge est directement reliée au positif de la batterie (jusqu'à 4.2v). En période de sommeil, IO2 en sortie est au niveau haut, la tension aux bornes est au maximum de 4.2-3.3V = 0.9, dans la zone de non-conduction de la led, quasi aucun courant ne passe, la led est éteinte, La tension aux bornes de IO32 est flottante, et pour éviter tout risque de tension statique ou induite (effet d'antenne), une résistance Rstat de 100 kOhms est tirée au positif, donc avec courant nul. Si le tirage était à la masse, il y aurait une fuite via la led d'au maximum : 0.9/(100 103) = 9 µA. Le filtre RC introduit un léger retard exponentiel de quelques dizaines de µS, c'est pour cela que nous allons d'abord faire une lecture du pont R/2R des configurateurs pendant les premières 50 µS, puis une fois la tension stabilisée sur IO32, la lecture de la tension batterie. |
Violet: entrée ADC sur IO32 |
Il faut toutefois ajouter que pendant ce temps le CPU travaille, avec une consommation moyenne de 50 mA, la consommation rajoutée par cette mesure est néglige
able, mais le courant à considérer n'est pas de 0.65 mA mais de 50 mA,
Dépense énergétique annuelle liée à la mesure de tension batterie : mA * mS * 73 * 10-3 = 50 * (104.4* 10-3) * (73 *10-3) = 0.4 mAh soit 0.2%, ce qui est absolument négligeable.
1) La relation lecture CAN / tension d'entrée est rigoureusement linéaire ! 2) La relation Vout -> Vin. C'est parfait entre 4.2 V et 3.5 V mais ensuite cela descend vite et à 3.1 V, la tension de sortie tombe à 2.86 V ce qui est limite pour la stabilité de l'ESP32. Cela n'est pas gênant car comme le montrent les courbes de décharges suivantes, la batterie peut être considérée comme totalement vide à 3.1V. 3) La perte de tension Vin -Volt = "dropout", qui est de 350 mV dans la zone utile, ce qui est beaucoup moins bon que nous le laissait penser la lecture du datasheet ! |
Mais cela ne suffit pas ! Connaitre la tension est une indication, mais ce qui est plus utile est de connaitre l'autonomie restante. |
![]() |
Consommation en latence pendant le réveil
C'est maintenant que les problèmes commencent, car tout consomme trop pendant trop longtemps.
Après avoir étudié le krill et les petits poissons, étudions maintenant les baleines.
Latence du réveil de l'ESP32
En début de courbe, à gauche, phase sommeil, consommation non mesurable dans le bruit < 10µA
Réveil deuxième case, consommation 7.5 mA pendant 30 mS
Palier 23 mA pendant 75 mS
Palier 28 mA pendant 8 mS
Palier 75 mA pendant 40 mS
Ensuite la phase active d’interprétation des commandes commence et allume la led pendant 40 mS, consommation de travail 20 mA (aucun périphérique n’est branché), puis repasse en sommeil.
Ce temps de latence est donc d'environ 150 mS pendant lequel on ne peut strictement rien faire. C’est beaucoup pour un processeur qui ne fait encore rien, 20% de l’énergie disponible sur une 18650, mais il n'y a pas moyen de réduire simplement… Il est intéressant de voir quand démarre le timer. Ce début de programme nous montre que le compteur a démarré 27 milli secondes avant de rendre la main. |
void setup() { long top = millis(); Serial.begin(115200); while (!Serial); Serial.println (top) ; // Affiche 27 mS |
Consommation en phase active réveil
Cette phase de latence incompressible de 150 mS est terminée, nous avons vu comment les périphériques s'activent pour fournir les données, pendant un temps et une consommation qui dépend des capteurs comme vu précédemment.
Maintenant tous les capteurs sont lus, la préparation de la charge utile prend un temps machine quasi nul. Pour chaque cycle, il y a très peu de données à envoyer pour relever toutes les balises, quelques octets dans la charge utile, mais cela prendra beaucoup de temps d'activité à fort courant.
Les balises communiquent toujours avec un maitre central qui centralise et traite toutes les données. Divers choix sont possibles, mais aucun n'est parfait.
C'est le produit <temps d'émission * courant moyen> qui sera le facteur clef. Les différentes consommations dans cette phase critique dépendent des choix technologiques pour l'envoi de cette charge utile.
Nous travaillerons en unidirectionnel, il n’y a pas d’handshake, la balise envoie mais n’écoute pas car cela prendrait beaucoup trop de temps machine
Envoi données :
Choix des technologies ??????????? à compléter ????????????
Infra rouge
C’est une technique simple et extrêmement performante sur le plan énergétique, comme le prouvent les télécommandes domestiques, mais elle n’est possible que pour des balises à vue du central, ce qui est très rarement le cas, aussi elle sera oubliée.
Bluetooth
Nous ne le détaillerons pas pour le moment, malgré l'avantage de sa faible consommation, car la portée est limitée et l'exploitation beaucoup plus compliquée qu'avec les autres moyens.
LoRa
??????????? à compléter ????????????
Radio 432 MHz
??????????? à compléter ????????????
ESPNow
Le système actuel tourne en ESPNow, mais n'exploite pas son avantage de pouvoir communiquer sur des grandes distances car tous les capteurs sont proches dans la maison.
Des solutions moins gourmandes sont à envisager.
??????????? à compléter ????????????
WiFi
Très curieusement, la consommation varie peu en réduisant la puissance émise, ce qui change beaucoup de nos émetteurs radio traditionnels.
En champ proche, près d'une box, la puissance est surabondante.
??????????? à compléter ????????????
Voir la page préparatoire qui montre le comportement d'une 18650 à faibles courants : Décharge lente d'une LiPo 18650
Cette page montre qu’il est difficile d’atteindre une grande autonomie avec des composants classiques, il faudra se tourner vers de nouveaux microcontrôleurs spécialement conçus pour cette problématique.
Addendum
Programmes inclus dans la directorie <__lipo_Beacon> :
Beacon_sleep.ino : Simple program to test ESP32 current deep sleep mode
VoltToPercent.ino : Percent capacity calculation for a good 18650 at low dicharge current from remaining voltage
PercentToVolt.ino : Remaining voltage for a good 18650 at low discharge current from percent capacity (only to verify table accuracy)
dec_pourcent.xlsx : Master record of decreasing voltage from time
tendance.xlsx : Optimised curve of 18650 percent capacity from voltage
Beacon_switches.ino : Very fast basic program to test availaible dip switches configurators from GPIO readings (bad solution)
Beacon_sleep.ino : Basic program to test the sleep mode current of the ESP32 beacon with a microAmperemeter. First use, ESP32 alone without FTDI
Beacon_RTC_init.ino : Simple test of time server and DS3231 RTC for the very first checks of ESP32 beacon.
Tous les détails et logiciels sont dans cette page à jour au : 220511 |
![]() |