Hallo, ich hab ein DS18S20 Digitalthermometer an einen atmega angeschlossen. Dieser liefert aber leider immer falsche Temperaturdaten zurück, die oberhalb des angegeben Messbereichs liegen (über 85 °C). Ich bin relativ sicher, dass ich das Protokoll selbst richtig implementiert habe, da die CRC Summe stimmt und beim lesen des Scratchpads die reservierten Bytes wie im Datenblatt angegeben 0xFF beinhalten. Die Stromversorgung läuft nicht über die Datenleitung und ich gebe den Befehl die Temperatur zu messen und warte über zwei Sekunden bevor ich sie wieder auslese. Hat irgendjemand eine Idee, was die Ursache für diess Problem sein könnte? Haben Werte wie 0xAF bis 0xB5 (die bekomme ich zurückgeliefert) irgend eine spezielle Bedeutung? Vielen Dank, Roland
hallo wie sieht dann dein programm aus?!? also ich hab mir letztes wochenende auch ein temperatursensor gebaut mit zwei solchen dingern. ich hatte das problem, dass ich das byte in der falschen reihenfolge eingelesen habe. "dreh" mal deine werte um...könnte es dann stimmen?!? hast du das timing eingehalten?! gruss fabian
Hi. Ich denke die Reihenfolge sollte stimmen. Wenn nicht wäre auch die Checksumme falsch, oder? Ich hab das Programm beigefügt. Der Teil mit dem DS18S20 ist in Thermo.c
hallo habe jetzt leider keine zeit um alles durchzuschauen...sieh aber ziemlich vernünftig aus, vielleicht stimmt das timing nicht. versuch dich mal nach der Application Note 162 (app162.pdf) zu richten vielleicht klappts dann. gruss fabian
Hi Fabian, befasse mich ja nun auch seit 2 Tagen mit dem DS18S20 und hab da auch schon einiges durchgemacht ;) lol Wenn Du magst kannst ja mal per Mail schreiben, vieleicht kann man ja Projekt erfahrungen austauschen. Hast du eigendlich vorher den binär wert durch 10 geteilt ? Dein Code ist leider in C und damit hab ich null erfahrungen. Mache nur in ASM seit ca. 3 Wochen. Der DS18S20 gibt ja bei 85°C binär 10101010 im LSB aus, das entsprich Dezimal 170 (Geteilt durch 2 ergibt das 85°C) Gruß Dennis
Hallo Dennis, ja ich teile den Wert durch 2. Der DS18S20 liefert mir Werte wie 0xAF und größer zurück. Wenn ich das durch 2 Teile, dann erhalte ich 87. Ich bin auch recht sicher, das die Reihenfolge stimmt, da 0xF5 (0xAF umgedreht) noch größer wäre. Es sind auch keine negativen Zahlen, da das zweite Byte im Scratchpad 0 ist.
Hmm ich hab gerade mal versucht deinen Code zu testen, aber ich bekomme da immer nur den CRC-Error. Liegt aber bestimmt am timeing. Mit wieviel Mhz läuft denn dein atmega? Hab das mal getestet an nem at90s8535 mit 8 Mhz und einem DS1820.
Meiner hat 16 Mhz. Man kann in der Datei MyUtils.h die Funktion Delayms anpassen. dort muss man die Zahl 16000000 ändern.
Hmm läuft nich irgendwie. Is mir auch echt bischen zu spät jetzt. Wenn du magst, kannste mal meine 1wire.c und ds18s20.c haben.
Nur misst der bei mir irgendwie komisch. Entweder ist der DS1820 den ich benutze ziemlich genau, oder das Thermometer zum vergleichen. Da sind immer so 1 - 2 Grad unterschied. Aber das zum vergleichen ist son digital-sendedietemeratur-zur-haupteinheit-dingens-mit-display. Denke das ist nicht so das dollste. Und LANGSAM!!!!! ist das teil auch noch. Ach ja, ich betreibe den Sensor in meiner Schaltung im parasite-power mode. Daher könnte natürlich der CRC-Fehler kommen. grmf. bestimmt sogar. :-)
Hallo, ja wäre nett, wenn du mir die beiden Dateien mal geben würdest. Ich kann es aber leider erst wieder am Donnerstag ausprobieren... Ich bin mir zwar nicht ganz sicher, aber an dem parasite-power Modus solltes es nicht liegen, denke ich, da im Moment für die ganze Wartezeit zwischen den beiden Abfragen die Leitung im High zustand ist.
Ich habe damit in der Adventszeit auch gekämpft. Mit teilweise geklautem Code (Internet) und einem Speicheroszilloskop habe ich es dann hinbekommen. Es ist verdammt wichtig das Timing zu beachten ! Ein paar Mikrosekunden zu lange die Datenleitung auf Low und der Sensor macht nen Reset. Leider ist mein Programm für den Pic und nicht sehr verständlich, funktioniert aber gut. Habe es mal angehängt, evtl. hilft es ja doch. Ist eine reine Textdatei.
Hallo, ich hab noch ein wenig experimentiert. Ich kann Daten in die zwei Byte EEPROM, die auf dem Chip sind schreiben und danach auch wieder korrekt auslesen. Daher bin ich mir jetzt sehr sicher, dass meine Implementierung des 1Wire Protokolls funktioniert und ich dort das Timing richtig habe, da sonst entweder beim Schreiben oder beim Lesen dieser Daten ein Fehler auftreten müsste. Ich hab auch ausprobiert, nach dem Messen Befehl abzufragen, wie lange der DS18S20 Bussy ist. Er sender tatsächlich fast eine Sekunde 0 Read Slots, misst also. Wie oben erwähnt stimmt auch die Checksumme, die er zurückliefert. Der Inhalt des Scratchpds war nach dem Messen: AE 00 12 34 FF FF 0D 10 00 Er hat also die beiden Bytes, im EEPROM so ausgegeben, wie ich sie gesetzt hatte (12 und 34) und er hat die beiden Reservierten Bytes, wie im Datenblatt angegeben auf 0xFF gesetzt. Gibt es sonst noch irgendwas, das man bei diesem Chip beachten müsste? Hat noch irgendwer eine Erklärung dafür, dass immer nur Temperaturen von über 80 Grad zurückgeliefert werden, oder muss ich davon ausgehen, dass der IC beschädigt ist?
Hi Roland, bestellt Dir doch einfach noch mal nen DS18S20, von maxim-ic als sample oder z.b. bei segor. vergleiche die werte ... dann weist du zu 99,9% ob der Sensor def. ist oder dein code komisch ist. ;) Die frage ist auch, ob die werte die du bekommst reproduzierbar sind, also sprich immer der gleiche wert, oder geht er hoch bzw. runter wenn du was am temp fühler veränderst ? Gruß dennis
Hi, nein die Werte sind nicht immer gleich, sondern schwanken zwischen AA und B5 oder so. Aber ich kann keinen Zusammenhang zwischen den Werten und der Temperatur feststellen, da sie auch schwanken, wenn sich die Temperatur nicht ändert und auch nicht, wenn ich das Fenster aufmache sinken.
@Roland Ich werd mir morgen auch so ein Teil besorgen, sofern es der Conrad auf Lager hast. Falls du es nicht bis dahin hinbekommst, werd ich dir beim Fehlersuchen helfen. Obwohl es mir lieber wäre, wenn ich deinen funktionierenden Code einfach klauen könnte. :-)
Hallo Männers! Ich habe mal vor einiger Zeit ein Bascom PRG für ein Thermometer mit DS18B20 in die Codesammlung gestellt. Vielleicht nützt es ja. Jedenfalls unterscheiden sich der DS1820 und der DS18S20 grundsätzlich voneinander in der Form der Daten, die sie ausgeben. Das hat mich auch eine Weile weich gemacht! MfG Paul
@Fritz: Du kannst meinen Code gerne verwenden. Wenn es bei dir funktioniert sag mir doch Bitte bescheid. Also hier in Köln hatte der Conrad DS18S20 nicht vorrätig, sondern musste sie erst bestellen :-(. Aber eigentlich sollte er die wohl vorrätig haben.
Hallo, ich habe Rolands Code mal in ein Testprogramm eingebaut und zwei Stunden damit gekämpft... Ich glaube ich habe gewonnen. Ich habe einen mega32 mit 4MHz laufen, Taktrate in MyUtils.h angepasst, und ein Nokia 3310 LCD an Port B. Das wollte aber nichts anzeigen, den irgendwie wurde die Datenrichtung von PortB1 immer auf Eingang geschaltet, wenn vom DS1820 gelesen werden sollte !?! Lösung: in Thermo.h das macro #define TH_BR {/*THERMOPORT &= ~_BV(THERMOPIN);*/THERMODDR &= ~_BV(THERMOPIN);} so geändert. Hier wurde kurz vorm Umschalten auf Eingabe noch die Leitung auf 0 gesetzt. Kommt mir überflüssig vor. Und siehe da, jetzt läuft das Programm, die Temperatur stimmt und der Port bleibt auch auf Ausgabe. @Roland Hilft das bei Dir auch ??? Und kann mir einer erklären, warum der PortB so komische Dinge macht ?
@Uwe Ich hab es mit dem geänderten Macro versucht und es hat nichts gebracht. Ich gebe dir Recht, dass es überflüssig ist und eventuell auch Probleme verursacht die Leitung auf 0 zu stellen, bevor man den Port auf lesen umschaltet. Ist bei mir, glaube ich, ein Überbleibsel von meinen Debugversuchen gewesen. Bei mir hatte diese Zeile keine Auswirkungen, da ich einen externen Pull Up für den DS18S20 verwende, und deswegen der interne Pullup vom ATMega nicht benötigt wurde. Da mein Code mit diesen Änderungen bei Uwe funktioniert hat, muss ich wohl davon ausgehen, dass mein DS18S20 defekt ist, oder?
Hi Roland, ich kann Dir einen Code in ASM geben falls es Dir was nützt. Gruß Dennis
Werde es heute abend nochmal mit 16MHz versuchen, falls meine CPU das bei 3,3V mitmacht. (3,3 Volt wegen des Displays) Irgendwie werde ich den Verdacht nicht los, das da was mit dem Timing nicht stimmt. Allerdings gelingt ja die CRC-Prüfung, also empfängst du das, was der DS820 sendet...
Hallo!
So, ich hab gestern den Sensor gekauft, und heute endlich eingelötet.
Ging tadellos.
Tip zum Speichersparen:
Um die Temperatur auszugeben verwende ich:
sprintf(text,"%d.%s°C",p/2,(p&1)?"5":"0");
Das spart 400 Byte gegenüber sprintf(text,"%.1f°C",p/2.0);
p ist das Byte, welches von THERMO_GetTemp() zurückgegeben wird.
Eine Frage hab ich, muss man in THERMO_GetTemp() wirklich 2 Sekunden
nach dem THERMO_Init_Temp_Read() warten? Muss man
THERMO_Init_Temp_Read() immer machen, oder reicht es einmal in meinen
Hauptprogramm und dann mach ich den Rest?
hallo miteinander hab mir vor ca. einem monat auch eine assemblerroutine für den ds1820 geschrieben und funktioniert wunderbar. @fritz 2 sekunden sind soviel mir ist schon ein bisschen viel aber die maximale adc conversion time ist im datenblatt angegeben und hängt natürlich von der adc auflösung ab. liegt irgendwas bei 900 ms oder weniger bei der höchsten auflösung. weiss nicht mehr genau. schau einfach mal nach das findest du schnell! gruss fabian ps: würd mal meinen dass THERMO_Init_Temp_Read() immer ausgeführt werden muss um dem ds1820 überhaupt den befehl zu geben eine neue temepraturmessung zu starten!
@Fabian So, habs im Datenblatt gefunden. Ich habs so umgeschrieben, dass ich einfach nach 2 sekunden wieder reinschau und in der Routine weitermache. Ich kann nämlich nicht in einem delay warten, da ich immer im powersave sein muss um Batterie zu sparen. Lt. Oszi zieht der Sensor glücklicherweise nur ein paar Millisekunden lang Strom.
Schade. Dann ist wohl wirklich mein DS18S20 kaputt. Muss ich mir wohl einen neuen kaufen :-(. Die 2 Sekunden sind da nur drin, um sicherzugehen, dass der IC auch wirklich lange genug wartet (Debugcode). Du kannst auch in regelmäßigen Abständen mit ReadBit feststellen, ob die Temperatur gemesssen wurde. Noch mal vielen Dank an alle, die mir geholfen haben und es bei sich ausprobiert haben.
War tatsächlich der DS18S20. Hab einen neuen gekauft und jetzt läuft alles ohne Probleme. Noch mal vielen Dank, an alle die geantwortet haben.
Hallo Fritz, bei RS-Components 378-3607 4.88Euro netto. (sau teuer, wie ich finde) also, da hab ich meine her. habe gerade nachgesehn, nicht lieferbar, war ja klar! Gruß Axel
Hallo, hat jemand von Euch schon mal bemerkt, daß die Temperatur im Durchschnitt 2 Grad zu hoch engezeigt wird? Ist mir bei meinen ersten Versuchen aufgefallen.
Nö. Wie hast denn nachgemessen? Der Tisch wo mein Teil liegt ist durch die Abluft vom Rechner darunter einiges wärmer als die Zimmertemperatur. Ein Digitalthermometer daneben hat die selbe Temperatur angezeigt.
Hallo Fritz, ich habe den DS18S20 auf dem Board neben 2cm neben dem AT90S8535. Temperatur mit 2 Thermometern daneben gemessen ist 21 Grad. Wenn ich dann das Netzteil anschalte zeigt er mir genau 21 °C an. Innerhalb der nächsten 15 min. steigt die Temperatur langsam auf 24 °C an. Mein At an der unteren Seite (Pin 20 21) wird nicht wärmer. Und in 2 cm Abstand dürfte der DS1820 dann auch nicht um 3 °C wärmer werden. Da bleibt als einzige Alternative noch eine Eigenerwärmung des 1820 übrig. Das vermute ich zumindest.
sieht so aus. allerdings messe ich nur alle 8 sekunden und schick den Sensor zwischendrin in powerdown. Er braucht glaub ich 1mA, das wären 5mW, da müsste der Wärmewiderstand zur Umgebung ja 600K/W sein, das TO92 hat aber normal nur ca. 150K/W. Aber probier mal nicht so oft messen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.