En mettant 512, j'ai moins de pertes de valeurs, cela n'affecte pas le signal de réception de mon TSSP4038
pas en mal en tout cas ! mettre 512 (50%) et si le besoin s'en fait sentir du côté de la portée augmenter pour que la valeur moyenne du courant soit plus élevée. (la valeur 200 de mon premier exemple est fortuite, oublions là)
le DHT 22 est cablé en cable plat de 25cm. Rien d'autre de cablé sur le NodeMCU.
et la liaison entre sortie 38kHz et DEL ?
'ai également ce kit : kit
en utilisant seulement la platine emetteur tu penses que cela pourrais aller ? la broche "SIG" doit etre au 5v permanent c'est cela, je n'ai pas tout cerné ...
Oui, SIG à +5V. Ce kit permettrait de décharger l'ESP8266 de la production du 38kHz et remplacerait la DEL IR
Voir ce que cela donne en présence du récepteur TSSP4038
Mais avec un peu de mise au point ça doit pouvoir fonctionner correctement sans module extérieur.
C'est un peu dommage de zapper d'une solution à une autre sans aller au bout des choses....
combien vaut la résistance de tirage (pull up) associée au DHT22 ?
une résistance trop élevée augmente la 'sensibilité' aux parasites; le fil de 25cm faisant office d'antenne réceptrice.
Sous 3,3v et à 25cm je verrai bien 1k Ohm voire 820 Ohm (la résistance de pull up interne de l'ESP8266 est trop élevée)
combien vaut la résistance de tirage (pull up) associée au DHT22 ?
une résistance trop élevée augmente la 'sensibilité' aux parasites; le fil de 25cm faisant office d'antenne réceptrice.
Sous 3,3v et à 25cm je verrai bien 1k Ohm voire 820 Ohm (la résistance de pull up interne de l'ESP8266 est trop élevée)
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.
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.
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)
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
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 :
// 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
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
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
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....
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