[paulfjujo]

Bonjour à tous ,

Probleme de durée d'acquisition d'une mesure capteur OWS
Apres avoir testé 3 sondes DS18B20 sur un meme bus OWS , avec gestion des ID # ... OK
je teste actuellement la version 1 bus --1 sonde

nota 1: résolution 12bits +- 0,0625°C

donc avec 3 bus OWS pour RA0,RA1,RA2
Sur une demande d'acquisition de mesure via la requette 0x44

Code : Tout sélectionner


Convert T [44h]
This command initiates a single temperature conversion.
Following the conversion, the resulting thermal data is
stored in the 2-byte temperature register in the scratchpad memory and the DS18B20 returns to its low-power
idle state. If the device is being used in parasite power
mode, within 10µs (max) after this command is issued
the master must enable a strong pullup on the 1-Wire bus
for the duration of the conversion (tCONV) as described
in the Powering the DS18B20 section. If the DS18B20 is
powered by an external supply, the master can issue read
time slots after the Convert T command and the DS18B20
will respond by transmitting a 0 while the temperature
conversion is in progress and a 1 when the conversion is
done.
 

j'obtiens la mesure après 780mS ! , alors qu'en utilisant un delay de 485µS ( notion de time slot 480µs)
j'obtiens < de 100mS !
780x3=> .. 2,34sec ..delay redibitoire pour mon appli finale ..
j'ai bien noté aussi qu'une résolution de 11 bits diviserait par 2 le temps maxi de 780mS ...
....mais si c'est bon avec 485µS !!!

DS18B20_Config_Resolution.jpg

exemple avec T2
réponse en 780mS avec attente lecture bit apres lancement lecture temper 0x44
exemple T1 et T3
réponse en 100mS avec __delay_us(485); apres lancement lecture temper 0x44

Code : Tout sélectionner


float getTemperature2()
{
  unsigned char i;
  float temperature1;
  unsigned char scratchPad[9] = {0,0,0,0,0,0,0,0,0};
  onewireInit_1();
  onewireWriteByte_1(0xCC);
  onewireWriteByte_1(0x44);
//  780mS  avec le test ci dessous
//  while (1) {
//   if (onewireReadBit_1())  // au moins 1 capteur connecté
//      break;
// }
 // 100 ms global avec le delay
  __delay_us(485);
  onewireInit_1();
  onewireWriteByte_1(0xCC);
  onewireWriteByte_1(0xBE);
  for (i = 0; i < 2; i++)  scratchPad[i] = onewireReadByte_1();
  onewireInit_1();
  temperature1 = ((scratchPad[1] * 256) + scratchPad[0])*0.0625;
  return temperature1;
}


(0.000) 00000 T1.INTER.= 18.437 ° C
(0.790) T2.EXTER.= 19.000 ° C
(0.109) T3.EAU = 18.250 ° C
(0.070)
(0.060) 00001 T1.INTER.= 18.375 ° C <-avec __delay_us(485); apres lancement lecture temper 0x44
(0.745) T2.EXTER.= 19.000 ° C <-avec attente lecture bit apres lancement lecture temper 0x44
(0.094) T3.EAU = 18.250 ° C <-avec __delay_us(485); apres lancement lecture temper 0x44
(0.085)
(0.077) 00002 T1.INTER.= 18.437 ° C
(0.729) T2.EXTER.= 19.062 ° C
(0.096) T3.EAU = 18.250 ° C
(0.089)
(0.005) 00003 T1.INTER.= 18.437 ° C
(0.795) T2.EXTER.= 19.062 ° C
(0.098) T3.EAU = 18.250 ° C
(0.082)

ça m'arrange bien .. mais j'aurais bien voulu comprendre !
et ne pas avoir une solution "qui tombe en marche "

Est-ce parce que les mesures ne sont pas contigües ? ( à la queue leue leue sur le meme bus ) ?


avec delay 485µ sur chaque mesure et un delay de boucle de 1 sec

[i](0.998) 00021
(0.097) T1.INTER.= 19.250° C
(0.034) T2.EXTER.= 19.812 °C
(0.072) T3.EAU = 19.750 °C
(0.090)
(0.991) 00022 <--- delay de boucle 1sec
(0.048) T1.INTER.= 19.250° C
(0.055) T2.EXTER.= 19.812 °C
(0.102) T3.EAU = 19.750 °C
(0.077) <--- delay de boucle 1sec
(1.000) 00023
(0.073) T1.INTER.= 19.250° C
(0.043) T2.EXTER.= 19.812 °C
(0.083) T3.EAU = 19.750 °C


votre avis ?


à suivre ...

[satinas]

Bonjour Paul,
Cela correspond à quoi tes 485us ?
Je viens de faire un essai avec un capteur DS18B20, reçu à l'époque d'Arduino.
Traduction en ASM de ce programme et merci à lui.
Par défaut on est en 12 bits, et j'ai bien environ 700ms d'attente avant lecture de la température. Si tu lis le résultat avant que le flag passe à ready, la mesure sera incertaine.
Remarque : Le DS1621 n'est pas aussi précis, il retourne la température seulement à 0,5°près, il serait bon de le remplacer par un DS18B20, serait-ce une coïncidence que tu en parles ? :)

[paulfjujo]

bonjour Satinas,

Merçi de toujours répondre à mes élucubrations..

Oui effectivement, tous les exemples montre un delay de 700mS
ce que j'ai observé aussi , en testant le bit de réponse

mon delay de 485µS .. uniquement pour etre > au time slot de 480µS qui entraine un reset bus OWS
mais j'obtiens aussi une mesure coherente avec un delai de 250µS !!! seulement

If the DS18B20 is powered by an external supply, the master can issue “read time slots”
(see the 1-Wire Bus System section) after the Convert T command and the DS18B20 will respond by
transmitting 0 while the temperature conversion is in progress and 1 when the conversion is done.

paragraph CONVERT T[44h]
the DS18B20 is powered by an external supply, the master can issue read time slots after the
Convert T command and the DS18B20 will respond by transmitting a 0 while the temperature
conversion is in progress and a 1 when the conversion is done.

WRITE TIME SLOTS
master read 0 slot 60µS
master read 1 15µS
le plus mauvais des cas de lecture de 12 bits à 0 =>12 x60 ..serait de 720µS
720µS et non pas 720 mS !

il est question de 750mS MAX (en 12bits) et le MIN c'est combien ?

je recherche surtout pourquoi 750mS ?
aucune explication dans la data sheet ?
quel rapport avec des time slots donnés en µS

je vais verifier si j'ai bien toute la dynamique de mesure en 12Bits avec le delay de 485µS ..
Eau chaude (> 56°C ) et aussi temperature negative (congelo -14°C)
..à suivre .

je viens de tester en mettant mon capteur DS18B20 , corps en inox contre le corps de mon fer à souder 40W
entouré d'un fil de cuivre pour les maintenir en contact et en rajoutant un capteur sonde thermocouple de diametre < 2mm
relié à mon multimetre FI515X ( prévu pour !) pour visu en °C sur le multimetre et en meme temps ,via le terminal YAT
l'evolution de temperataure
montée tres rapide à 100°C, debranché le fer et suivi de la descente
Le thermocouple descend plus vite car tres faible inertie thermique !

Code : Tout sélectionner


mais les mesures sont tres coherentes
DS18B20      (sans les 3 decimales !)          81  ,  74  ,  67 ,  55 ,  37  ,  34 ,  31 ,  27 ,   25 ,  24 ,   23 ,   22 ,   21,  20 ,  19.75 , 18.25, ....... 17.62
Thermocouple  (resolutuion 1°C !)              80  ,  72  ,  65 ,  51 ,  34  ,  31 ,  29 ,  25  ,  23 ,  22 ,   21 ,   20 ,   19,  18 ,  18      , 17    ,.......   17


reste à deplacer mon proto vers le frigo .....

[satinas]

Les time slots correspondent aux spécifications de timing relatifs aux reset et read/write data.
Les 750ms correspondent au temps de conversion de l'ADC en résolution max 12 bits. Si tu lis trop vite, tu récupères peut-être l'ancien résultat de conversion. Yaka diminuer la résolution.
Par contre ma question c'est à quoi bon une résolution de 0,0625°, je doute que la justesse du capteur soit à la hauteur de cette résolution. Cela peut quand même servir pour mesurer des variations de température.

[paulfjujo]

......
Les 750ms correspondent au temps de conversion de l'ADC en résolution max 12 bits.
Si tu lis trop vite, tu récupères peut-être l'ancien résultat de conversion. ....

Les 750ms correspondent au temps de conversion de l'ADC en résolution max 12 bits.
on voit ça où ?
à par des valeurs MAXI , dans le tableau de la spec sheet ..

J'ai bien compris que la résolution n'est pas la précision .
precision données +-0.5°C dans la gamme -10 à +85°C
mais un gage pour verifier la répétabilité ,ou la tendance d'évolution ..
Dans l'application finale ,la mesure sera arrondie au 1/10em de °C
ou bien la resolution sera diminuée .. tests en cours la-dessus

je pense effectivement que je doits recupérer la mesure precédente ...qui a lieu , au minima à 2 cycles (des 2 mesures) précédentes
(J'ai 3 bus OWS) + le temps d'affichage terminal et LCD
mais SANS delay dans ma boucle principale; donc à fond les ballons ,
j'obtiens quand meme mes 3 (memes) mesures sur un cycle global de 300mS !

les 3x 750mS necessaires à la conversion ADC n'y sont pas.
Mystere et boule de suif !

On ne nous dit pas tout !

exemple:

Code : Tout sélectionner

((10:25:37.706) (0.000)  00362
(10:25:37.706) (0.000)  T1.INTER.= 17.500° C
(10:25:37.768) (0.061)  T2.EXTER.= 23.437 °C
(10:25:37.863) (0.094)  T3.EAU = 17.500 °C
(10:25:37.948) (0.085) 
(10:25:37.951) (0.003)  00363
(10:25:37.960) (0.008)  T1.INTER.= 17.500° C
(10:25:38.055) (0.095)  T2.EXTER.= 23.875 °C
(10:25:38.150) (0.094)  T3.EAU = 17.500 °C
(10:25:38.235) (0.085) 
(10:25:38.239) (0.004)  00364
(10:25:38.246) (0.007)  T1.INTER.= 17.500° C
(10:25:38.341) (0.094)  T2.EXTER.= 23.875 °C
(10:25:38.436) (0.094)  T3.EAU = 17.500 °C
(10:25:38.561) (0.124) 
(10:25:38.561) (0.000)  00365
(10:25:38.561) (0.000)  T1.INTER.= 17.500° C
(10:25:38.628) (0.067)  T2.EXTER.= 23.875 °C
(10:25:38.739) (0.110)  T3.EAU = 17.500 °C
(10:25:38.808) (0.068) 
(10:25:38.810) (0.002)  00366
(10:25:38.821) (0.010)  T1.INTER.= 17.500° C
(10:25:38.916) (0.095)  T2.EXTER.= 24.312 °C
(10:25:39.009) (0.092)  T3.EAU = 17.500 °C
(10:25:39.094) (0.085) 


[satinas]

on voit ça où ? à par des valeurs MAXI , dans le tableau de la spec sheet

C'est max car cela doit être la fréquence minimale de l'horloge de l'ADC, si on tient compte de la dispersion de fabrication.
J'ai fait quelques essais de lecture prématurée après 1ms, 10ms, 50ms, 150ms, 350ms, 550ms, puis attente flag. On voit bien qu'il prend la dernière valeur écrite dans la ram, à 550ms environ il arrive à avoir la nouvelle valeur convertie.

Code : Tout sélectionner

1ms  10   50   150  350  550  flag
0181 0181 0181 0181 0181 017E 017E
017E 017E 017E 017E 017E 017E 017E
017E 017E 017E 017E 017E 017F 017F
017F 017F 017F 017F 017F 017F 017F
017F 017F 017F 017F 017F 017F 017F
017F 017F 017F 017F 017F 017F 017F
017F 017F 017F 017F 017F 017F 017F
017F 017F 017F 017F 017F 0180 0180
0180 0180 0180 0180 0180 0180 0180
0180 0180 0180 0180 0180 0182 0182
0182 0182 0182 0182 0182 0187 0187
0187 0187 0187 0187 0187 018D 018D
018D 018D 018D 018D 018D 0190 0190
0190 0190 0190 0190 0190 0190 0190
0190 0190 0190 0190 0190 018F 018F
018F 018F 018F 018F 018F 018E 018E
018E 018E 018E 018E 018E 018D 018D
018D 018D 018D 018D 018D 018D 018D
018D 018D 018D 018D 018D 018C 018C
018C 018C 018C 018C 018C 018C 018C
018C 018C 018C 018C 018C 018C 018C
018C 018C 018C 018C 018C 018B 018B
018B 018B 018B 018B 018B 018A 018A
018A 018A 018A 018A 018A 018A 018A
018A 018A 018A 018A 018A 018A 018A
018A 018A 018A 018A 018A 0189 0189


[paulfjujo]

pas avant 550mS ?

Les mesures sont pourtant bien converties et rafraichies .. à chaque tour de boucle et forcément sur le bon capteur
... d'autant que j'ai un bus OWS different par capteur

il y a un truc qui nous échappe ...

mais je ne vais pas faire une these la-dessus...pas assez de neurones .

en attendant:

Tests avec resolution sur 11 bits
AVEC DELAY puis avec Test bit , en compilant Avec ou sans le
//#define AVEC_TEMPO

Code : Tout sélectionner



float getTemperature1()
{
  unsigned char i;
  float temperature0;
  unsigned char scratchPad[9] = {0,0,0,0,0,0,0,0,0};
  onewireInit_0();
  onewireWriteByte_0(0xCC);
  onewireWriteByte_0(0x44);
#ifdef AVEC_TEMPO
   __delay_us(485);
  #else
  //  780mS  avec le test bit ci dessous en 12 bits ,  ou  352ms en 11 bits
  while (1) {
  if (onewireReadBit_0())  // au moins 1 capteur connecté
     break;
 }
#endif
   onewireInit_0();
  onewireWriteByte_0(0xCC);
  onewireWriteByte_0(0xBE);
  for (i = 0; i < 2; i++)  scratchPad[i] = onewireReadByte_0();
  onewireInit_0();
  temperature0 = ((scratchPad[1] * 256) + scratchPad[0])*0.0625;
  return temperature0;
}

 

Nouveaux tests en mode 11 bits +-0,125°C
AVEC Tempo apres requete 0x44
#define AVEC_TEMPO
10 series de 3 mesures
14:18:25:961 - 14:18:22805 = 3,1sec
103mS par mesure ( incluant l'afichage Terminal + affichage LCD)

on voit bien ici que la resolution est de +-0.125 °C au lieu de +-0.0625 °C

Code : Tout sélectionner

(14:18:22.805)  00400
(14:18:22.805)  T1.INTER.= 17.875° C
(14:18:22.891)  T2.EXTER.= 19.125 °C
(14:18:22.986)  T3.EAU = 17.750 °C
(14:18:23.072) 
(14:18:23.099)  00401
(14:18:23.099)  T1.INTER.= 17.875° C
(14:18:23.181)  T2.EXTER.= 19.125 °C
(14:18:23.275)  T3.EAU = 17.750 °C
(14:18:23.361) 
... etc ...
(14:18:25.426)  00409
(14:18:25.426)  T1.INTER.= 17.875° C
(14:18:25.491)  T2.EXTER.= 19.125 °C
(14:18:25.586)  T3.EAU = 17.750 °C
(14:18:25.672) 
(14:18:25.721)  00410
(14:18:25.721)  T1.INTER.= 17.875° C
(14:18:25.782)  T2.EXTER.= 19.125 °C
(14:18:25.876)  T3.EAU = 17.750 °C
(14:18:25.961) 


le mem test tests en mode 11 bits +-0,125°C
avec //#define AVEC_TEMPO
donc avec le test bit apres requete 0x44
10 series de 3 mesures
14:23:38.810 - 14:23:28.229 =10,58 sec
donc 0.352 sec par mesure ( incluant l'afichage Terminal + affichage LCD)

Code : Tout sélectionner

(14:23:28.229)  00010
(14:23:28.541)  T1.INTER.= 17.875° C
(14:23:28.986)  T2.EXTER.= 19.250 °C
(14:23:29.082)  T3.EAU = 17.750 °C
(14:23:29.166) 
(14:23:29.195)  00011
(14:23:29.506)  T1.INTER.= 17.875° C
(14:23:29.950)  T2.EXTER.= 19.250 °C
(14:23:30.045)  T3.EAU = 17.750 °C
(14:23:30.131) 
... etc .....
(14:23:36.911)  00019
(14:23:37.221)  T1.INTER.= 17.875° C
(14:23:37.665)  T2.EXTER.= 19.250 °C
(14:23:37.760)  T3.EAU = 17.750 °C
(14:23:37.846) 
(14:23:37.874)  00020
(14:23:38.185)  T1.INTER.= 17.875° C
(14:23:38.631)  T2.EXTER.= 19.250 °C
(14:23:38.724)  T3.EAU = 17.750 °C
(14:23:38.810) 


On ne peut nier l'evidence ,même incomprise !

mais pour ne pas arriver au fameux cas :
"tomber en marche" ( sic "DAUDET78" à qui je passe bien le bonjour)
je privilegerai le mode test bit ..
352 ms par mesure devant etre jouable pour l'application finale .

sujet clos ? ..pas encore
non, il faut que je teste encore , sonde dans le congelo ...

[satinas]

Je ne vois pas ce qui t'échappe, la doc est claire, voir figure 13 et 14.
Une lecture se déroule ainsi, avec 2 transactions :

- Master tx reset (ce que tu appelles delay 485us)
- le capteur répond présent
- commande 0xcc skip rom
- commande 0x44 start convert
- attente flag conversion finie par polling

- Master tx reset
- le capteur répond présent
- commande 0xcc skip rom
- commande 0xbe read scratchpad
- lecture datas

Dans mes essais plus haut j'ai sauté l'attente flag conversion finie. Les 550ms sont théoriques, il y a aussi de l'affichage et de l'envoi uart, cela doit plutôt tourner aux alentours des 700ms, comme annoncé.

[paulfjujo]

bonjour à tous,

Je ne vois pas ce qui t'échappe, la doc est claire, voir figure 13 et 14.

Oui, je suis d'accord avec toi, la doc est claire , si on l'applique telle quelle.

Ce qui m'echappe, c' est COMMENT peut-on arriver à un delai de mesure de 103mS ?
en utilisant un delay de 485µS à la place du test bit ?
d'ailleurs ce delay peut meme etre reduit à 250µS !

si on regarde l'organigramme , si je strappe le test bit avec mon delay ..
comment la conversion se finit-elle OK , apres seulement 480µS ? datas lues dans le scratchpad via 0xBE ..OK !
il y a ici une incoherence .

je vais tester en faisant une RAZ scratchpad juste avant de lancer la conversion 0x44 ..pour voir si c'est la mesure
réellement en cours ou la reminescence d'une conversion precedente !

En fait si j'insiste , c'est parceque le delay de 750mS x 3 mesures , devient trop préponderant dans mon application finale..
où interfere la gestion de 5BP (Boutons Poussoirs) et des Menus de choix sur LCD ...
Le fait d'utiliser la resolution à 11bits reduit deja le delay du test bit à 350mS ..c'est mieux mais insuffisant..

J'avais pensé à intercaler une condition dans le test bit .. si detection appui sur un BoutonPoussoir (parmi 5)
Flag INTerruption levé => pour faire sortir du test bit en cours et annuler la mesure en cours pour pouvoir traiter
immediatement l'etat B.P activé...

A moins que sortir du test bit apres plus de 750mS , voir 10 à 30 secondes, n'affecte pas la mesure qui sera stockée dans le scratchpad ?
à tester ...

donc encore quelques pistes de tests à suivre ...c'est chiant..mais formateur ..

et la maxime de jeremy :
....C'est en faisant des erreurs, que l'on apprend le mieux !!!

c'en est presque à regretter l'usage prevu au depart avec un LM35 analogique
+ ADC 12b conversion en < 1mS ...

je vais aller voir aussi des avis coté futura..

[satinas]

Bonjour
Tu confirmes que tu obtiens 2 températures différentes espacées de 100ms ?
Pourquoi parles-tu de 3*750ms alors que tu as 3 bus, un par capteur ?
S'il n'y a qu'un seul bus, on doit pouvoir lancer une par une les 3 mesures, attendre 750ms et récupérer les 3 mesures.

J'ai mesuré la durée de la conversion avec un timer (attente du flag) , j'obtiens le plus souvent 600ms, il faudrait vérifier avec d'autres températures, l'ADC a peut être des temps de réponse variables, selon sa technologie.
Colonne 1 -> numéro mesure
Colonne 2 -> durée de conversion à multiplier par 65,536 ms et des brouettes
Colonne 3 -> mesure en hexa
Colonne 4 -> mesure en décimal

001 009 0183 24.1875
002 009 0183 24.1875
003 009 0183 24.1875
004 009 0184 24.2500
005 009 0184 24.2500
006 009 0184 24.2500
007 009 0185 24.3125
008 009 0185 24.3125
009 009 0185 24.3125
010 009 0185 24.3125
011 009 0185 24.3125
012 009 0186 24.3750
013 009 0186 24.3750
014 009 018A 24.6250
015 009 0196 25.3750
016 009 019E 25.8750
017 009 01A4 26.2500
018 009 01AA 26.6250
019 003 01AA 26.6250
020 004 01AE 26.8750
021 009 01B2 27.1250
022 009 01B3 27.1875
023 009 01B5 27.3125
024 009 01B7 27.4375
025 009 01BA 27.6250
026 009 01BC 27.7500
027 009 01BD 27.8125
028 009 01BF 27.9375
029 009 01BD 27.8125
030 009 01BB 27.6875
031 009 01BA 27.6250
032 009 01B7 27.4375
033 009 01B7 27.4375
034 009 01B5 27.3125
035 009 01B4 27.2500
036 009 01B3 27.1875
037 009 01B3 27.1875
038 009 01B3 27.1875
039 009 01B2 27.1250
040 009 01B2 27.1250
041 009 01B2 27.1250
042 009 01B1 27.0625
043 003 01B1 27.0625
044 004 01B1 27.0625
045 009 01B0 27.0000
046 009 01AF 26.9375
047 009 01AE 26.8750
048 009 01AD 26.8125
049 009 01AD 26.8125
050 009 01AC 26.7500
051 009 01AC 26.7500
052 009 01AB 26.6875
053 009 01AB 26.6875
054 009 01AA 26.6250
055 009 01A9 26.5625