DS18S20 Fehler ab ca. 40°C

[Sascha G. (sash)]

Hallo an alle Bastelfreudigen.

Habe hier ein ziemlich großes Problem, bei dem ein Kumpel und ich 
einfach nicht weiter kommen.

Es geht um den oben genannten Sensor DS18S20 von Maxim.

Sensor wird einmal an einer SPS-Ctrl ( 
http://www.mikrocontroller.com/de/SPS-ctrl.php ) mit einem Mega644p und 
einmal an einer selbst entwickelten Schaltung mit einem Mega32 
betrieben.

Wichtig:
*Es tritt bei beiden Schaltung der selbe Fehler auf, wodurch ein 
Hardwaredefekt eigentlich ausgeschlossen werden kann.

*In der Application Note von Maxim ist ein 1-wire Bustreiber 
beschrieben. Der Fehler tritt ebenfalls mit Bustreiber und ohne 
Bustreiber auf (beide Schaltungen mit und ohne Treiber).

*Die Adressen der Sensoren lassen sich einwandfrei auslesen.

*Temperatur des Sensores lässt sich im negativen Bereich bis ca. -40°C 
auslesen (so kalt macht das Kältespray) ohne Fehler.

*Fehler tritt bei allen getesteten Sensoren auf.

*2 verschiedene Vertriebshändler.

Das Problem:
Wird der Sensor nun erwärmt und die Temperatur ist ungefähr bei 40°C, 
dann macht der Sensor nichts mehr und sendet im gesamten SCRATCHPAD nur 
noch logisch "1" zurück (Logic Analyzer sei dank).

Ein weiterer Versuch bei besagten 40°C die Adresse des Sensores 
auszulesen schlägt ebenfalls fehl und man bekommt nur FFh zurück 
geliefert.

Kühlt man den Sensor nun wieder ab, dann zeigt er wieder die richtige 
Temperatur an und die Adresse lässt sich auch wieder auslesen.

Ich habe hier mal den Code vom DS18S20 mit angehängt.
Es werden die Funktionen "void 
DS18S20_Sensor_Wandlung_starten_highres(uint8_t Nummer)" und "float 
DS18S20_Sensor_auslesen_highres(uint8_t Nummer)" benutzt.

Wir haben keine Idee mehr, an was es liegen könnte.
Nun seid Ihr dran ;-)
Kennt einer dieses Problem?

Gruß
Sascha

[Sascha G. (sash)]

Kleiner Nachtrag.
Hier noch die 1-wire Routine

Gruß
Sascha

[(prx) A. K. (prx)]

Nach dem Start der Messung sollte man min. 750ms warten, bevor man das 
Ergebnis ausliest. Nicht 6ms (woher?).

[Sascha G. (sash)]

Hallo,

also es wird sogar eine ganze Sekunde gewartet, bis der Wert nach dem 
Wandeln ausgelesen wird.

Quasi:
Wandlung starten;
delay 1 sek;
Wert auslesen;

Gruß
Sascha

[Peter D. (peda)]

mögliche Fehler:

- Timing falsch berechnet
- Leitung zu lang
- Pullup zu groß


Peter

[eProfi (Gast)]

Parasite-Power oder externe 5V?
wenn Parasite, dann muss Vcc auf Gnd gelegt werden.

Berichte bitte auf jeden Fall, wenn Du die Lösung gefunden hast.

[Sascha Geßler (Gast)]

Die Sensoren werden mit +5V versorgt.
Zu lange Leitung kann ich ausschliessen, die Sensoren sind direkt am AVR 
dran (5cm Leitung). Das Timing und der Abtastzeitpunkt passen auch.
Was bringt den Sensor aber dazu, bei der Ausgabe der 9 Bytes neun Mal 
hintereinander 0xFF zu senden? Ich habe das mit dem Oszi und dem 
Logicanalyzer angeschaut. Ein falsches Timing würde ja zu einem falschen 
Sampel-Zeitpunkt führen. Aber der Sensor gibt definitiv 9 mal 
hintereinander 0xFF aus.

[Anselm 6. (anselm68)]

PullUp vergessen oder gegen GND?
;)

[Sascha G. (sash)]

Weder noch!
Denn immerhin geht ja die Messung bis ~+40°C und ohne einen Pull Up oder 
Pull Up gegen GND würde da sicher nichts rauskommen.

[Peter D. (peda)]

Sascha Geßler schrieb:
> Das Timing und der Abtastzeitpunkt passen auch.

Wie hast Du das geprüft?

Es kann ja keiner sehen, wie Dein Timing ist.
Warum nimmst Du nicht die _delay_us() aus der AVR-GCC Lib?


> Was bringt den Sensor aber dazu, bei der Ausgabe der 9 Bytes neun Mal
> hintereinander 0xFF zu senden?

Wenn er das Kommando nicht verstanden hat, sendet er auch nichts.


Nimm mal 4,7k als Pullup.

Was soll das überhaupt mit dem N-FET?
Der ist überflüssig:
- Init: Port-Bit = 0
- Pin auf low: DDR-Bit = 1
- Pin auf Input: DDR-Bit = 0
fertig ist der Open-Drain Pin.


Peter