DS18b20,résolution aléatoire ?

Bonjour,

j'observe un phénomène que je ne m’explique pas concernant la mesure de température à partir de plusieurs sondes DS18b20. 3 sont sur le même arduino pro mini, un autre est seule sur un autre pro mini.

Quand je relève les données, j'observe que sur les 3 sondes connectées en mode onewire , l'une est en 9 bits (0.5 degré de pas), les deux autres en 12 bits (0.0625 de pas).

Sur le second dispo, les données sont en 10 bits (0.25 de pas), comme je relève aussi la températuer du chip RTC, il est en 12 bits.

Je suis étonné car en principe les DS18b20 sont par défaut en 12 bits.

J'ai revérifié mes codes, je ne vois pas de raison de ce comportement.

Est-ce lié au fait que les délais que j'ai imposés entre chaque mesures sont faibles (10ms) alors que le temps de conversion est franchement plus important (de 93.75ms à 750ms entre les 9 bits et les 12 bits) ?

Bon, ça n'a pas grande importance car la précision est de 0.5 degré et je ne suis pas sûr que mes plantes se plaignent d'une gestion de la température aussi approximative...

Cordialement

Votre chip RTC a une température ... qui est la température du chip (ne rigolez pas : j'ai sur RPi une carte qui mesure entre autres la température; comme elle est littéralement sur le RPi, elle mesure ... la température des radiateurs!)
Vos cadences d'échantillonnage sont proprement infernales, au vu des temps de réaction des plantes (même un escargot est plus rapide qu'une plante, sinon, il ne pourraît pas se sustenter). Transposer à une plante est courageux....

Si votre diagnostic est précis -et je n'en doute pas-, pourquoi ne pas prendre le temps de faire les mesures lentement?
Par ailleurs, un traitement par médiane sur les trois voies améliorerait un peu la précision -et résisterait à une panne d'un capteur-

en fait, je ne travaille pas à la cadence infernale que vous pensez :slight_smile:

j'acquiers les données toutes les 15 mn et entre deux mesures, je mets en veille le système. Donc ce n'est que l'envoi qui est en rafale peut-être (sans doute) trop rapide. Les trois données correspondent à trois sites défférents (serre à 1 mètre, et deux réserves d'eau tampon

Je mesure toutes les 15 mn pour une raison simple, ce sont des données en serre et en particulier en période très froide, une panne de chauffage de 1 heure ce sont de vrais dégâts dans la serre (situation vécue deux ou trois fois). Donc en parano que je suis, je contrôle fréquemment l'évolution des températures et quand les données deviennent critique ça buzze dans la maison.

Cordialement

Bonjour
J'utilise selon les cas les DS18B20 dans l'une des 4 résolutions possibles
Je n'ai jamais rencontré de changement spontanné, il faudrait pour cela que le registre Config change tout seul de valeur. (alim à problème ? câblage ?)

Testez avec les temporisations normales -mettons une seconde : ca rajoutera 3 secondes à votre traitement, 0.3% des temps de cycle -et je parie que vos arduini sont sur batterie chargeable, à la maison: dans ce cas, quelle est la longueur des fils?-

Je suis moi aussi étonné de ces changements de résolution spontanés.

Je vais effectivement ajouter des délais d'une seconde pour laisser le temps à la conversion.

j'avoue que je n'ai à ce jour pas pris garde du temps de conversion et ça marche depuis pas mal de temps. j'aurais attendu que ça plante...

C'est en peaufinant mes détections que j'ai observé ce comportement. Il m'avait échappé car comme j'utilise thingspeak et que j'utilise ses capacités de lissage, ça ne m'avait pas sauté aux yeux.

Pour répondre à al1ch, c'est vrai que l'une des sondes (qui marche en 12 bits) est à 8 mètres du MCU. Celle qui fonctionne à 9 bits est la plus proche du MCU (moins d'un mètre.)

Enfin, la résistance de pullup est proche du MCU donc éloignée d'e 1 mètre (9 bits), 2 mètres(12 bits) et 8 mètres(12 bits) du capteur.

Tu utilises la librairie DallasTemperature ?

Oui j'utilise la bibliothèque DallasTemperature.

Hello,
Sans forcément résoudre le problème source, mais la librairie Dallas dispose de méthode pour forcer la résolution de la mesure, et de verivéri la résolution courante. L'utilisation permettrai peut être d'obtenir des mesures stables de ce point de vue

[color=#24292e][color=#6a737d]// get global resolution[/color]
[color=#005cc5]uint8_t[/color] [color=#6f42c1]getResolution[/color]();

[color=#6a737d]// set global resolution to 9, 10, 11, or 12 bits[/color]
[color=#d73a49]void[/color] [color=#6f42c1]setResolution[/color]([color=#005cc5]uint8_t[/color]);

[color=#6a737d]// returns the device resolution: 9, 10, 11, or 12 bits[/color]
[color=#005cc5]uint8_t[/color] [color=#6f42c1]getResolution[/color]([color=#d73a49]const[/color] [color=#005cc5]uint8_t[/color]*);
[color=#6a737d]
//[/color][color=#6a737d] set resolution of a device to 9, 10, 11, or 12 bits[/color]
[color=#d73a49]bool[/color] [color=#6f42c1]setResolution[/color]([color=#d73a49]const[/color] [color=#005cc5]uint8_t[/color]*, [color=#005cc5]uint8_t[/color],
			[color=#d73a49]bool[/color] ski


Source [iurl=https://github.com/milesburton/Arduino-Temperature-Control-Library/blob/master/DallasTemperature.h]https://github.com/milesburton/Arduino-Temperature-Control-Library/blob/master/DallasTemperature.h[/iurl][/color]

Oui, c'est juste DallasTemperature possède les outils pour fixer la resolution, c'est sans doute ce que je vais faire si je ne trouve pas la raison de ce comportement bizarre.

Bonsoir,
la résolution est écrite en EEPROM de la sonde, tu as peut être testé ces sondes avec un exemple qui a modifié la résolution d'usine

C'est peut-être la raison. C'est vrai que lors de mes tous premiers essais j'ai fait quelques tests de résolution, mais tout ça est loin. Ca signifierait que la résolution modifiée reste modifiée même dans une autre application (enregistrement dans l'EEPROM) ?

Je vais testé deux solutions :

  • la première c'est d'augmenter le temps d'attente entre deux acquisitions
  • la seconde, en forçant la résolution.

De plus les acquisitions sont effectuées non pas par analyse à chaque cycle des capteurs présents mais en fournissant les adresses déterminées par onewire finder. C'est la seule opération effectuée avant chargement du fichier. Il n'y a rien dans ce fichier qui puisse modifier la résolution.

L'électronique reste un grand mystère...

La librairie DallasTemperature fournit des routines toutes prêtes :

  sensors.setWaitForConversion(true);

// ou 

  int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
  delay(conversionTime);

Dans le deuxième cas, delay peut être remplacé par une mise en sommeil si utile.
Sinon autant utiliser setWaitForConversion(true)

je viens de forcer la résolution avec la commande :

sensors.setResolution("le nomde mon capteur", 12);

Ça a l'air de marcher, les 3 sont en 12 bits. Donc si je comprends bien comme c'est enregistré dans la mémoire du capteur, si je supprime la ligne de commande ci-dessus, il devrai rester en 12 bits ?

Merci hbachetti pour l'info, je n'avais pas fouillé les commandes de dallas, c'est intéressant, je vais ajouter la ligne de commande, c'est plus intelligent que coller des delays partout...

edit : c'est ajouté et ça marche... Alles ist in Ordnung.