Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 05-11-2016 22:10:00

passemoilaclede12
Membre
Inscription : 02-11-2016

Problème d'identification de sonde de température DS18B20

Bonjour,

Sur mon raspberry, sont branchées 3 sondes de température DS18B20 en 1Wire.

Voici un bout de code python qui récupère la valeur de la température sur les 3 sondes. Il fonctionne mais le répertoire "/sys/bus/w1/devices/28-800000038a0d/w1_slave" dont le nom est l’identifiant de la sonde se transforme en "28-380000000000" et on ne peut plus rien lire puisque ça ne correspond plus à rien.(même chose pour les deux autres répertoire relatif au deux autres sondes)

Si je reboote le RPi, ça fonctionne pendant quelques lectures et le changement de nom intervient intempestivement.

Le 1Wire mesure un bonne vingtaine de mètre : Faut-il revoir la valeur de la résistance (4,7k) ?
J'ai lu sur un forum que "ça arrive...." sans explication.....
Si quelqu'un à des info, je suis preneur !!!!!

Merci



def lireFichierTemperature(Fichier):            # lecture
    f = open(Fichier, 'r')
    lignes = f.readlines()
    f.close()
    return lignes
 
def LireTemperature(Capteur):               # extraction de la temperature
    lignes = lireFichierTemperature(Capteur)
    while lignes[0].strip()[-3:] != 'YES':
        time.sleep(0.2)
        lignes = lireFichierTemperature(Capteur)
    equals_pos = lignes[1].find('t=')
    if equals_pos != -1:
        temp_string = lignes[1][equals_pos+2:]
        temp_c = float(temp_string) / 1000.0
    return temp_c  

lcd.set_cursor(0,3)
lcd.message("In")
temp = str(LireTemperature("/sys/bus/w1/devices/28-0415915c80ff/w1_slave"))
lcd.message(temp[0:-2])

lcd.set_cursor(7,3)
temp = str(LireTemperature("/sys/bus/w1/devices/28-800000038a0d/w1_slave"))
lcd.message("Ex")
lcd.message(temp[0:-2])

lcd.set_cursor(14,3)
temp = str(LireTemperature("/sys/bus/w1/devices/28-0415916583ff/w1_slave"))
lcd.message("Pi")
lcd.message(temp[0:-2])
 

Hors ligne

#2 06-11-2016 15:30:30

Philou92
Adhérent(e)
Lieu : Hauts de Seine
Distrib. : Debian Jessie 8.7
Noyau : Linux 3.16.0-4-amd64
(G)UI : Gnome 3.14
Inscription : 29-04-2015

Re : Problème d'identification de sonde de température DS18B20

Hello,

Deux possibilités : problème matériel ou soft.
Côté matériel ta sonde est peut-être hs. As-tu essayé de la remplacer ? Ce qui est étrange mais pas impossible c'est la suite de six "0" dans le code 64bit.
Côté soft est-ce qu'il réalise un test de validité du code crc renvoyé par la sonde ?

Pour la résistance pas de soucis. Peux-tu montrer un schéma de câblage ? Quel est la longueur des câbles de liaison ?

Hors ligne

#3 06-11-2016 17:17:19

MicP
Membre
Distrib. : debian stable
Noyau : Linux 3.16.0-4-amd64
(G)UI : Xfce
Inscription : 29-02-2016

Re : Problème d'identification de sonde de température DS18B20

Bonjour

Se méfier aussi des câbles non blindés qui passent trop près des générateurs de champ magnétique (transformateurs, câbles qui véhiculent des appels de courant important, alimentations à découpage mal blindées, harmoniques des émetteurs radio mal blindés, moteurs électriques, etc.)
qui induisent un courant dans le câble générant ainsi des parasites qui polluent la communication.

Je propose donc de faire d'abord un test avec un câble le plus court possible
et un seul capteur connecté, le temps de vérifier qu'il n'y a aucune panne logicielle.

Dernière modification par MicP (09-11-2016 12:37:04)

Hors ligne

#4 27-12-2016 19:23:28

guillaumebs
Membre
Distrib. : debian
Noyau : linux 3.16.0-4-amd64
(G)UI : icewm + zsh
Inscription : 25-12-2016

Re : Problème d'identification de sonde de température DS18B20

hello,

malheureusement l'I2C est p-e le bus le moins recommandé pour des cablages long car il est bidirectionnel, on passe notre temps à charger/décharger des buffer "tri-state" qui basculent entrée/sortie (c'est d'ailleurs à cause de eux qu'on peut à peine espérer atteindre + de 400 kHz de fréquence d'horloge), et la longueur de cable rajoute de l'inductance au système.

1/ reste en fréquence faible (100kHz),
2/ travail d'abord à faible distance

3/ renforcer la verification des handshake peut aider, avec <erno.h> tu peux savoir si le byte n'est pas acknowledgé et donc le renvoyer tant que cela n'est pas vrai: les transactions sont plus longues mais à l'issu tu as au moins une transaction valide,

4/ il te faut certainement jouer avec la résitance de pull-up, si tu estimes l'inductance introduite à 30pF/m (je connais pas la bonne estimation), tu introduis 0.6nF d'inductance. Si tu utilises 4.7kOhm de résistance, tu crée un filtre passe bas qui coupe à wc=1/rc=355kHz.Si tu as un scope tu peux vérifier l'effet de ce filtre sur les créneaux au niveau des sondes, le tout étant de respecter la doc constructeur

edit: j'utilise ta valeur de résistance

Dernière modification par guillaumebs (27-12-2016 19:26:05)

Hors ligne

Pied de page des forums