Réveiller ESP32-CAM

Bonsoir,

La première chose suivante à faire sera simplement de tester sur ta carte AI THINKER ESP32-CAM un exemple de la lib IRremote avec un des pins encore dispo en input* , une fois ça acquis et et de validé , il restera a integrer l'ensemble.
NB , ne pas oublier d'utiliser un "TSOP" alimenté en 3.3V

  • A priori selon RJCN38 , faire déjà un test IR sur GPIO16 pour la sortie du TSOP

Je viens de téléverser dans mon ESP32-CAM l'exemple IRrecvDemo dans IRremoteESP8266, avec la carte AI Thinker ESP32-CAM, le TSOP alimenté en 3.3v, sur GPIO14 (la télécommande ne veut pas réagir avec GPIO16, je ne sais pas pourquoi, je le constate c'est tout...)

Ca fonctionne très bien à chaque appuie sur les touches, en regardant sur le moniteur série.

il restera a integrer l'ensemble

J'ai donc intégré le programme en faisant bien attention aux endroits où il faut mettre chaque élément dans mon programme de steaming.

Au fait, pour info, ce programme est celui ci

La carte sélectionnée est bien "#define CAMERA_MODEL_AI_THINKER"

Le résultat est malheureusement identique, c'est à dire qu'effectivement il doit y avoir un conflit quelque part.
On dirait que le programme de streaming n'est "pas d'accord" avec le programme infrarouge... >:(

A suivre ?...

Oublier içi GPIO16,
Dans les modules à ESP32 qui, comme le WROVER, intègrent une PSRAM (RAM Pseudo Statique SPI) GPIO16 est utilisé en sortie pour le chip select de la RAM. Schéma interne du WROVER
GPIO16 WROVER.jpg

On peut se demander pourquoi le concepteur de la carte ESP32-CAM a sorti un GPIO inutilisable au lieu d'un GPIO disponible....

GPIO16 WROVER.jpg

ArduiCool:
Bonsoir,
Je viens de téléverser dans mon ESP32-CAM l’exemple IRrecvDemo dans IRremoteESP8266, avec la carte AI Thinker ESP32-CAM, le TSOP alimenté en 3.3v, sur GPIO14 (la télécommande ne veut pas réagir avec GPIO16, je ne sais pas pourquoi, je le constate c’est tout…)

Ca fonctionne très bien à chaque appuie sur les touches, en regardant sur le moniteur série.


Le résultat est malheureusement identique, c’est à dire qu’effectivement il doit y avoir un conflit quelque part.
On dirait que le programme de streaming n’est “pas d’accord” avec le programme infrarouge… >:(

A suivre ?..

Bon

Actuellement pour toi , le constat est :

  • Avec un AI thinker ESP32-CAM cela fonctionne avec le seul programme de reception IR uploadé pour le GPIO14, mais pas pour GPIO16.
  • çà “coince” ensuite lorsque tu veux integrer çà au programme webcamserver
    Ma reflexion rapide :
    Le GPIO14 doit être utilisé/initialisé par le programme webcamserver pour l’utilisation de la carte SD

la probabilité d’un conflit sur ce GPIO avec l’intégration du code IR, me semble donc importante

Je n’ai pas la possibilité en ce moment de faire des essais avec un “esp32-CAM” + TSOP

Mais sous toutes réserves et en l’état de tes manips réalisées , je pense que je tenterais pour voir , un essai de “code intégré” en mettant/définissant la sortie du TSOP sur le GPIO URX (le GPIO URX n’est utilisé que pour faire l’upload des programmes)

Parfaite synthèse Artouste,

C'est exactement la situation actuelle.

Je vais essayer ce que tu propose, mais j'avoue que je ne sais pas quel GPIO tu suggère en écrivant GPIO URX.

C'est le GPIO3 (marqué U0RXD sur les photos plus haut) qu'il s'agit ?

Je ne voudrais pas faire des bêtises :slight_smile:

un bémol…désolé…

s’'il s’agit toujours de réveiller un ESP32 endormi on ne peut compter que sur les GPIOs capables de le faire, ils sont nommés ‘RTC GPIOs’, catégorie spéciale…

Si la page suivante reprend bien la Data Sheet on voit ces GPIO repérés en orange


Source :

GPIO 3 (Rx de l’Uart 0) n’est pas dans cette liste, il ne peut jouer le rôle d’un ‘RTC GPIO’ (il n’est pas actif en deep sleep)

al1fch:
un bémol......désolé....

s''il s'agit toujours de réveiller un ESP32 endormi on ne peut compter que sur les GPIOs capables de le faire, ils sont nommés 'RTC GPIOs', catégorie spéciale...

Si la page suivante reprend bien la Data Sheet on voit ces GPIO repérés en orange


Source :
ESP32 Deep Sleep with Arduino IDE and Wake Up Sources | Random Nerd Tutorials

GPIO 3 (Rx de l'Uart 0) n'est pas dans cette liste, il ne peut jouer le rôle d'un 'RTC GPIO' (il n'est pas actif en deep sleep)

Bonsoir Al1
dans mon esprit , c'etait déjà eventuellement pour voir si un code webcamserver + intégration code irrecv fonctionnent en "bonne intelligence" :grin:

Si c'est le cas , ce sera un pas de plus de fait : un code IR reçu/analysé pourrait donc "endormir" l'esp , ensuite effectivement se posera le probleme de son reveil avec un pin adéquat pour de l'interrupt

J'ai bien conscience que tout n'est pas encore gagné 8)
Comme par exemple déjà de voir où et quand déclarer GPIO3 en input :wink:

Et complement , aprés une petite reflexion , un test en utilisant GPIO0 pour le TSOP aprés test devrait résoudre pas mal de problémes :grin: ( je crois que RJNC38 y avait d'ailleurs plus bas fais référence)

Avoir donc quel niveau est fourni par un TSP non excité 8)

Comme par exemple déjà de voir où et quand déclarer GPIO3 en input :wink:

Il s’agit donc bien du GPIO3 pour faire un essai de branchement du TSOP sur l’ESP32-CAM :slight_smile:

Je regarde cela demain :wink:

ArduiCool:
Il s'agit donc bien du GPIO3 pour faire un essai de branchement du TSOP sur l'ESP32-CAM :slight_smile:

Je regarde cela demain :wink:

regarde aussi et peut être surtout :grin: , ma réponse complétée pour GPIO0 8)

Bonjour

un coup d'oeil :
-au schéma de la carte ESP32-CAM donné plus haut par rjnc38 (message #18)
-au schéma interne des modules WROOM , WROVER ou équivalents

laisserait entendre que si l'on renonce à utiliser l'embase de carte µSD les 6 GPIO suivants seraient disponibles:

2,4 12, 13, 14 et 15 (a l'exception de GPIO14 , sortie d'horloge SD, ils ont un pull-up de 47K)
Les voici avec leurs dénominations relatives aux sigaux SD
SD.png
Bonus : ils semblent qu'ils aient tous le pouvoir de réveiller l'ESP32 (=appartenance à la catégorie RTC_GPIO, cf message #24)

SD.png

Bonjour,

al1fch:
laisserait entendre que si l'on renonce à utiliser l'embase de carte µSD les 6 GPIO suivants seraient disponibles:
2,4 12, 13, 14 et 15 (a l'exception de GPIO14 , sortie d'horloge SD, ils ont un pull-up de 47K)

peut être même qu'il est possible de mixer les deux : pendant le sommeil il n'y a pas besoin de la µSD ...
c'est ce qui semble être fait ici avec le gpio13 (j'ai pas testé)

Bonjour,

Alors,après tests avec les GPIO :

GPIO0 --> conflit
GPIO3 --> conflit

A tout hasard j'ai testé aussi ceux là aussi ::slight_smile: :

GPIO2 --> conflit
GPIO4 --> le témoin (lumière) de l'ESP32-CAM s'allume dès la mise sous tension, donc j'ai vite débranché
GPIO12 --> conflit
GPIO13 --> conflit
GPIO14 --> conflit
GPIO15 --> conflit

Et pendant que j'y étais... ::slight_smile:

GPIO1 --> conflit
GPIO16 --> conflit

Et si j'écarte uniquement la phrase "// irrecv.enableIRIn();" (qui Démarre le récepteur), je peut voir mon point d'accès sur mon tél. et évidement le streaming fonctionne.

conflit, c'est à dire exactement la même lecture que ce que j'ai mis sur mon post #13 (voir photos)

Je crois que je les ai tous testés :frowning:

Dur, dur cette histoire... :o

ArduiCool:
Bonjour,

Alors,après tests avec les GPIO :

GPIO0 --> conflit
GPIO3 --> conflit

A tout hasard j'ai testé aussi ceux là aussi :

GPIO2 --> conflit
GPIO4 --> le témoin (lumière) de l'ESP32-CAM s'allume dès la mise sous tension, donc j'ai vite débranché
GPIO12 --> conflit
GPIO13 --> conflit
GPIO14 --> conflit
GPIO15 --> conflit

Et si j'écarte uniquement la phrase "// irrecv.enableIRIn();" (qui Démarre le récepteur), je peut voir mon point d'accès sur mon tél. et évidement le streaming fonctionne.

conflit, c'est à dire exactement la même lecture que ce que j'ai mis sur mon post #13 (voir photos)

Dur, dur cette histoire...

bonjour
poste tout le code webcamser.ino modifié que tu utilise pour faire tes tests

Bonsoir Artouste

poste tout le code webcamser.ino modifié que tu utilise pour faire tes tests

Il s’agit du programme de ce tuto

Il y a pas mal de commentaires pour moi, j’ai fais un peu de tri, pas grave…

je le met en pièce jointe

il est modifié pour ajouter l’infrarouge qui pose tant de problème

Au fait j’ai vu sur le web qu’il y a des conflits possibles avec les bibliothèques pour l’infrarouge, c’est peut être par là qu’il faudrait voir, j’ai cherché un peu déjà, pour l’instant sans réel succès comme tu dois t’en douter… :confused:

ESP32_CAM_3_Essais_pour_Infrarouge.ino (13.8 KB)

Bonjour

Petit retour au titre du fil de discussion ......


Voir ce tutoriel qui traite du réveil d'un ESP32-CAM par un détecteur de présence (PIR)

Le capteur PIR est sur le GPIO13 qui est explicitement autorisé à réveiller l'ESP32
sur un niveau bas (0, Low) ..... Comme indiqué dans l'exemple ExternalWakeup

esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0);

GPIO13 est aussi utilisé pour la carte µSD mais comme l'a fait remarquer plus haut rjnc38, il est utilisable en mode sommeil pour réveiller l'ESP32

Bonjour,

al1fch:
Bonjour

Petit retour au titre du fil de discussion ......


Voir ce tutoriel qui traite du réveil d'un ESP32-CAM par un détecteur de présence (PIR)
ESP32-CAM PIR Motion Detector with Photo Capture | Random Nerd Tutorials

Le capteur PIR est sur le GPIO13 qui est explicitement autorisé à réveiller l'ESP32
sur un niveau bas (0, Low) ..... Comme indiqué dans l'exemple ExternalWakeup

esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0);

GPIO13 est aussi utilisé pour la carte µSD mais comme l'a fait remarquer plus haut rjnc38, il est utilisable en mode sommeil pour réveiller l'ESP32

Oui effectivement, j'ai ce tuto en ligne de mire depuis le début pour y piocher des éléments qui me serviront :slight_smile:

Mais avant, il faut que je résolve les problèmes qui surviennent.

Je rappelle en image (en m'inspirant de la présentation que tu as mise venant de ce tuto intéressant) ce que je souhaite réaliser :

J'avais au tout début penser au bluetooth, puis au wifi, dans les deux cas ça a été un échec.

C'est pour cela que l'idée m'ai venue d'utiliser l'infrarouge en branchant le récepteur IR sur le GPIO13 à la place du détecteur de présence du tuto.

Bon alors mon souhait en image :

Seulement évidement, je tombe sur un un problème de conflit entre le wifi et l'IR.

En lisant sur un forum américain, dont j'ai perdu le nom, je vois qu'il faudrait que l'ESP32-CAM soit connecté au wifi AVANT la mise en fonction de l'IR pour que cela fonctionne.

Ce qui paraît vrai, puisque que quand j'ai mis une condition (dans la Loop) pour la mise en marche de l'IR :

///*
// xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
// Infrarouge
// Tester si wifi est connectée, dans ce cas mettre en fonction l'infrarouge
if (WiFi.status() == WL_CONNECTED) { // si wifi est connectée (WL_CONNECTED attribué lors de la connexion à un réseau WiFi)
delay(100);
irrecv.enableIRIn(); // Démarre le récepteur infrarouge
while (!Serial) // Attend que la connexion série soit établie.
delay(50);
Serial.println();
Serial.print("IRrecvDemo est maintenant en cours d'exécution et attend un message IR sur la Pin ");
Serial.println(kRecvPin);
}
// Fin de teste de wifi connectée
// xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
//*/

Cela paraît logique pour moi, mais je ne sait pas si je met cela au bon endroit :confused:

Avec un "chargerDoctor", je vois 190mA à la mise en marche de l'esp32-cam, et quand je met la wifi cela passe bien en Streaming et je vois 200 à 210 mA, ce qui tendrait à prouver que le détecteur IR c'est bien mit en marche après la connection wifi.

Seulement il n'y a aucune réaction sur la led témoin que j'ai ajouté sur le GPIO4 qui est le flash de l'esp32-cam, pour témoigner si ma "logique" fonctionne bien.

Alors je cherche où placer ma condition de mise en fonction de lIR..

ArduiCool:
Bonjour,Oui effectivement, j'ai ce tuto en ligne de mire depuis le début pour y piocher des éléments qui me serviront :slight_smile:

Mais avant, il faut que je résolve les problèmes qui surviennent.

Je rappelle en image (en m'inspirant de la présentation que tu as mise venant de ce tuto intéressant) ce que je souhaite réaliser :

J'avais au tout début penser au bluetooth, puis au wifi, dans les deux cas ça a été un échec.

C'est pour cela que l'idée m'ai venue d'utiliser l'infrarouge en branchant le récepteur IR sur le GPIO13 comme indiqué sur le tuto pour le branchement du détecteur de présence).

Bon alors mon souhait en image :

Bonjour
Sous toutes reserves :
et juste pour une verif basique , je n'ai pas de quoi tester aujourd'hui :
il me semble, mais çà reste à verifier, que les TSOP non excités delivrent un niveau haut (état repos)
ça donne quoi une tentative de reveil de ton esp32-cam "préalablement endormi" par simple excitation du TSOP sur GPIO13 en "mode bourrin" (pas de recherche de code) ?

donc flasher le code du turoriel ‘réveil par PIR’ en remplaçant le PIR par le récepteur IR, c’est bien ça Artouste ?

Bonjour Artouste,

ça donne quoi une tentative de reveil de ton esp32-cam "préalablement endormi" par simple excitation du TSOP sur GPIO13 en "mode bourrin" (pas de recherche de code) ?

J'avoue que pour l'instant je n'ai pas mis, ni d'endormissement, ni de réveil, car je voulais déjà me prouver si le principe d'une intervention du TSOP fonctionnait à l'aide d'une led comme expliqué plus haut..

Je crains que nos post se sont croisé, j'ai modifié mon post précédent car je te trouvait incomplet :confused:

Je vais essayé de voir ce que tu me propose,, mais il faut que j'endorme l'esp au démarrage et que j'essai de le réveiller sur le gpio13 avec le TSOP

al1fch:
donc flasher le code du turoriel 'réveil par PIR' en remplaçant le PIR par le récepteur IR, c'est bien ça Artouste ?

Bonjour Al1
oui , dans un 1er temps , je part du postulat que le tsop "non excité" délivre un niveau haut , la "1ére salve" reçue et démodulée devrait generer au moins une transition vers un état bas de réveil , au moins tant que l'esp32-cam n'est pas replongé en sommeil .

ArduiCool:
Bonjour Artouste,

J'avoue que pour l'instant je n'ai pas mis, ni d'endormissement, ni de réveil, car je voulais déjà me prouver si le principe d'une intervention du TSOP fonctionnait à l'aide d'une led comme expliqué plus haut..

Je crains que nos post se sont croisé, j'ai modifié mon post précédent car je te trouvait incomplet :confused:

Je vais essayé de voir ce que tu me propose,, mais il faut que j'endorme l'esp au démarrage et que j'essai de le réveiller sur le gpio13 avec le TSOP

... ou au bout de 15 20" ~ pour tester simplement et pratiquement des reveils ensuite