Problème avec un détecteur à base LM393 et de 1 wire

[destroyedlolo]

Bonjour,

J'ai un détecteur de pluie à bas coût basé sur le schéma très classique suivant :
DetPluie.png
(Le même montage est aussi utilisé dans des capteurs de luminosité, de température, de ... en fait quasiment n'importe quoi à partir du moment où ça se résume à comparer 1 tension avec une référence).

J'essaie de l'interfacer avec mon réseau 1-wire par un DS28EA00 par le schéma suivant :
Schema_DetPluie.png

Mon but est d'activer le capteur à la demande par le PIA.A et récupérer l'information pluie sur le PIA.B, active au niveau bas (0v).

Mon problème est que lorsque je met le capteur sous tension, sa sortie D0 est très succinctement activée (la LED correspondant clignote 1 fois), mais plus grave, ça force le PIOB en sortie et je suis obligé lui envoyé un ordre d'extinction pour qu'il repasse en entrée.

Je pense qu'il y a un courant d'appel dans ce D0, c'est pourquoi j'ai ajouté une diode.
Le blème est maintenant avec cette diode, le PIAB n'est jamais détecté comme étant à l'état bas

Que puis-je faire ? Sans diode, ca force le PIO en sortie. Avec, le signal n'est plus détecté

Je pense mettre une résistance de tirage vers la masse après la diode des fois qu'elle reste bloquée car le courant d'entrée du DS28EA00 n'est pas suffisant ... mais est-ce vraiment la solution ?

Merci
-----

[DAUDET78]

Je pense mettre une résistance de tirage vers la masse après la diode des fois qu'elle reste bloquée car le courant d'entrée du DS28EA00 n'est pas suffisant ... mais est-ce vraiment la solution ?

Je n'ai pas analyser tout ton truc, mais si la solution de la diode est la bonne solution, le schéma ne peut marcher que si on met une pulldown (10K à 220K)

[destroyedlolo]

Merci pour ta réponse.
Malheureusement, ca ne marche pas mieux : la sortie est toujours considérée comme étant à 0
Faudra que je regarde a tete reposée.

[destroyedlolo]

Bonjour,

Je reviens sur ce (vieux) sujet car ... en fait, j'ai le même comportement avec tous les modules utilisant un LM393 (testé aussi sur des détecteurs de lumière de même source).
Après quelques tests, ca n'a rien a voir avec le DS28ea00 ou quoi que ce soit d'autre car même "à vide", le LM393 envoie une pichenette au démarrage ...
Ce qui me gène, c'est que la dite pichenette est suffisamment forte pour forcer un changement d'état du DS28EA00 ... elle doit donc sortir des tensions/intensité normalement attendu sur ce genre de montage. Et comme ces détecteurs sont alimentés à la demande (sondes déportées alimentées par batteries, chaque mA compte ), j'ai peur qu'a force ca ne détruise les portes logiques que je met derrière.
N'ayant qu'un vieux oscillo analogique, c'est beaucoup trop bref pour que je puisse tester voir quoi que ce soit
Je pense mettre un simple filtre RC (la question est alors de savoir de quelle valeur ...) mais peut-être l'un de vous aura une idée plus lumineuse ...

Merci

Laurent

[A voir en vidéo sur Futura]

[DAUDET78]

Ce qui me gène, c'est que la dite pichenette est suffisamment forte pour forcer un changement d'état du DS28EA00 ...

Ton DS28EA00 .... c'est une usine à gaz ! http://pdf.atasheetcatalog.com/datas...m/DS28EA00.pdf

elle doit donc sortir des tensions/intensité normalement attendu sur ce genre de montage.

Non, le LM393 envoi, à la mise sous tension, un signal "normal", mais, de ce que je pige, le DS28EA00 a un latch en entrée qui mémorise cette surtension et qui doit être resetté par soft (j'ai pas regardé la procédure).
Si tu mets l'entrée AC au 0V avant la mise sous tension, tu as le même problème ?
PS : Ta diode entre le DS et le 393 est nuisible . Si la sortie du LM393 est à 0V, l'entrée du DS est flottante
PS : Je ne vois pas de découplage sur le 5V ??

[destroyedlolo]

Ton DS28EA00 .... c'est une usine à gaz ! http://pdf.atasheetcatalog.com/datas...m/DS28EA00.pdf

Mheu non : je suis en train de faire une librairie pour les interfacer avec des Arduino/ESP, et je t'assure que c'est rien à coté d'un DS2406 pour lequel il m'a fallu plusieurs lectures de la doc avant de comprendre comment accéder aux PIOs.

Non, le LM393 envoi, à la mise sous tension, un signal "normal", mais, de ce que je pige, le DS28EA00 a un latch en entrée qui mémorise cette surtension et qui doit être resetté par soft (j'ai pas regardé la procédure).

C'est parce que je me suis mal exprimé : le DS est alimenté tout le temps (il ne consomme quasiment rien) et son PIO.A alimente le montage du LM à la demande.

Si tu mets l'entrée AC au 0V avant la mise sous tension, tu as le même problème ?

La LED liée a sa sortie est toujours allumée, si je le met au VCC, elle s'éteint ... et du coup, j'ai compris : la pichenette vient de la charge de C2 qui devrait se faire par R1. Sauf que là, ca passe aussi par le DS
Bref, je vais devoir faire avec (car je n'ai pas envie de charcuter la carte du LM) ... la question va être d'éviter que la charge ne se fasse par autre chose que R1. D'où ...

PS : Ta diode entre le DS et le 393 est nuisible . Si la sortie du LM393 est à 0V, l'entrée du DS est flottante

... du coup, elle me parait nécessaire non ? Mais il manque dans tous les cas une résistance de pull-up.
A moins qu'il y ait une meilleure solution ?

PS : Je ne vois pas de découplage sur le 5V ??

Pour le DS, c'est en interne : c'est prévu pour.
Pour le LM, il y a C1.

A+

[DAUDET78]

La LED liée a sa sortie est toujours allumée,

Normal,
Mais as tu une info parasite (pichenette) sur ton DS ?

... du coup, elle me parait nécessaire non ? Mais il manque dans tous les cas une résistance de pull-up.

La PullUP, c'est R5
Retire ta diode

Pour le DS, c'est en interne : c'est prévu pour.
Pour le LM, il y a C1.

OK, pas vu ...

[destroyedlolo]

Arg, j'ai confondu : C2 ne se charge pas à travers le DS car il se trouve du coté du capteur. Mais c'est quand même lui qui crée l'impulsion.

Pour l'impulsion, on en connait maintenant la cause. Mais la question reste de savoir pourquoi ca perturbe le DS
C'est peut etre lui qui a un pb du coup, vu que j'ai pas mal bidouillé dessus. J'ai testé avec un autre DS mais sur le capteur de luminosité et son PIO ne semble pas en sortie.
Je testerai demain avec le capteur de pluie et ce nouveau DS.

Bonne soirée.

[DAUDET78]

Fait le test que je t'ai demandé ! tu courtcircuites C2 (et sans diode)

[PA5CAL]

Bonjour

Si j'ai bien compris le problème, lorsque le DS28EA00 commande l'alimentation du comparateur par un niveau bas sur PIOA, le condensateur C2 qui n'est pas encore chargé provoque une impulsion au niveau bas sur la sortie du comparateur et sur PIOB.

La solution la plus évidente pour éviter ce comportement serait de connecter C2 entre VCC et AC, en parallèle sur R1, plutôt qu'entre GND et AC.

rcomp1.png

Dans le cas où cette solution ne serait pas satisfaisante du fait du courant de charge de C2 au travers du capteur branché sur AC, alors on pourrait :
(a) - soit insérer une résistance de limitation entre R1 et C2, C2 restant connecté entre VCC et l'entrée INA+ du comparateur ;
(b) - soit retarder la montée de la tension IN, en plaçant par exemple un condensateur de même valeur que C2 (100nF) entre l'entrée INA- du comparateur et GND et une résistance légèrement supérieure à R1 (>10kΩ) entre cette entrée et la sortie du potentiomètre R2.

rcomp2.png

Dans le cas où l'on voudrait imposer provisoirement un niveau de sortie haut au démarrage du comparateur même lorsque le capteur branché sur AC est actif, il suffirait de conjuguer les deux solutions (a) et (b), avec pour (b) une résistance supérieure à la somme de R1 et de la résistance de limitation choisie pour (a).

rcomp3.png

[PA5CAL]

(Oups... sur les schémas, la numérotation de R1 et R2 a été inversée.)

[DAUDET78]

J'ai vaguement l'impression (faudrait analyser la spec du DS ou faire des tests avec une pullup et un switch sur l'entrée) que le DS latche l'état de l'entrée lors de la demande de lecture de l'entrée.
Donc il faudrait valider le VCC et ensuite attendre un moment avant de lire l'entrée

[destroyedlolo]

Bonjour,

Je n'ai pas pu faire de tests hier (ski ) mais j'en ferai en fin de semaine : je vais tester avec un autre DS pour voir si ce n'est pas lui le pb ainsi que le teste de DAUDET78 en fin de semaine.

Pour clarifier le fonctionnement du DS dont j'ai épluché le datasheet en long et en large :

• Au démarrage, le DS est en mode "CHAIN OFF" donc les PIOs sont en mode haute impédance
• Ils peuvent être modifiés que par un ordre "CHAIN" ou "ACCESS WRITE". Comme je n'utilise pas de chainage, dans mon cas ca ne sera qu'ACCESS WRITE.

Et là, je me dis qu'il y a peut-être un bug au niveau d'OWFS (couche d'abstraction 1-wire sous Linux pour ceux qui ne connaissent pas). Je m'explique, si on souhaite changer l'état du PIO.A, 2 solutions :

1. Envoyer 0xA5 puis un octet représentant l'états DE TOUS les PIOs (les 6 bits inutilisés sont ignorés). L'avantage est qu'ensuite on recoie un octet correspondant au nouvel état (confirmation que l'ordre est bien passé).
2. Envoyer 0xA5 puis uniquement un bit correspondant à l'état du PIO.A puis on fait un reset du bus, donc plus besoin d'envoyer les autres bits : c'est ce que je fais avec mes ESP, mais on n'a du coup plus de vérification.

Maintenant, si la solution 1 est choisie, il faudrait faire

• un PIO Access Read (0xF5) pour lire le contenu actuel des 2 PIOs
• un PIO Access Write (0xA5) après n'avoir modifié QUE le bit du PIO.A

Si OWFS utilise cette méthode mais ne vérifie pas les contenu de PIO.B avant son 0xA5, il est donc possible qu'il change l'état de ce port ... et le capteur n'y serait pour rien.
Et pour ca, je peux faire facilement le tests en activant le PIO.A sans mettre le capteur et regardé si PIO.B a été changé ou non.

A+

[DAUDET78]

Pour clarifier le fonctionnement du DS dont j'ai épluché le datasheet en long et en large :

Quand je te disais que c'était une usine à gaz .....

[destroyedlolo]

Quand je te disais que c'était une usine à gaz .....

Mais non, juste du numérique

Bon j'ai fait des tests avec un autre DS28EA00 ... et je n'ai aucun probleme : je pense donc qu'il a pris un ch'ton durant mes expérimentations (faut dire que mon premier montage était un peu capilo-tracté en contrôlant la masse plutot que le VCC ).

Bon, je pense que je vais conserver mon composant actuel : après tout ca marche, juste lui envoyé un ordre pour désactiver le PIO ...

Merci en tout cas pour votre aide.

[DAUDET78]

faut dire que mon premier montage était un peu capilo-tracté en contrôlant la masse plutot que le VCC

Ben oui ! si tu fais une connerie de ce genre ......

[destroyedlolo]

Je voulais économiser sur les composants passifs ... je ne recommencerai pas

[DAUDET78]

Pour ta culturation :

[destroyedlolo]

Bon, je me suis précipité : le résultat est exactement le même

Bon, étape suivante : je vais le faire depuis un ESP pour m'affranchir d'OWFS. Si le test échoue a nouveau, c'est qu'il y a un défaut de conception avec les DS et je verrai avec Maxim. Sinon j'essaierai de voir ce qui cloche avec OWFS et éventuellement leur proposer un patch.

A suivre donc ...

[destroyedlolo]

Pour ta culturation :

Pièce jointe 354816

Me voila donc culturé et c'est peut etre ce qu'il se passe à travers les portes logiques. L'ajout d'une diode comme je l'ai fait pour éviter le 1er cas est peut être la solution, non ? (il me manque une résistance de Pull-Up dans ce cas).
Le 2nd cas ne devrait pas se passer car les PIO du DS sont open drain et donc ne peuvent forcer que vers la masse.

(Pourquoi je fais ca ? parce que mon nouveau montage va servir pour automatiser un poulailler et je n'ai besoin de cette info que 2 fois par jour pour détecter le lever et le coucher du soleil donc je veux économiser la conso du détecteur jour/nuit vu que l'alimentation se fera pas photovoltaïque et batterie).

[destroyedlolo]

Bon, ben c'est bien un bug dans OWFS.
Je viens d'essayer dans les mêmes conditions avec un ESP8266 et le code suivant :

#include <OWBus.h>
#include <OWBus/DS28EA00.h>

#define ONE_WIRE_BUS 5			// Where 1-wire bus is connected to (GPIO-5)
OneWire oneWire(ONE_WIRE_BUS);	// Initialize oneWire library
OWBus bus(&oneWire);


void setup() {
	Serial.begin(115200);
	delay(100);
}

void status(DS28EA00 &p){
	uint8_t pios = p.readPIOs();
	
	Serial.print(pios, HEX);
	Serial.print(" (val, flipflop) PIO.A : ");
	Serial.print(p.getPIOA() ? "1,":"0,");
	Serial.print(p.getFlipFlopA() ? "1":"0");
	Serial.print(" / PIO.B : ");
	Serial.print(p.getPIOB() ? "1,":"0,");
	Serial.println(p.getFlipFlopB() ? "1":"0");
}

void loop() {
	DS28EA00 p( bus, 0x42886847000000bf );
	p.readPIOs();	// récupère la valeur initiale

	Serial.println("\nPIO.A = On (0)");
	p.writePIOs( p.getFlipFlopB() ? DS28EA00::PIObitsvalue::PIOBbit : 0 );	// garde la valeur du PIO.B
	status(p);
	delay(1e3);

	Serial.println("Retour état initial (PIO.A = 1)");
	p.writePIOs(
		DS28EA00::PIObitsvalue::PIOAbit | 
		( p.getFlipFlopB() ? DS28EA00::PIObitsvalue::PIOBbit : 0 )
	);
	status(p);
	delay(1e3);
}

Et la ça fonctionne pile poile. Je vais donc ouvrir un bug report chez eux et essayez de voir ou ça pèche ...

Je vous tiens au jus.
(Sinon, il neige et c'est cool )

[destroyedlolo]

Bonjour,

Les dev m'ont confirmé que la librairie écrit systématiquement les 2 bits ... et donc fait n'importe quoi pour le second
Donc un

echo 1 > PIO.A

mettra le second PIO dans un état indéterminé.
La seule solution actuellement est d'utiliser PIO.ALL ou PIO.BYTE.

Pour ceux qui programmerai un Arduino ou compatible (ESP8266), j'ai fait une librairie qui n'a pas ce problème.

A+