Discussion :

[cobra38]

Bonjour,

Depuis le mois de mai , je teste la liaison entre :
Un Emetteur composé de uPESY ESP32 + Lora
Un Récepteur composé de TTGO Lora

toutes les 10 Mn env l’Émetteur envoi le niveau de la batterie plus les 2 signaux d'entrée à 1 ou 0
Le Récepteur analyse ces infos et entre autre le niveau en % de la batterie
Or depuis lé départ càd 15 Mai, je constate aléatoirement que le niveau batterie passe à 0% (voir fichier joint) alors qu'il est en réalité de 87%
je n'arrive pas à déterminer quelle pourrait être la raison, en écartant bien sûr que cette valeur soit réelle :
-est-ce un délai trop court à l'envoi ou du coté du Récepteur pour analyse la valeur ?
-lorsque la valeur est à 0% devrais-je confirmer par un deuxième test ?

c'est pourquoi je sollicite votre aide pour résoudre ce petit problème
je peux mettre si vous le souhaitez les 2 croquis Emetteur et Recepteur en copie

merci mille fois
pascal

[jackk]

Sans l'électronique de mesure ni la partie du code correspondante, difficile d'en tirer des conclusions.

[cobra38]

voici , voilà

[cobra38]

Et les schémas

[jackk]

Merci.
Je loupe peut-être un truc, mais je ne vois pas comment Vbat est mesurée sur le schéma. Mais je doute que ça vienne de là puisque la plupart du temps la mesure est bonne.

Je pensais que l'ADC n'avait peut-être pas le temps d'effectuer la conversion, mais d'après ton code ça ne vient pas de là.

Je pense plutôt à un problème dans le code du récepteur qui ne convertirait pas correctement la chaine reçue en entier. Essaie d'afficher sur le moniteur la chaine brute pour voir ce qu'elle vaut au moment de l'erreur sur la courbe.

[Jay M]

Je loupe peut-être un truc, mais je ne vois pas comment Vbat est mesurée sur le schéma.

La carte uPesy ESP32 Wroom Low Power DevKit a une particularité : contrairement à la carte uPesy Wroom DevKit, la pin GPIO35 est inutilisable car elle sert à mesurer la tension en entrée du régulateur - ce qui permet de mesurer la tension de la batterie par exemple.

d'où dans le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
const gpio_num_t vbatPin   = GPIO_NUM_35;
...
  int vBat = analogRead(vbatPin); // tension échantillonnée brute
  Serial.print("Valeur Brute = "); Serial.println(vBat);

[Jay M]

Or depuis lé départ càd 15 Mai, je constate aléatoirement que le niveau batterie passe à 0% (voir fichier joint) alors qu'il est en réalité de 87%

la conversion message ascii => valeur numérique se fait par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int valeurBrute = atoi(buffer + 1); // +1 pour sauter le 'V' et commencer à analyser à partir du premier chiffre

ce qui semble cohérent avec le mode d'émission, à condition bien sûr que le message soit correct

Vous avez juste avant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

		Serial.print("Reception: "); Serial.println(buffer);

est-ce que vous recevez V0 ou autre chose ?

et côté émetteur vous faites

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  Serial.print("Valeur Brute = "); Serial.println(vBat);

voyez vous le 0?

[cobra38]

Merci pour toutes vos réponses

pour jackk

Jay M a raison je récupère la valeur par la lecture de GPIO35


pour Jay M

voyez vous le 0?

en fait je ne fais que constater sur Blynk avec l'envoi d'un e-mail d'alarme ( aujourd'hui par ex : valeur 0 à 11h49 et 87% à 11h44 puis à 87% à 12h04 )
visiblement je n'ai pas 0 en valeur mais par contre le programme voit de façon aléatoire cette valeur et l'envoi à Blynk
je ne vois par contre comment faire pour "piéger" le problème

[Jay M]

il faudrait regarder les traces dans les moniteurs série pour voir si le zéro final correspond à un envoi effectif (mauvaise lecture donc) ou un bug dans la réception Lora (le V est reçu mais ensuite ce n'est pas la valeur) ou un bug lors de l'envoi ou réception Blynk

[Guesset]

Bonjour,

Une approche qui pourrait masquer le problème (s'il vient de la lecture) consiste à stocker la dernière valeur trouvée. Si la nouvelle valeur est sensiblement différente (seuil à définir +/- Vbat_old / 8 par exemple), la stocker et réitérer la lecture. Cela ne règle pas le problème mais devrait masquer les valeurs erratiques.

Salutations

[Jay M]

on peut aussi procéder par debug sur le matériel - par exemple si la station d'acquisition lit 0 alors elle allume une LED. Si la LED n'est jamais allumée, c'est que le problème ne vient pas de là.
Idem pour le récepteur, s'il décode un 0 après le 'V' alors allumez une LED. Si la LED n'est jamais allumée, c'est que le problème ne vient pas de là.

[cobra38]

en vous remerciant encore pour vos réponses

Avant de mettre en "dur" la proposition de Guesset
à savoir faire un second test pour confirmer la valeur
je propose tout d'abord de modifier comme suit le code
en partant du principe qu'il s'agit d'une valeur brute reçue à 0 et que le calcul VBAT n'a donc aucun sens

votre avis ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
case 'V':
				        if (BAL == 0) {
							digitalWrite(LED3,HIGH);
							delay(500);
							digitalWrite(LED3,LOW);
							delay(50);
							vliaison = true ;
							AffLiaison();
						}
					  int valeurBrute = atoi(buffer+1); // +1 pour sauter le 'V' et commencer à analyser à partir du premier chiffre 
            if (valeurBrute >0 ){
                VBAT = 1.37*(valeurBrute/4095.0)*3.3; // modification changement carte uPesy
						    IOT_Etat(); 
            }else{
               display.setTextAlignment(TEXT_ALIGN_LEFT);
               display.setFont(ArialMT_Plain_10);
               display.drawString(0, 0, "Erreur Vbat");
            }
            break;	
            }

[f-leb]

Bonsoir,

L'image du premier message montre un seul passage à zéro en 24h, et cela se reproduit de façon aléatoire je suppose !
En statistique, on sait éliminer les valeurs aberrantes.

Toutes les 10min, tu fais 5 relevés à suivre et tu recherches la valeur médiane.

[Guesset]

Bonjour,

Avant d'appliquer une suppression de valeurs aléatoires, il serait certainement utile de savoir où elle est générée (capture, transmission, réception) par exemple avec les tests proposés par Jay M.

Il y a un truc bizarre, sur le graphique le 0 semble apparaître juste à minuit. Est-ce toujours le cas ?

Salutations

[cobra38]

Il y a un truc bizarre, sur le graphique le 0 semble apparaître juste à minuit. Est-ce toujours le cas ?

il semble malheureusement que c'est aléatoire
à titre d'infos, je mets le relevé de ce jour
perte à 4h30 du matin et à 5h59 du matin

[cobra38]

Bonsoir,

L'image du premier message montre un seul passage à zéro en 24h, et cela se reproduit de façon aléatoire je suppose !
En statistique, on sait éliminer les valeurs aberrantes.

Toutes les 10min, tu fais 5 relevés à suivre et tu recherches la valeur médiane.

Merci f-leb , j'en prends bonne note et comme je l'ai dit, je vais à terme éliminer les valeurs qui ne sont pas conformes à la logique
à savoir une valeur de batterie + élevée que la valeur précédente ( sauf en recharge ) et celle à zéro bien sûr

[f-leb]

[...]à savoir une valeur de batterie + élevée que la valeur précédente ( sauf en recharge ) et celle à zéro bien sûr

Mmhh... tu as quand même de petites fluctuations dans tes mesures, une valeur (un peu) plus élevée que la précédente n'est pas forcément une valeur aberrante. Et puis comment ton système sait s'il est en charge ou en décharge ?

Mais d'abord, comme c'est conseillé plus haut par JayM et Guesset, il faudrait savoir l'origine de ces valeurs aberrantes (de la lecture analogique, ou de la transmission).