Conception d'un nichoir connecté ! soucis de LED IR modulé !

[rer67]

4, 7, suivi de 2 zeros = 4700 Ohm
l'autre composant est un condensateur

tu n'as pas répondu sur le câblage (type, longueur) entre ESP8266 et DEL IR (TSAL6200) (c'est l'antenne qui emet les 'parasites')

ici lors des test je n'ai rien de connecté !

[al1fch]

ça va mieux en le disant explicement !!

Pour essayer d'aider j'imagine un schéma, s'il ne correspond pas à la réalité c'est une perte de temps ,  ça tend à casser  la motivation puisque je ne sais plus trop de quoi on parle exactement...
barriére IR , 2 barriéres IR, pas de barrière IR ? (sans DEL on ne peut plus parler de barrière IR en action)
our limiter les échanges sur des malentendus, j'attend que ça se stabilise =
UN schéma représentant la réalité du montage + UN code complet,
sur cette base on peut réfléchir.

[rer67]

le DHT 22 est cablé en cable plat de 25cm. Rien d'autre de cablé sur le NodeMCU.

Je l'avais déja ecrit que je n'ai rien d'autre de cablé pour le moment.

Mais je comprends ton message, je vais faire un schema et faire suivre le code.

[rer67]

Je reprends,

Comme j'ai grillé ma TSSP4038, j'ai refait un test simple afin de vérifier le fonctionnement de mon sketch au niveau de l'eeprom et de l'affichage de ma page web.

C'est à ce moment là que je me suis rendu compte que le 38khz générait des parasites.
La seul chose qui est branchée sur la NodeMCU est le câble USB et la sonde DHT22.


le code est en PJ

on est en phase à présent ?

[al1fch]

sur mon smartphone je ne peux rien tirer d'un fichier ino joint , je verrai plus tard

Sur quel GPIO est raccordé le DATA du DHT22 ? (je vois mal et suis de la viellie école : rien ne vaut un schéma, un vrai avec des composants représentés par leurs symboles, les photos, vidéos, images Fritzing en disent moins sur l'essentiel et mettent en avant des détails inutiles)

[rer67]

ok merci

sinon ici joint en TXT

[rer67]

et un croquis du montage final tel que je pensais le réaliser

[al1fch]

les idées à ce stade

chez moi j'aurai :
-examiné à l'oscilloscope l'alimentation et DATA sur le DHT22, eexaminé DATA avec un analyseur logique pour localiser le bug
-soudé une résistance de 1K en parallèle avec celle de 4,7K sur le module DHT22

Pour contourner le pb il est  envisageable  de n'activer le 38kHz que pendant la gestion de la barrière, ou  du moins le couper pendant la lecture du DHT22
ça parait faisable car dans le programme la coupure du faisceau n'est pas détectée par interruption mais par 'polling'
(Analog.write(D5, 0) pour couper ? jamais testé)

Si le 38kHZ n'est jamais coupé , déplacer AnalogWriteFreq() et AnalogWrite() dans le setup, pas  besoin de les relancer à chaque tour de boucle

Autre solution d'évitement = cacher sous le tapis = éliminer par logiciel les données aberrantes issues du DHT22 ne pas les publier sur la page web

[rer67]

Re,

J'ai récemment reçu un "mini oscilloscope" on va dire bas de gamme .. je vais voir pour le mettre en oeuvre !
Par contre, l'idée d'arrêter le 38Khz pendant la lecture est une bonne piste, j'ai adapté comme cela :

Code: [Select]

// Affichage T&H sur la console
   if (millis() - chronoDHT > duration) {
      chronoDHT = millis();
      analogWrite(D5, 0);     // extinction 38Khz
      Temperature = dht.readTemperature(); // Mesure de la temperature
      Humidity = dht.readHumidity(); // Mesure de l'hygrométrie
      Serial.print("Temperature: ");
      Serial.println(Temperature);
      Serial.print("Humidity: ");
      Serial.println(Humidity);
      analogWrite(D5, 512);   // redémarrage 38Khz
    }
et les lectures du DHT sont 100% correcte pour le moment....
Je confirmerais demain quand je pourrais à nouveau avoir des TSSP4038 et essayer les barrières
Si J'ai bien compris je doit laisser plutôt 512 que 200 dans "analogwrite"  C'est  juste ?
Merci

[al1fch]

512 (rapport cyclique 50%= signal carré ) oui évidemment !!
partir  de cette valeur et OUBLIER 200 (rapport cyclique 20%) qui n'était qu'une valeur anecdotique

[rer67]

Le changement de rapport cyclique doit me faire changer la valeur de la résistance en série des 2 led émettrices ? Ou pas ?

[al1fch]

Non. il me semble qu'elles ont été dimensionnées pour un rapport cyclique de 50%
Il me semble que depuis le message #121 je ne considère pratiquement que le signal carré (pas rectangulaire) donc rapport cyclique 50%, valeur 512 pour l'Analog.write()  ESP8266

[rer67]

J'ai enfin tout rebranché selon mon schéma et tout fonctionne.,le code et la page Web.
Avec l'arrêt du 38khz pendant la lecture ca fonctionne. Par contre j'ai du ajouter un petit delay() après la lecture pour laisser un peu le temps au 38khz d'irradier le Tssp car sans ce délais il me détectait un manque du 38khz.

Reste maintenant à tout implémenter dans le nichoir et d'imprimer les support de  led et de la photodiode....

Je compte enregistrer encore le nombre de  sortie d'oiseau donc je devrais plutôt utiliser la zone à partir de 4096 pour équilibrer un peu l'usure c'est bien cela ?
Merci beaucoup....

[al1fch]

Bonsoir

ça commence à bien se présenter !!

içi l'EEPROM est émulée dans une mémoire Flash SPI dont l'effacement se fait par secteur de  4ko , donc oui le second secteur commence en 4096 et l'utiliser permet de soulager le premier secteur et répartir l'usure sur deux secteurs

[rer67]

oui !! ca avance ....

j'ai tout de même encore une question bête peut être mais c'est pour mieux comprendre.

Si j'écris dans les secteurs 1 et 2 :

Code: [Select]

EEPROM.write(1, uint8_t(entree / 256));
EEPROM.write(2, uint8_t(entree % 256));
EEPROM.commit();

cela implique que j'aurais par la même effacé les secteurs de 3 à 4095 ? Puisque qu'il efface avant d'écrire  sur 4Ko ?