DS18B20 en RS232

[LICHTENBERGER]

Bonjour

Confronté à un problème de distance entre le capteur de température panneaux solaires et l'automate, j'ai solutionné en ajoutant un composant qui lit le capteur DS18B20 en one-wire et envoie le résultat en RS232 9600 bauds. Le dit composant est un PIC 12F683 qui en CMS fait tenir le dispositif sur une plaquette de 1cm2.
Il y a deux mesures par secondes, la résolution est de 1 degré.
Tout est là : lichtenberger.s.free.fr/DS18B20_RS232_12F683.docx
Il y a schéma, programme binaire et source.

NB: On peut me contacter via mon adresse free (lichtenberger.s at free.) mais pour que je reçoive votre mail il faut impérativement mettre ' sylvain ' dans l'objet car un filtre anti spam bloque tout ce qui ne contient pas mon prénom dans l'objet du message.

[defdef]

Avec quelle distance tu avais des problèmes pour "lire" une DS18B20 ?
Tu utilisais en mode parasite ou en l'alimentant?

[LICHTENBERGER]

Assez variable et dépendant de l'environnement.
Les problèmes commencent à partir de 5m. Après 15m, lisibilité très aléatoire.

J'utilise toujours le mode alimenté. Je pense que ce ne peut être que pire avec le mode parasite.

Je suis en cours d'une autre solution : Envoi d'une suite d'impulsions dont l'espacement traduit la température.
Avec une plage comprise entre 1 et 2 ms, on devrait pouvoir lire à grande distance.

Le PIC étant dans un doigt de gant (sans support ou circuit imprimé donc) j'espère des distances très confortables. A ces fréquences, peu de gènes dues à des réflexions sur les extrémités. Mais bien sûr, il ne faut pas avoir à lire 100 températures tous le 1/10 de secondes.
Le PIC est donné pour un fonctionnement entre -40° et +125° donc pas de risque de destruction jusqu'à ces valeurs. Par contre, il faudra dans la conversion T/° en lecture T tenir compte du fait que la fréquence de l'horloge RC du PIC peut varier avec la température.

[defdef]

Le problème viendrait de la résistance du fil?
Et si on utilise une plus grosse section?
J'ai récupéré du câble renforcé de france télécom, il faut que je testa avec ça.

[LICHTENBERGER]

Ce n'est pas la résistance du câble qui pose problème. Il ne passe qu'un courant très faible, un câble plus gros n'arrangerait rien.
C'est plutôt son aptitude à transmettre des signaux sans déformations.
Un câble est soumis à toutes sortes de parasitage électromagnétique par exemple, mais il y a aussi la capacité propre du fil et aussi son impédance qui augmente avec la longueur.
Et en plus les problèmes de réflexion de signaux sur les extrémités.
Ce qui est sûr c'est qu'on va plus loin avec du câble réseau cat 5 ou 6 (blindé et paires torsadées) qu'avec un simple fil téléphone.
Ne pas oublier qu'on travaille quand même avec des pulses de quelques microsecondes.

[defdef]

https://www.maximintegrated.com/en/app- ... mvp/id/148

[LICHTENBERGER]

Oui, bien sur et c'était séduisant.
Malheureusement il y a la pratique et là ça se complique.
Ce dont je parlais, c'est ce que je constatais. Une transmission stable et sûre avec un réseau comportant une dizaine de sonde sur un même bus, je n'ai jamais pu atteindre les distances annoncées...

[defdef]

Je viens de faire un essai avec 4 sondes sur 1 seul bus OneWire.
- 2 très proches
- 2 virtuellement très loin au bout d'un très long toron de fil torsadé non blindé oublié par France Télécom (que je n'ai pas encore eu le courage de dérouler pour mesurer, mais y a 33 tours sur le sol)

J'ai alimenté les sondes "localement", car 5v sur la distance je crois que c'est pas trop possible.
J'ai utilisé une torsade du toron entre deux portions de la breadboard.

Le comportement es le suivante:
- 4 sondes branchées => seules les 2 plus loin répondent
- si je coupe les sondes éloignées+reset => les 2 proches répondent

Du coup, je suis rassuré, pour la distance, mais il semblerait qu'il faille faire plusieurs bus OneWire ou avoir toutes les sondes à la même distance.

[LICHTENBERGER]

Oui,il est possible que la topologie de l'installation soit à surveiller de près.
Une expérimentation poussée serait intéressante.
Par contre, je ne pense pas que l'alim "locale" (parasite power) soit une nécessité. Vu la conso du chip, ça doit aller, et ceci d'autant mieux que ça fonctionne avec la seule alim du data. De fait le mode parasite power est surtout là pour éviter un troisième fil, pas pour avoir une meilleure alim.

[defdef]

En fait avec "alimentation locale", je voulais dire un +5v et Gnd de courte distance.
Seul le fil "data" était très long.
Je n'utilise pas le parasite mode.

Je vais faire les testes avec :
- 2 x 2 sondes 'éloignés" sur 2 paires différentes (genre en étoile) avec alim courte
- 1 sonde data + alim éloignée
- 4 sondes data + alim éloignée sur 1 paire de grande longueur.

[youn260]

bonsoir
je mets mon grain de sel
j'ai depuis des années une quinzaine de 18b20/2406 en parasite sur une centaine de metres
ces petites bètes sont tres sensibles aux surtensions
et quand une a des problèmes elle perturbe tout le réseau
elles usent aussi peut etre
je sais pas trop mais régulierement il faut en changer
le plus compliqué c'est de trouver la perturbatrice
il faut les brancher les unes apres les autres on voit(presque) de suite celle qui est en défaut
cdlt

[LICHTENBERGER]

Pour ma part, je n'utilise pas le mode parasite car d'une part ça complique la programmation puisqu'il faut alimenter le DQ pendant les écritures mémoire et les conversions (ce qui de plus nécessite une broche du CPU pour ce faire) et d'autre part, le mode parasite n'est pas recommandé au delà de 100°.
Et il se trouve que ça arrive notamment avec une utilisation où le fluide caloporteur est du glycol et qu'un problème de surchauffe survient.
Une installation faite pour l'hiver peut l'été être en excédent de calories, et j'ai vu un ballon de 1000l commencer la journée à 95° et à midi être au dessus des 100° sus nommés (merci les soupapes de sécu).

Pour pallier aux problèmes de conflits et de remplacement de sondes, quand c'est possible, je ne mets qu'une seule DS18B20 sur un bus. Pas besoin d'adressage donc pas de problème de remplacement. Après tout, avec des PT100 ou PT1000, c'est bien ce qu'on fait.

[Jean-Matthieu STRICKER]

Bonjour Sylvain,

Content de trouver ta trace sur ce forum ! car je t'ai envoyé un mail sans réponse il y a qq mois.

Ces derniers mois j'ai ressorti deux de tes programmes (horloge du 7/4/2013 et Thermo du 7/7/2011) pour faire un thermostat préparateur d'ECS pour ma chaudière qui n'en comporte pas.

Préalablement je me suis servi de tes routines sur PIC16F628 pour faire un thermostat haute résolution pour couper le chauffage si la température d'une cloison de ma maison est trop élevée (mesure de la température d'inertie).
J'ai constaté qu'il y avait toujours un écart de température lue de bien +2°à +3° en dehors de la tolérance de température de la sonde DS18B20 !
En diminuant la fréquence de lecture de la sonde toutes les minutes, la lecture de température était beaucoup plus fidèle : la sonde DS18B20 s'auto-chauffe quand on cause avec elle.
Ce point est connu en lisant bien les datasheets !
Mais il subsistait encore un décalage de +1,5°, avec cela difficile d'apprécier les faibles variations en dessous de 0.1° !
En reprenant ton code j'ai découvert que le programme mettait un état 1 sur le port avant de libérer le bus (en entrée) après un forçage à 0 par la sonde, ceci provoquait un micro-court circuit via la sonde et donc un auto-échauffement ! Après correction de tes routines la mesure était beaucoup plus fidèle !
Je vois encore ce même hic dans ton dernier programme ? ou alors quelque chose m'échappe sur le protocole 1 wire ?

D'autre part, le programme de décodage DCF77 a été corrigé et rendu plus robuste par des contrôles de cohérence qui renforcent le contrôle de parité si 2 bits sont faux.
Toutes les nuits il fait une resynchro avec 5 tentatives pour choper le basculement de l'heure été/hiver. Et en fin de journée il enclenche la chaudière si la température est dans la plage d'hysthérésis
Le thermostat ECS fonctionne très bien maintenant et se débrouille tout seul après une coupure de courant !

Pour ce qui est du mode parasite, je l'ai implémenté sur ce projet !
J'ai validé le protocole 1-wire avec une charge capacitive de 1 nF sur le bus, et toujours 4k7 de pullup (qui peut être diminué à 1k)
Le câble fait 3 m de long et il est blindé par une tresse de masse reliée côté capteur et côté PIC.
Pour des longues distance en mode parasite je vous suggère d'utiliser du câble coaxial (pour TNT ou parabole) avec des connecteurs F.
Ce câble ref 17PATC (le coax noir qui résiste aux UV) fait 52 pF/m ce qui permet de déporter une sonde sur 20 m pour 1000 pF de charge. Je pense que l'on pourrait aller à 40 m avec une résistance de charge de 1k (à valider)

[LICHTENBERGER]

Bonjour Jean-Mathieu.
Merci pour cette interessante contribution.
Normalement je réponds à mes mail dans les 48 heures. Malheureusement suite à une pollution redoutable de mon adresse free, un filtre impose de mettre sylvain dans l'objet pour qu'il me parvienne. Sinon, c'est poubelle !
Une non réponse si c'est par mon adresse laposte.net peut être du fait que les messages que j'envoie avec cette adresse arrivent assez souvent en spam et sont pas visibles si on ne consulte pas les courriers indésirables. C'est curieux, certains destinataires les reçoivent systématiquement en indésirables, d'autres jamais. Pour les premiers, une mise de mon adresse en "liste blanche" résous le problème, chez d'autres non. Bref pour m'écrire directement, mon prénom suivi de .lichtenberger chez laposte(.net) fait l'affaire.

Il es assez normal que mes routines de lectures T soient identiques dans tous mes programmes, c'est du copier/coller. Je ne me suis pas replongé dedans depuis bien longtemps, mais je vais le faire.
Je pense que la mise à 1 du bus était là pour préparer le prochain "Write Time Slots" mais en effet, il pourrait être plus tard dans le programme.

Du fait de la mauvaise réception du DCF77, je me suis orienté vers la lecture GPS (quant on est dans un lieu qui reçoit correctement le signal GPS) ou vers le CI DS1302, horloge "RTC" de Maxim. Mais le problème est la dérive du temps sans doute due à des quartz de piètres précisions sur ces modules (à 1€) qu'on trouve sur ebay.
Si on veut garder un bonne précision avec ça, on peut toujours faire une correction par logiciel.

Je n'ai jamais testé le mode parasite. L'économie en fil ne me semble pas déterminante.
J'ai récemment fait des tests avec un simple câble téléphone 2 paires. Je disposais d'une longueur de 40m et ça lisait bien. En environnement perturbé (électromagnétiquement parlant), j'avais des problèmes à partir de quelque mètres...

[defdef]

Bon j'ai mis les deux premières DS18b20 au bout d'une paire torsadée sur 5m environ + la fin en file simple sur 1m en étoile et cela fonctionne bien.
Une sonde sur le tuyau du haut du ballon de la chaudière bois et l'autre sous l'isolant au milieu du serpentin solaire.
Je n'ai pas de doigt de gant, mais la mesure du serpentin solaire, qui est la plus important est cohérente avec les thermomètres analogiques qui sont au dessus et en dessous.
J'avais commander de la pâte thermique, mais je ne sais même pas si je vais l'utiliser.
L'arduino est branché sur mon routeur openwrt qui collecte les données via la console série usb.
Après rien de plus facile que de faire un petit graphique avec gnuplot.


Les prochaines sondes seront beaucoup plus loin, car elles vont traverser toute la maison dans le vide sanitaire avant de remonter sur la pergola!
Avoir si cela fonctionnera avec le même bus one-wire ou, si à cause de la différence de longueur comme dans mes expériences précédentes, je suis obliger de déclarer un second bus one-wire.
Dans tous les cas, ce n'est pas gênant