Perte de la valeur de la batterie

merci Auteur

il faut que je fasse une petite rectification la périodicité n'est pas de 10mn comme je l'ai honteusement annoncée mais de 5mn :oops:

Code:

---

1 2	const uint64_t TIME_TO_SLEEP = 300ull; /* Temps de mise en veille de l'ESP32 (en secondes) ici 5Mn */

---

Citation:

---

-est-ce que cette chute de tension ne se produirait pas au réveil du microcontrôleur ?

---

Dans le problème se reproduirait à chaque envoi or je peux rester un jour complet sans pb

par contre depuis que j'ai posté , j'ai effectué une correction mineure du programme du récepteur à savoir :

Code:

---

1 2 3 4 5

Blynk.run(); AQT.tick();   delay(20); // <=== 10 à 20

---

et comme le montre le relevé, je ne constate pas de perte alim et une mesure batterie beaucoup plus stable ,
il faut que j'attende au moins une semaine pour confirmer cela mais il y a une certaine amélioration

Bonjour,

Je ne vois pas trop d'où vient l'estimation à 5 minutes. Avec des envois toutes les 10 minutes, le V qui caractérise une mesure à 0 entre deux mesures correctes aura mécanique une largeur à mi hauteur de 5 minutes sans que cela signifie quoi que ce soit. Le 0 peut durer entre quelques ms (temps de mesure) jusqu'à presque les 10 mn sans que les courbes changent.

Pour savoir si le pb vient de la valeur mesurée (tension fluctuante), je propose de changer temporairement dans envoiVbatBrut(), int vBat = analogRead(vbatPin); par int vBat = 4000); Si pendant 24 heures nous ne recevons que V4000, nous serons sûr que les 0 viennent de int vBat = analogRead(vbatPin); donc soit il y a un pb de conversion analogique numérique soit une valeur en entrée connait des fluctuations étranges.

Une chose est sûre, la valeur 0 n'est pas une vraie valeur, car si c'était le cas, le MCU n'aurait pas d'alimentation.

Supposons que le problème soit l'entrée analogique. La documentation fait état d'un montage de ce type :

Pièce jointe 643512

On voit que l'impédance source d'entrée, hors le condensateur, est très élevée (0.76 MOhms) et n'est protégées des impulsions parasites que par le condensateur de 10 nF. C'est pourquoi je commencerais par vérifier que ce condensateur est bien en place.

Ensuite, je modifierais envoiVbatBrut avec un code (certainement bogué :oops:) de ce type.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int vBat = 0; #define DELTA 32 ... //*********************************************** void envoiVbatBrut() { char str[8]; // 6 caractères devraient suffire : V4095 et /0 do { int vBatOld = vBat; vBat = analogRead(vbatPin); // tension échantillonnée brute } while(abs(vBat-vBatOld) > DELTA); // Attention, DELTA trop petit => boucle infinie Serial.print("Valeur Brute = "); Serial.println(vBat); sprintf(str, "V%d", vBat); // 'V' suivi de la tension brute loraMessage(str); // Envoi du message }

---

Dans le cas général il n'y aura qu'une lecture comme dans le code initial (et pour peu que DELTA soit mieux choisi - ici 0.8% de 4096). Ensuite il fera autant de lectures jusqu'à stabilisation dans une fenêtre V+/- DELTA. Un compteur pourrait limiter le nombre d'essais.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void envoiVbatBrut() { char str[8]; // 6 caractères devraient suffire : V4095 et /0 int cmpt = 8; do { cmpt--; int vBatOld = vBat; vBat = analogRead(vbatPin); // tension échantillonnée brute } while((abs(vBat-vBatOld) > DELTA) && (cmpt > 0)); Serial.print("Valeur Brute = "); Serial.println(vBat); sprintf(str, "V%d", vBat); // 'V' suivi de la tension brute loraMessage(str); // Envoi du message }

---

Salutations

Merci Guesset

Je vais essayer tout çà

en 1 => mettre une valeur fixe pour différencier l'erreur en envoi ou en lecture

en 2 => si pb lecture faire une moyenne de 8 lectures de la tension brute puis envoi

j'ai tout bon ?

par contre le fait d'avoir doublé le délai et passer de 10 à 20µS

Code:

---

1 2 3 4

Blynk.run(); AQT.tick(); delay(20); // <=== 10 à 20

---

n'aurait aucun effet ?

Citation:

---

Envoyé par cobra38

faire une moyenne de 8 lectures de la tension brute puis envoi

---

Non, pas une moyenne, mais une médiane. La médiane va lisser ta courbe tout en éliminant les valeurs aberrantes.

Bonjour cobra38,

Citation:

---

Envoyé par cobra38

...si pb lecture faire une moyenne de 8 lectures de la tension brute puis envoi...

---

Ce n'est pas une moyenne. Le principe est de prendre la première lecture qui est dans la continuité de la précédente (le but est de ne garder que les valeurs sur pente faible c'est-à-dire à moins de 1% d'évolution avec le DELTA proposé). Afin d'éviter tout risque de boucle sans fin, le deuxième code utilise un compteur qui limite à 8 itérations maxi. Si nous sommes dans une zone d'évolution rapide (|dV/dt| > DELTA) le code retournera la 8^ème valeur lue même si la variation est loin d'être terminée.

Citation:

---

Envoyé par cobra38

par contre le fait d'avoir doublé le délai et passer de 10 à 20µS

Code:

---

1 2 3 4

Blynk.run(); AQT.tick(); delay(20); // <=== 10 à 20

---

n'aurait aucun effet ?

---

Je ne sais pas (delay() est en ms et non en us). Je ne vois pas l'impact que cela pourrait avoir car l'ESP32 est multitâche et delay n'a pas nécessairement d'effet bloquant sur tous les threads. Si cela avait un impact cela signifierait un problème de transmission et non de capture des valeurs. De toute façon, avec une sollicitation toutes les 5 mn, il n'y a pas le feu au lac.

Il faut faire attention au graphique qui n'est pas à la même échelle temporelle. L'affichage doit filtrer (vraisemblablement interpolation par filtrage passe-bas) les événements car il n'y a pas une colonne par point (sous-échantillonage de restitution). Aussi, les 0 remontent et les plateaux sont adoucis.

Salut

Guesset f-leb
merci pour ces précisions
les maths n'étant pas mon fort ;), je comprends cela comme une sorte de "filtrage" de la mesure sur 8 itérations max dans ce cas ...

je continue et vous tiens informer ...

Bonjour à tous

Comme préconisé par Guesset

Citation:

---

Pour savoir si le pb vient de la valeur mesurée (tension fluctuante), je propose de changer temporairement dans envoiVbatBrut(), int vBat = analogRead(vbatPin); par int vBat = 4000); Si pendant 24 heures nous ne recevons que V4000, nous serons sûr que les 0 viennent de int vBat = analogRead(vbatPin); donc soit il y a un pb de conversion analogique numérique soit une valeur en entrée connait des fluctuations étranges.

---

j'ai modifié dans le croquis EMETTEUR la valeur :

Code:

---

int vBat = 4000; // <======

---

c'est parti pour 24h => affichage batterie 121% soit

Code:

---

VBAT = 1.37*(valeurBrute/4095.0)*3.3; // modification changement carte uPesy

---

Bonjour

Comme parfois un dessin s'avère plus explicite ...

Pièce jointe 643553

La courbe en pointillés rouges est la résultante du traitement. Comme mentionné, les échelles de temps sont assez fantaisistes pour pouvoir voir quelque chose. En effet 5 mn vaut 300 000 ms et le temps entre deux mesures secondaires est de l'ordre de la ms. Le déplacement temporel apparent du point retenu (rond rouge plein) est donc également visuellement exagéré. il est environ de 5 ms sur 300 000 ms. L'avantage de la médiane par rapport à la continuité est que c'est un retard constant (il faut avoir lu les 5 valeurs pour trouver la médiane) ce qui n'apparaît pas sur le dessin. Mais pour cette application cela n'a aucune importance.

Pièce jointe 643554[/CENTER]
Les zones de validité sont représentées par un dégradé entre VbatOld-Delta et VbatOld+Delta centré sur VbatOld. Si la prochaine mesure est dans cette plage, elle est acceptée (trait horizontal vert). Sinon on fait une nouvelle lecture en considérant que la dernière devient VbatOld. Comme le laps de temps est très faible il y a de grandes chances que cette nouvelle lecture soit dans la plage requise. L'avantage est que le nombre de lectures augmente très peu. Le retour en sommeil est donc plus rapide. L'inconvénient est normalement qu'il faut bien calibrer Delta, mais pour simplement éliminer des 0 impossibles, le réglage n'a pas besoin d'être très précis.

Contrairement aux filtres classiques qui sont des fonctions continues, ces deux traitements ne sont pas continus d'où une certaine réticence à les appeler filtres même si leur but est de filtrer des valeurs aberrantes :weird:.

Salutations

merci Guesset

Très instructif ( à mettre peut-être la démonstration en infos générales )
et bravo pour la vulgarisation ;)

aux dernières nouvelles , il n'y pas de perte alim après quelques heures avec : int vBat = 4000

Bonjour,

On commence à y voir plus clair (si ça se confirme).

Donc la lecture serait fausse de temps à autre.

Comme déjà mentionné, l'entrée du convertisseur est à haute impédance (certainement pour limiter la consommation). Cela la rend sensible aux parasites. Y a t-il des sources de parasites proches (moteurs électriques, électrovannes, arcs électriques, relai forte puissance par exemple) ?
Cela peut aussi être la référence de tension qui est perturbée, mais je ne sais pas comment elle est générée (peut être en interne).
Ce pourrait être un conflit interne au MCU qui perturbe la numérisation (intervention sur les compteurs utilisés par le convertisseur par exemple) mais je pense que cela aurait un caractère moins erratique.

Les solutions proposées ont de bonnes chances de régler le problème, mais il est toujours frustrant de ne pas connaître le fin mot de l'histoire.

Salutations

Citation:

---

Y a t-il des sources de parasites proches (moteurs électriques, électrovannes, arcs électriques, relais forte puissance par exemple) ?

---

Je pense plutôt au WIFI j'ai un Routeur Xiaomi AX 6000 dans la même pièce ....

Il est inutile, je crois, d'attendre 24h, je vais donc procéder à la modification que vous m'avez indiquée à savoir :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

void envoiVbatBrut() { char str[8]; // 6 caractères devraient suffire : V4095 et /0 int cmpt = 8; do { cmpt--; int vBatOld = vBat; vBat = analogRead(vbatPin); // tension échantillonnée brute } while((abs(vBat-vBatOld) > DELTA) && (cmpt > 0)); Serial.print("Valeur Brute = "); Serial.println(vBat); sprintf(str, "V%d", vBat); // 'V' suivi de la tension brute loraMessage(str); // Envoi du message }

---

ESP32-Emetteur_V1-230907a:88:8: error: unused variable 'vBatOld' [-Werror=unused-variable]
int vBatOld = vBat;


J'ai du modifier comme suit car j'avais l'erreur ci-dessus à compilation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void envoiVbatBrut() { char str[8]; // 6 caractères devraient suffire : V4095 et /0 int cmpt = 8; int vBatOld = 0 ; // <=============== do { cmpt--; vBatOld = vBat; vBat = analogRead(vbatPin); // tension échantillonnée brute } while((abs(vBat-vBatOld) > DELTA) && (cmpt > 0)); Serial.print("Valeur Brute = "); Serial.println(vBat); sprintf(str, "V%d", vBat); // 'V' suivi de la tension brute loraMessage(str); // Envoi du message }

---

Pour les gens pressés avec le calcul de la médiane : RunningMedian

Bonjour Cobra38,

Citation:

---

Envoyé par cobra38

ESP32-Emetteur_V1-230907a:88:8: error: unused variable 'vBatOld' [-Werror=unused-variable]
int vBatOld = vBat;

---

Autant pour moi :oops:, je la déclarais dans le bloc mais elle était utilisée en dehors du bloc dans le contrôle de la boucle (test du while).
L'initialisation à 0 n'est pas indispensable.

Même si je ne l'ai pas rappelé dans le code avec compteur, il faut déclarer la variable Vbat en global. Mais je présume que si ça compile c'est que cela a été fait.

Que cela donne le résultat attendu ou pas, tenir informé le forum serait bien.

Salut

Citation:

---

Que cela donne le résultat attendu ou pas, tenir informé le forum serait bien.

---

Je n'y manquerai pas , je laisse tourner quelques temps

merci encore Guesset

Après une semaine de test voici le résultat de la mesure batterie
On peut constater qu'il y a toujours des pertes de mesures batteries
mais beaucoup moins peut-être est du à la modification du traitement de Vbat dans le croquis de l'Emetteur
ma conclusion serait d'appliquer peut-être une méthode identique dans le croquis cette fois du Récepteur
à savoir permettre l'envoi de la mesure de la batterie non plus toutes les 5 mn
mais attendre 2 cycles pour confirmer la mesure Vbat

Votre avis ?

Bonjour,

L'idée supposait implicitement des parasites ponctuels qui ne sont peut-être pas aussi ponctuels que cela :roll:. Or en faisant des mesures à la suite, pratiquement sans délai, on peut trouver deux fois la même valeur aberrante qui devient donc acceptable. J'avais hésité à ajouter un délai entre deux mesures mais, en me disant que l'hypothèse de l'impulsion parasite très courte restait valable, il semblait inutile de diminuer l'efficacité du système (temps d'éveil plus long) :calim2:.

Entre temps, avec un esprit d'escalier peu glorieux :oops:, je me suis dit que pour envoyer le message, le MPU devait avoir au moins 2.4V qui est le seuil bas du Vcc d''un ESP32. En prenant 2000 on a une marge de sécurité puisque cela correspond à environ 2.2 V (je présume que c'est un régulateur buck à faible perte).

Donc si la valeur vBat lue est < 2000, soit on n'envoie rien en considérant que le MPU n'est pas en état d'envoyer quoi que ce soit, soit on relit vBat jusqu'à trouver une valeur > 2000 (peut être avec une temporisation). L'avantage de cette démarche est qu'elle marche pour toute valeur aberrante.

Comme le module ne se plante pas, c'est que la valeur d'alimentation reste supérieure au minimum requis. Or la tension de la batterie est >= à la tension d'alimentation (régulateur buck oblige).

Il est fait état d'un WIFI proche. Je ne crois pas à sa responsabilité directe. Mais s'il est alimenté par un bloc de qualité moyenne proche de la carte ESP32, c'est peut être une piste. Je craindrais plutôt la proximité d'une machine à laver, d'un chauffe-eau etc.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

int vBat = 0;   //*********************************************** void envoiVbatBrut() { char str[8]; // 6 caractères devraient suffire : V4095 et /0 int vBatNew; for(int cmpt = 8; cmpt > 0; --cmpt) { vBatNew = analogRead(vbatPin); // tension échantillonnée brute if(vBatNew > 2000) { vBat = vBatNew; break; } delay(10); // Attendre 1/100 s } Serial.print("Valeur Brute = "); Serial.println(vBat); sprintf(str, "V%d", vBat); // 'V' suivi de la tension brute loraMessage(str); // Envoi du message }

---

Sauf erreur, ce code lit une valeur qui si elle est > 2000 est envoyée sans "delay". Si la valeur est inférieure à 2000, une nouvelle lecture a lieu 10 ms plus tard. Et ainsi de suite en cas de valeur trop faible jusqu'à 8 fois soit moins de 1/10 s. Si au bout de 8 fois il n'a toujours pas trouvé de valeur correcte, la valeur précédente est retransmise. On pourrait également choisir de ne rien transmettre ou un code comme "V--". Mais dans le cas d'une représentation graphique envoyer une valeur numérique reste intéressant.

Le problème rencontré me semble une perturbation externe que nous essayons de régler par du code en aveugle. Le déplacement de la carte (l'orientation aussi), en faire fonctionner une autre en même temps au même endroit, sont autant de moyens de moyens de tenter de pister le problème.

Une autre approche serait de mettre sur une entrée analogique, le même montage que celui utilisé sur IO35 mais en divisant les valeurs des résistance par 10 (100 k et 270 k) et en multipliant celle de la capacité par 10 soit 100 nF (non chimique). Si ça marche, cela confirmerait que le montage original est trop sensible aux parasites. En contrepartie la consommation du pont passe de 1 uA à 10 uA ce qui est certainement la raison des choix initiaux (de plus le ratio n'est plus le même car avec les valeur d'origine le ratio doit intégrer la résistance d'entrée du convertisseur ce qui n'est pas le cas avec les valeurs plus faibles).

Salutations

Merci Guesset

Je vais essayer cette nouvelle approche de l’émetteur
mais il faut que j'attende à minima 1 semaine pour validation

Une autre piste ne pourrait-elle pas venir aussi du Récepteur ?

Bonsoir,

Le test fait avec une valeur statique (4000) ne fait jamais apparaître de valeurs autres ce qui signifie que la transmission (émission comme réception) est bonne.

Bien sûr, il serait néanmoins possible de faire un traitement en réception mais nous avons la chance unique, depuis l'émetteur, de pouvoir faire d'autres lectures.

Salutations

Bonjour Guesset

j'ai implanté la nouvelle version void envoiVbatBrut()
je suis parti pour 1 semaine de test ....

merci encore
pascal