Go Down

Topic: Nouveau projet: Traçer la consommation d'un module IoT. (Read 4730 times) previous topic - next topic

hbachetti

Un premier résultat :

La carte dont on mesure la consommation :
- ARDUINO PRO MINI sans LED et sans régulateur
- un module radio NRF24L01
- un régulateur 3.3V LM2936
- un capteur DS19B20

Le régulateur est alimenté en 4.2V.
La carte envoie la température toutes les 10s.
Elle est mise en veille entre chaque envoi, le NRF24L01 aussi.

Normalement on doit obtenir une consommation en veille de :
- ARDUINO : 5µA
- NRF24L01 : < 1µA
- LM2936 : 15µA
- DS18B20 : < 1µA
Soit environ 22µA.

Normalement on doit obtenir une consommation en activité de :
- ARDUINO : 10mA
- NRF24L01 : 12.3mA
- LM2936 : 15µA
- DS18B20 : < 1.5mA
Soit environ 25mA.


Le banc de mesure :
- ARDUINO NANO
- INA226 avec shunt 0.1Ω high-side
- INA226 avec shunt 10Ω low-side
Le shunt 10Ω est court-circuité en permanence sauf toutes les 10s quand on mesure le courant de repos.
Le banc envoie au PC par la liaison série chaque changement significatif de tension ou courant.

Un script PYTHON reçoit les mesures pendant une période de 60s et calcule les mini, maxi et moyennes :

Code: [Select]

MIN VOLTAGE: 4.1 V
MAX VOLTAGE: 4.2 V
MIN CURRENT: 16.5 µA
MAX CURRENT: 27000.0 µA
AVG VOLTAGE: 4.20 V
AVG CURRENT: 47.19 µA


Pas trop déconnant non ?

@+
Ne consommez pas trop ...
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

RIN67630

Normalement on doit obtenir une consommation en veille de :
- ARDUINO : 5µA
- NRF24L01 : < 1µA
- LM2936 : 15µA
- DS18B20 : < 1µA
Soit environ 22µA.

Normalement on doit obtenir une consommation en activité de :
- ARDUINO : 10mA
- NRF24L01 : 12.3mA
- LM2936 : 15µA
- DS18B20 : < 1.5mA
Soit environ 25mA.



Super!
Tu peux y rajouter des informations sur les timings?
-periodicité du réveil,
-durée de sommeil, et consommation par phase de sommeil
-durée de la phase active et consommation par phase active
-% de la consommation pour chaque phase.

C'est celà qui va devenir interessant: savoir où on doit intervenir pour baisser la consommation totale.


P.S. si ton circuit se réveille toutes les 10s il ne faut pas choisir cette période pour la mesure en veille.

hbachetti

Une version graphique ?


J'interprète  les pics de consommation comme suit :
8mA : ARDUINO
9mA : ARDUINO + DS18B20
24mA : ARDUINO + DS18B20 + NRF24L01
34mA : là c'est la colle ...

@+


Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

hbachetti

Quote
Tu peux y rajouter des informations sur les timings?
-periodicité du réveil,
-durée de sommeil, et consommation par phase de sommeil
-durée de la phase active et consommation par phase active
-% de la consommation pour chaque phase.
périodicité du réveil : 10s
durée de sommeil : idem
consommation en sommeil : 17à18µA
durée de la phase active et consommation par phase active

Il faut examiner les traces. Je dirais une trentaine de ms. Le problème est que ce n'est pas très répétitif.
Je ne rate pas de phases de réveil, c'est plutôt que les détails de chaque phase de réveil ne sont pas captés de manière assez fine.
Quelquefois, pendant une phase de réveil je vois la conso ARDUINO tout seul mais pas le reste.
Cela veut dire clairement que la mesure n'est pas assez rapide.
J'ai fait tout ce que j'ai pu pour alléger au maxi
Avant, en utilisant les méthodes de la classe readShuntVoltage() par exemple, je ratais pas mal de phases de réveil.
Dans la version actuelle, je lis les registres en direct, et je les utilise tel quels, sous forme d'entiers, aucun float.
Cela va nettement mieux, mais on sent bien que des échantillons sont absents.

La solution ? pas d'I2C, un ADC plus rapide ?
J'envisage sérieusement STM32 F4.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

RIN67630

Il faut examiner les traces. Je dirais une trentaine de ms. Le problème est que ce n'est pas très répétitif.
Je ne rate pas de phases de réveil, c'est plutôt que les détails de chaque phase de réveil ne sont pas captés de manière assez fine.
En principe le I2C à 100Khz ne devrait pas trop freiner.
Il faudrait quand meme prévoir un buffer, meme petit.
Quand ca se réveille, il faut accumuler les mesures sans rien faire d'autre.
Tu peux par ex. prendre millis() % 64  pour indexer un buffer de 64 mesures sur environ 0,064 sec. Tu y balances toutes les mesures sans reflechir, sauf un treshold pour detecter une phase active et sa fin.
Quand un "orage" est passé, tu imprimes le buffer.
Tu 'as pas un ESP32 qui traine?
Tu peux le faire tourner à 160 MHZ et il a plein de mémoire...


hbachetti

Salut

J'ai quelques ESP12E qui traînent dans un tiroir.
Je peux essayer aussi avec un STM32F103C8T6. 72Mhz, 128Kb de RAM.
Je l'ai déjà mis en oeuvre sous IDE ARDUINO.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

hbachetti

Un essai avec un ARDUINO MEGA.
L'ARDUINO stocke les données au fil de l'eau et envoie ses données entre les pics de consommation.



@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

hbachetti

Apparemment, avec un INA226 il va être difficile d'obtenir une mesure rapide.
Celle-ci prend environ 1.75 ms.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

RIN67630

Un essai avec un ARDUINO MEGA.
L'ARDUINO stocke les données au fil de l'eau et envoie ses données entre les pics de consommation.
Avec un graphe sur 600s c'est un peu dur de voir les détails. Avec une mesure toutes le 2mS tu dois quand même avoir plus que deux,trois points. Sinon il faut eventuellement envisager un filtre RC entre le shunt et l'ina266, comme décrit dans la notice d'utilisation. Tu peux aussi lisser avec un condensateur la consommation de ton module.

hbachetti

Oui, pas de problème, je chope environ 8 à 9 échantillons sur la période de réveil.
Mais il y a ce pic de consommation de 30mA que je loupe une fois sur trois.

Pas bien grave.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

RIN67630

Oui, pas de problème, je chope environ 8 à 9 échantillons sur la période de réveil.
Mais il y a ce pic de consommation de 30mA que je loupe une fois sur trois.
Faut pas baisser les bras...
Dans la doc, tu peux réduire la periode de mesure jusqu'à 140μS.
Tu peux aussi changer le mode de facon a mesurer rapidement l'intensité seulement.
Voir pages 13-14 de la doc.

hbachetti

C'est vrai que la tension est plutôt stable et ne nécessite pas une mesure aussi fréquente.
En mesurant le courant seul, j'arrive à capter une vingtaine d'échantillons sur la période de réveil.



Quote
Avec un graphe sur 600s c'est un peu dur de voir les détails.
J'utilise MatPlotLib, il est possible de zoomer :



Sur les graphes, on voit à chaque réveil, deux pointes de consommation.
Cela provient de l'utilisation de la fonction sleep() de MYSENSORS.
Le processeur est endormi pour 8 secondes maximum.
Comme ma période de réveil est de 10 secondes, il se réveille une première fois pour rien et se réveille une deuxième fois deux secondes plus tard.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

RIN67630

Le processeur est endormi pour 8 secondes maximum.
Comme ma période de réveil est de 10 secondes, il se réveille une première fois pour rien et se réveille une deuxième fois deux secondes plus tard.
On commence à voir tout l'interêt du bidule: pas seulement pour calculer une consommation, masi aussi pour déboguer un développement dans le sens d'économiser l'energie.

hbachetti

Tout à fait. Je me demandais d'où provenait ce premier réveil. Maintenant j'ai l'explication.

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

hbachetti

La suite :
Comme j'étais parti pour utiliser une NANO, j'avais l'intention de développer un PCB regroupant la NANO, les INA226, l'afficheur et les composants divers.
Comme je suis obligé d'utiliser une MEGA pour pouvoir stocker mes mesures en mémoire, il faut faire les choses à l'envers, c'est à dire développer un shield à enficher sur la MEGA.

Tout à refaire  :smiley-confuse:

@+
Linux is like a wigwam: no Windows, no Gates, and an Apache inside ...

Go Up