Maximiser autonomie d'un esp8266 sur batterie

Bonjour

Je reprends des travaux pour essayer d'optimiser la consommation électrique d'un esp8266, afin qu'il puisse fonctionner sur batterie le plus longtemps possible.

Le cas est ultra classique : une sonde de température qui remonte ses lectures à intervalles réguliers.

La démarche l'est aussi :
Après avoir apprivoisé le deepsleep, je me suis rendu compte que la connexion initiale au WiFi prend trop de temps, avec un réel problème sur la consommation électrique.

Chez moi, avec une Bbox, un wemos met entre 5 et 6 secondes pour être connecté au WiFi, selon la méthode WiFi.begin la plus simple.

Temps descendu à 1040 ms après application des conseils donnés dans la très intéressante série d'articles ci-dessous.
Reducing WiFi power consumption on ESP8266, part 1
Reducing WiFi power consumption on ESP8266, part 2
Reducing WiFi power consumption on ESP8266, part 3
Further reducing power consumption on ESP8266
Ces articles me semblent une illustration assez exhaustive de ce que l'on trouve sur le net.

Mais j'ai lu par endroit que certaines personnes arrivent à des résultats meilleurs, je me demande comment.
Peut-être est-ce lié à ma box?

Par ailleurs, en décortiquant la doc et les lib du core arduino, je suis aussi tombé sur la possibilité d'utiliser WiFi.setOuputPower(...) qui doit permettre de diminuer la puissance des ondes radio émises et donc de réduire la conso électrique.
L'idée est de baisser la puissance d'émission au niveau juste suffisant.
Mais jusqu'ici je n'ai pas obtenu de résultats probants en jouant sur ce paramètre.
En simulant un fonctionnement normal accéléré (réveil toutes les 30 secondes, petite batterie, histoire d'avoir un cycle de décharge complet en quelques heures/jours) je n'ai pas observé d'amélioration.

Des idées ?
Des expériences à partager ?

Bonjour

A l'oscilloscope on peut observer une réduction de l'amplitude des pics de courants en réduisant la puissance d'émission. Pour moi c'est une des mesures complémentaires pour augmenter l'autonomie et je l'utilise systématiquement pour mes capteurs WiFi

Le gain observé se situe essentiellement en fin de décharge de la batterie , lorsque sa résistance interne est élevée et que les pics de courants engendrent des creux de tension susceptibles de resetter l'ESP8266. Je gagne quelques cycles d'émission. Les mAh gagnés à chaque cycle sont négligeables mais je peux exploiter plus longtemps l'accu LiFePO4 qui alimente en direct l'ESP8266 en 3,2V (sans régulateur)

Avec ma Freebox le temps de connection à la box au réveil (ip fixe) est de l'ordre de 0,5s ce qui fait qu'un cycle réveil+ mesure +connection+ envoi vers ThingSpeak dure en moyenne 0,8s seulement. J'ai également réduit la résolution des DS18B20 pour accélerer la mesure.

Pour le suivi de la durée du cycle je mémorise en RAM RTC ou en EEPROM la valeur de millis() juste avant la mise en sommeil. Au cycle suivant j'envoie vers ThingSpeak la durée du cycle précédent et je peux suivre ça sous forme d'histogrammes.
histo.jpg
Le suivi du courant avec un oscilloscope est également très instructif vu que ce courant varie énormément au cours d'un cycle d'émission. On peut observer la contribution (amplitude et durée) de chaque étape d'un des ces cycles.

J'ai acheté récemment une Wemos D1 mini.
Je remarque un chose : régularité de métronome à la connexion WIFI, contrairement à une NodeMCU classique.
J'ai toujours 3.5s à la connexion (la livebox, plutôt ancienne, y est peut-être pour qq chose.

Pour ce qui est de la consommation je n'ai pas encore essayé l'ESP8266 comme client WEB, MQTT ou autre.

Le couple PRO MINI + NRF24L01 me donne entière satisfaction. Une batterie de 230mAH dure 17 mois. J'ai récemment changé ma batterie chinoise 16340 230mAH (vendue pour 2300mAH !) pour une batterie XTAR 650mAH. Il va falloir attendre un moment ...

Mais cette solution n'est adaptée que pour envoyer des données à un serveur situé sur un réseau local (DOMOTICZ pour moi), encore que rien n'empêcherait la RASPBERRY PI d'envoyer les données sur un serveur externe.

Il manque aussi une info dans ta demande : la période d'envoi des données.
Chez moi je suis à 15 minutes.

Bricoleau a évoqué un réveil toutes les 30s

Dans mon cas les sondes de t° WiFi (D1 Mini modifiées) se réveillent toutes les heures.
Alimentées en direct en 3,2V par des LiFePo4 au format 18650 de capacité réelle 1500 mAh elles tiennent plus de 10 mois '(doutes sur les 12 mois de la dernière rechargée, une D1 Mini Lite avec un ESP8285.... à vérifier...)

J'ai vu 30s "en simulant un fonctionnement normal accéléré". J'espère qu'en réalité la période est nettement supérieure.

Effectivement

Mon objectif serait d'atteindre une autonomie de 12 mois minimum avec un relevé toutes les 15 minutes et une batterie raisonnable.

Cela me semble ambitieux avec un wemos. Je voulais être sûr d'avoir tout gratté avant de partir sur du nrf comme tu l'as développé, très performant mais j'y regrette l'absence des possibilités offertes par les technos du web

Pour un thermomètre tu n'as besoin de rien en provenance du WEB.

Le plus gros dispositif que j'ai est un écran TFT.
Une version NRF24L01 qui affiche des informations en provenance de DOMOTICZ, y compris l'heure et la date.
Une version ESP8266 qui affiche en plus des infos venant du WEB :

  • date et heure (NTP)
  • météo
  • saint du jour

Il n'est pas interdit de mixer les deux technos.

Mon objectif serait d'atteindre une autonomie de 12 mois minimum avec un relevé toutes les 15 minutes et une batterie raisonnable.

C'était également mon objectif et je reste en deça si je veux continuer à envoyer directement mes données vers ThingSpeak et si 'batterie raisonnable' = format 1850.
Pour ThingSpeak (dans le CDC pour moi) l'envoi par MQTT ne fait pas gagner grand chose sur la durée de la session.

L'autonomie actuellement atteinte me satisfait déjà et je laisse en place 3 capteurs de ce type.

pistes de progression : capteur de température plus rapide, carte ESP8266, envoi en MQTT vers le Raspberry Pi local qui relaierai vers ThingSpeak. L'autonomie déjà atteinte ne me motive pas vraiment pour continuer son amélioreration.

Bonjour

Après deux jours de tests et recherches intenses, j'arrive à un résultat encourageant, mais pas encore totalement satisfaisant.
La bonne nouvelle est que j'arrive à me connecter au réseau wifi depuis un wemos D1 mini en 160 ms !

Le programme démo (ajustez les premières lignes selon votre configuration locale)

#include <ESP8266WiFi.h>

#define myWiFi_ssid           "xxxxxxxxxxxx"
#define myWiFi_password       "xxxxxxxxxx"

const uint8_t myWiFi_bssid[]= {0x00, 0x26, 0x44, 0xF7, 0x5C, 0xAB}; //adresse MAC de la box
const uint8_t myWiFi_channel= 11;                                   //channel WIFI utilisé par la box 

#define myWiFi_subnetMask     IPAddress(255,255,255,0)
#define myWiFi_gatewayIP      IPAddress(192,168,1,254)
#define myWiFi_dnsIP          IPAddress(192,168,1,254)

#define myWiFi_localIP        IPAddress(192,168,1,31)

void setup()
{
  uint32_t init, start, end;
  init = millis();

  WiFi.config(myWiFi_localIP, myWiFi_gatewayIP, myWiFi_subnetMask, myWiFi_dnsIP);
  //et pas de WiFi.begin() : on laisse l'ESP se connecter tout seul avec les derniers identifiants enregistrés

  Serial.begin(115200);

  start = millis();
  while (!WiFi.isConnected() && millis() - start < 5000) yield();
  end = millis();

  if (WiFi.isConnected())
  {
    Serial.print("\nAuto Connect : ");
    Serial.print(end - start);
    Serial.println(" ms");
  }
  else
  {
    if (!WiFi.getAutoConnect()) WiFi.setAutoConnect(true);
    if (!WiFi.getPersistent()) WiFi.persistent(true);

    WiFi.begin(myWiFi_ssid, myWiFi_password, myWiFi_channel, myWiFi_bssid, true);

    start = millis();
    while (!WiFi.isConnected() && millis() - start < 10000) yield();
    end = millis();

    if (WiFi.isConnected())
    {
      Serial.print("\nStatic Connect : ");
      Serial.print(end - start);
      Serial.println(" ms");
    }
    else
    {
      Serial.println("\nConnect failed !");
    }
  }
  
  Serial.print("Total time : ");
  Serial.print(millis() - init);
  Serial.println(" ms");

  if (WiFi.isConnected())
  {
    String s;
    Serial.print(F("SSID       : "));
    Serial.println(WiFi.SSID());
    Serial.print(F("psk        : "));
    Serial.println(WiFi.psk());
    s = WiFi.BSSIDstr();
    Serial.print(F("BSSID      : "));
    Serial.println(s);
    Serial.print(F("channel    : "));
    Serial.println(WiFi.channel());
    Serial.print(F("RSSI       : "));
    Serial.println(WiFi.RSSI());
    s = WiFi.hostname();
    Serial.print(F("hostname   : "));
    Serial.println(s);
    s = WiFi.macAddress();
    Serial.print(F("macAddress : "));
    Serial.println(s);
    Serial.print(F("localIP    : "));
    Serial.println(WiFi.localIP());
    Serial.print(F("subnetMask : "));
    Serial.println(WiFi.subnetMask());
    Serial.print(F("gatewayIP  : "));
    Serial.println(WiFi.gatewayIP());
    Serial.print(F("dnsIP      : "));
    Serial.println(WiFi.dnsIP());
  }

  Serial.println("Reset your board to restart");
}

void loop()
{
}

La plupart du temps, la connexion se fait en 160 ms.
Parfois c'est plus lent. Les traces debug de l'ESP, lorsqu'elles sont activées, montrent alors des soucis de connexion au réseau, lancement de scan etc.
On va dire que ce sont les aléas de l'environnement radio.

Jusqu'ici tout va bien, mais c'est après que ça se gâte : si on enchaîne immédiatement par une connexion à un serveur sur le réseau local (en l'occurrence un raspberry pi qui héberge un serveur mqtt), celle-ci à tendance à patatouiller.

J'ai pu isoler le problème, localisé sur l'instruction client.connect(serveur, port)
Celle-ci prend la plupart du temps 800 ms, et parfois significativement plus (> 2000 ms)

J'arrive alors à un temps total de 160 + 800 = environ 1000 ms pour atteindre le raspi à partir du démarrage de l'ESP.

Tous les tests que j'ai pu effectuer montrent clairement que le serveur distant et le réseau sont hors de cause. Le problème est bien à l'intérieur de l'ESP.

Si j'intercale un delay(500) juste après la connexion au WiFi, le client.connect(serveur, port) dure moins de 10 ms.
Ce qui donne alors un temps total de 160 + 500 + 10 = 670 ms

500 ms semble être la valeur minimum du delay, sous laquelle le temps du client.connect se dégrade considérablement.

Le programme démo avec connexion à un serveur

#include <ESP8266WiFi.h>

#define myWiFi_ssid           "xxxxxxxxxxxx"
#define myWiFi_password       "xxxxxxxxxx"

const uint8_t myWiFi_bssid[]= {0x00, 0x26, 0x44, 0xF7, 0x5C, 0xAB}; //adresse MAC de la box
const uint8_t myWiFi_channel= 11;                                   //channel WIFI utilisé par la box 

#define myWiFi_subnetMask     IPAddress(255,255,255,0)
#define myWiFi_gatewayIP      IPAddress(192,168,1,254)
#define myWiFi_dnsIP          IPAddress(192,168,1,254)

#define myWiFi_localIP        IPAddress(192,168,1,31)

#define myWiFi_mqttServerIP   IPAddress(192,168,1,48)
#define myWiFi_mqttServerPort 1883

void setup()
{
  uint32_t init, start, end;
  init = millis();

  WiFi.config(myWiFi_localIP, myWiFi_gatewayIP, myWiFi_subnetMask, myWiFi_dnsIP);
  //et pas de WiFi.begin() : on laisse l'ESP se connecter tout seul avec les derniers identifiants enregistrés

  Serial.begin(115200);

  start = millis();
  while (!WiFi.isConnected() && millis() - start < 5000) yield();
  end = millis();

  if (WiFi.isConnected())
  {
    Serial.print("\nAuto Connect : ");
    Serial.print(end - start);
    Serial.println(" ms");
  }
  else
  {
    if (!WiFi.getAutoConnect()) WiFi.setAutoConnect(true);
    if (!WiFi.getPersistent()) WiFi.persistent(true);

    WiFi.begin(myWiFi_ssid, myWiFi_password, myWiFi_channel, myWiFi_bssid, true);

    start = millis();
    while (!WiFi.isConnected() && millis() - start < 10000) yield();
    end = millis();

    Serial.print(WiFi.isConnected() ? "\nStatic Connect : " : "\nConnect failed ! ");
    Serial.print(end - start);
    Serial.println(" ms");
  }

  if (WiFi.isConnected())
  {
    //Le gros problème ici !!!!!!!
    //il faut un delay(minimum 500) pour que le prochain client->connect() soit rapide
    uint32_t wait = 500;
    Serial.print("Wait ");
    Serial.print(wait);
    Serial.println(" ms");
    delay(wait);

    WiFiClient* client = new WiFiClient;

    start = millis();
    bool clientIsConnected = client->connect(myWiFi_mqttServerIP, myWiFi_mqttServerPort);
    end = millis();

    Serial.print(clientIsConnected ? "Client connected : " : "Client failed ! ");
    Serial.print(end - start);
    Serial.println(" ms");
  }

  Serial.print("Total time : ");
  Serial.print(millis() - init);
  Serial.println(" ms");

  Serial.println("Reset your board to restart");
}

void loop()
{
}

Résultats types :

Auto Connect : 161 ms
Wait 1 ms
Client connected : 815 ms
Total time : 977 ms
Reset your board to restart
Auto Connect : 159 ms
Wait 500 ms
Client connected : 7 ms
Total time : 667 ms
Reset your board to restart

Un comble : c'est plus rapide avec un delay(500) !!!

Je pense qu'il doit y avoir un machin qui tourne en arrière-plan au niveau du core de l'ESP, pendant une grosse demi-seconde après démarrage, et qui gêne les communications.
J'ai fouillé dans les libs du core, dans les traces debug, dans la doc : pas moyen de mettre le doigt sur le machin, pour savoir s'il est possible de le neutraliser.

Bonjour

Le phénomène observé persiste-t-il en cessant de recourrir à l'autoconnect ?
persiste-t-il avec un WiFi.config moins détaillé ?
(Je n'ai pas relu la doc mais à l'époque ou j'avais fait les essais il ya avait des zones d'ombre sur l'autoconnect, la 'persistence' ,les paramètres mémorisés après une connection valide...)

Mes essais commencent à dater et au vu du code qui tourne chez moi depuis presque deux ans (sans autoconnect) l'intervalle de temps entre la connection à la box et le connection au serveur distant est de l'ordre de 200mS (temps de conversion d'un DS18B20 en mode 10 bits). Augmenter la résolution (11 ou 12 bits) allongeait la durée totale dans des proportions indiqéues par la data sheet du DS18B20.
Je ne trouve pas trace d'essais avec relevé des temps intermédiaires et n'ai qu'un suivi du temps total que j'avais cherché à minimiser.

Mettre ou aps dans la configuration l'adresse Mac de la box et le canal ?
il me semlble que le gain était significatif en cas de présence de répéteur WiFi

Merci pour la réponse

Les tests effectués permettent de localiser le problème, mais ils ne sont pas encore assez exhaustifs.

Je vais engager une série de tests complémentaires pour mieux comprendre le phénomène, en faisant varier :

  • la procédure de connexion WiFi, de la plus simple avec un bête begin(ssid,pass) aux plus sophistiquées avec ou sans autoconnect et persistence. En distinguant bien ce que l'on observe à la mise sous tension et à la sortie d'un deep sleep.
  • le réseau WiFi : même si le mien semble "propre" (pas de répéteur wifi, le wemos est en direct sur la box, elle-même reliée en filaire au raspberry), je vais utiliser un second wemos à la fois en tant que point d'accès et serveur distant. Si les symptômes sont les mêmes c'est que le problème est bien à l'intérieur de l'ESP.

Si le problème a une solution, on peut viser un temps d'exécution total de la fonction setup() à 200 ms, avec un ds18b20 en 10 bits, en parallélisant la lecture et les connexions.

Ce qui me gonfle, c'est qu'avant d'entrer dans la fonction setup(), un ESP fait des trucs sur lesquels nous n'avons aucune visibilité et qui, selon la conf, peuvent prendre un temps significatif (j'ai lu 325 ms) et consommer pas mal de courant.
Visiblement même millis() est remis à zéro avant d'appeler setup() et je n'ai pas trouvé de moyen logiciel de connaître ce temps d'initialisation.
Et je ne suis pas outillé pour suivre avec précision la consommation instantanée d'un ESP.

une autre option à envisager si vous n'avez pas vraiment besoin des données avec une granularité de 15 ou 30 minutes immédiatement c'est d'émettre les données que tous les N réveils.

Comme vous l'avez vu c'est l'activation de la stack radio et la connexion initiale qui coûte cher, envoyer 4 octets ou 40 octets ne change pas dramatiquent la donne.

ça peut être aussi un peu intelligent, s'il n'y a pas de variation d'amplitude de plus de x% entre la valeur min et max dans le buffer alors on ne fais pas encore l'émission (jusqu'à 10 fois) sinon on envoie toutes les données en attente car la modif peut être significative. ça vous permet d'interpoler sur la partie serveur l'affichage sur un range de données probables même si vous n'avez rien reçu.

@bricoleau

Ce qui me gonfle, c'est qu'avant d'entrer dans la fonction setup(), un ESP fait des trucs sur lesquels nous n'avons aucune visibilité et qui, selon la conf, peuvent prendre un temps significatif (j'ai lu 325 ms) et consommer pas mal de courant.

Sans avoir accès malheureusement au détail de l'ensemble des nombreuses actions se situant entre la mise sous tension et le moment ou setup() a la main on trouve quand même des descriptions résumées .
Comme ici : Boot Process · esp8266/esp8266-wiki Wiki · GitHub

ou ici une tentative de retro engénierie du bootloader de premier niveau : esp8266-wiki/reversed/ota_bootloader_stage1.c at master · esp8266/esp8266-wiki · GitHub

C'est tout un petit système qu'il faut mettre en place avant de pouvoir passer la main au code utilisateur... comme le défilement des lignes à l'écran de démarrage d'un raspberry PI jusqu'au prompt... mais sans les lignes !!

Je pourrais eventuellement remettre en place un dispositif de test avec suivi du courant à l'oscilloscope.

@JML C'est une piste envisagée (pas testée) dans mon cas pour ThingSpeak depuis qu'un envoi 'bulk' est possible.
Mais dans ce cas c'est à moi d'horodater toutes les infos avant l'envoi du paquet de données. Actuellement ThingSpeak horodate à réception mes données envoyées.

J-M-L:
une autre option à envisager si vous n'avez pas vraiment besoin des données avec une granularité de 15 ou 30 minutes immédiatement c'est d'émettre les données que tous les N réveils.

Comme vous l'avez vu c'est l'activation de la stack radio et la connexion initiale qui coûte cher, envoyer 4 octets ou 40 octets ne change pas dramatiquent la donne.

ça peut être aussi un peu intelligent, s'il n'y a pas de variation d'amplitude de plus de x% entre la valeur min et max dans le buffer alors on ne fais pas encore l'émission (jusqu'à 10 fois) sinon on envoie toutes les données en attente car la modif peut être significative. ça vous permet d'interpoler sur la partie serveur l'affichage sur un range de données probables même si vous n'avez rien reçu.

Oui tout est envisageable.
Comme envoyer systématiquement en udp la lecture courante ainsi que les n dernières. Ainsi, si le paquet udp se perd, la lecture perdue sera retransmise n fois dans les paquets suivants, ce qui peut apporter une meilleure résilience de l'historisation des relevés.

Mais il n'empêche qu'avant de prendre telle ou telle solution, j'aimerais arriver à maîtriser complètement les contraintes de bases.
Et sur ce point il me reste un os à ronger :slight_smile:

c'est le genre de truc où on peut engloutir des heures ! bon "rongeage" :slight_smile:

Alors...

En chargeant un second wemos avec l'exemple ESP8266/WiFiAccessPoint.ino fourni avec le package esp8266, et en me connectant à celui-ci en lieu et place de ma box, j'arrive à un résultat assez spectaculaire :slight_smile:

Auto Connect : 138 ms
Client connected : 8 ms
Total time : 147 ms

Après un deepSleep, ma fonction setup(), qui attend la connexion au WiFi et se connecte au serveur web embarqué dans l'accessPoint, dure seulement 147 ms !

Conclusion : mon lag de 800ms constaté à la première connexion à un serveur distant, lorsqu'elle intervient immédiatement après la connexion au réseau WiFi, n'est pas causé par l'ESP8266.
C'est la bbox qui me fait une blague.
Par acquis de conscience, j'ai paramétré toute la conf statique dans la box, cablé directement le raspberry dessus au lieu de passer par un switch gigabit intermédiaire, mais cela n'a rien changé.

Reste à creuser ce qui se passe dans l'ESP8266 avant d'entrer dans setup()

En passant le terminal arduino à 74880 bps, avec l'affichage des timestamps (pas super précis, mais ça donne une idée), on obtient :

19:40:05.908 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
19:40:05.908 -> 
19:40:05.942 -> load 0x4010f000, len 1392, room 16 
19:40:05.942 -> tail 0
19:40:05.942 -> chksum 0xd0
19:40:05.942 -> csum 0xd0
19:40:05.942 -> v3d128e5c
19:40:05.942 -> ~ld
19:40:06.145 -> 
19:40:06.145 -> Auto Connect : 138 ms
19:40:06.179 -> Client connected : 8 ms
19:40:06.179 -> Total time : 147 ms

Visiblement l'initialisation de l'ESP dure 230[edit] 100 ms

Et en activant toutes les traces en option de compil

19:43:34.947 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
19:43:34.947 -> 
19:43:34.947 -> load 0x4010f000, len 1392, room 16 
19:43:34.947 -> tail 0
19:43:34.947 -> chksum 0xd0
19:43:34.947 -> csum 0xd0
19:43:34.981 -> v3d128e5c
19:43:34.981 -> ~ld
19:43:35.049 -> 
19:43:35.049 -> SDK:2.2.2-dev(38a443e)/Core:2.6.3=20603000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-16-ge23a07e/BearSSL:89454af
19:43:35.049 -> wifi evt: 2
19:43:35.151 -> scandone
19:43:35.151 -> state: 0 -> 2 (b0)
19:43:35.151 -> state: 2 -> 3 (0)
19:43:35.151 -> state: 3 -> 5 (10)
19:43:35.151 -> add 0
19:43:35.151 -> aid 1
19:43:35.151 -> cnt 
19:43:35.185 -> 
19:43:35.185 -> connected with ESPap, channel 1
19:43:35.185 -> ip:192.168.4.2,mask:255.255.255.0,gw:192.168.4.1
19:43:35.185 -> ip:192.168.4.2,mask:255.255.255.0,gw:192.168.4.1
19:43:35.185 -> wifi evt: 0
19:43:35.185 -> wifi evt: 3
19:43:35.185 -> 
19:43:35.185 -> Auto Connect : 140 ms
19:43:35.185 -> :ref 1
19:43:35.219 -> Client connected : 26 ms
19:43:35.219 -> Total time : 171 ms
19:43:35.219 -> state: 5 -> 0 (0)
19:43:35.219 -> rm 0
19:43:35.219 -> del if0
19:43:35.219 -> usl
19:43:35.219 -> wifi evt: 1
19:43:35.219 -> STA disconnect: 8
19:43:35.219 -> :close
19:43:35.321 -> enter deep sleep

On a toujours les 230 ms avant setup()
Le setup() est un peu ralenti par les traces
Et le deepSleep met quand même 100ms à s'exécuter

Bonjour

Et le deepSleep met quand même 100ms à s'exécuter

je découvre dans la doc un deepSleepInstant() qui fait gagner environ 100mS. Effets de bord ?
https://arduino-esp8266.readthedocs.io/en/2.7.1/libraries.html#esp-specific-apis

ci joint deux enregistrements du courant consommé, avec et sans 'Instant', les deux deepsleep sont ici en mode 'WAKE-RF_DEFAULT'.
La trace d haut est le signal RST qui sert à déclencher l'acquisition.
On voit deux paliers de courant modéré avant l'activation initiale du WiFI.
Le second palier pourrait correspondre au chargement en RAM à partir de la mémoire Flash SPI.

Le code testé est celui présenté plus haut (#8) mais en ajoutant une mise en sommeil dès la connection à la box effective, l'objectif étant d'observer l'activité au démarrage


3eme test sans calibration RF au réveil : deepSleepInstant (durée, NO_RF_CAL) démarrage WiFi raccourci... gain de temps, gain d'énergie mais effets de bord ?

Cest tests sont faits avec un signal WiFi box faible (distance, murs) la connection à la box est laborieuse.

Et n dernier pour matérialiser le début de startup()
Un GPIO est brièvement active au tout debut du startup. On le voit environ (durée variable) 150mS après le RESET (trace du haut (coincide avec le premier pic d'activité du WiFi en autoreconnection, donc non lié à WiFibegin)

Intéressant

J'ai un oscillo basique mais je suis une quiche en électronique.
Qu'est-ce que tu utilises pour convertir le courant en tension observable à l'oscillo ?

conversion cournat/tension : içi une simple résistance de 0,1 Ohm (parfois 0,33 Ohm) dans la ligne de masse.
elle est insérée içi dans une 'rallonge USB maison'

la valeur 0,1 ohm permet de maintenir à un nveau très faible la chute de tension pour ne pas perturber l'objet alimenté, elle est d'autre part compatible avec les calibres 5 ou 2mV du scope en ma posession.

Sans mémoire il serait très difficile d'avoir une trace exploitable, c'est indispensable pour observer de tels phénomènes transitoires.

ok merci
C'est bien ce que je pensais, mais j'avais peur que la chute de tension aux bornes de l'ESP pose problème.

J'étais plutôt parti sur un "vrai" capteur de courant du style ACSxxx ou autre, avec une sortie analogique sur laquelle je pourrais brancher l'oscillo, mais j'ai du mal à en trouver un pour mesurer les courants DC très faibles.