DS18B20 setzt aus und zeigt faslche Werte

  • Heyho,

    Ich verwenden nun seit einiger Zeit wasserdichte DS18B20 zur Messung der Wassertemperatur in der Thames in London. Das funktionierte auch einwandfrei zusammen mit einem Raspberry 2B+ über Monate. Vor ein paar Tagen allerdings ergaben sich falsche und fehlende Messwerte. Das textfile mit den ausgegebenen Daten und Zeitstempeln sieht z.B. so aus:

    Die 5.678 Grad Celsius sind in etwa korrekt. Was natürlich nicht stimmt sind die -1 Grad Celsius und die komplett fehlenden Bereiche.

    Der Sensor ist an ein Verlängerungskabel gelötet (absolut Wasserdicht und die Stelle ist ohnehin nicht unter Wasser). das Verlängerungskabel ist etwa 10m lang, shielded und hat 3 Adern. Mit Strom wird der Sensor über 3v3 (pin1) versorgt. Daten sind mit GPIO4 (pin7) und ground ist mit pin9 verbunden. Zwischen power und data hängt noch der 4k7 Widerstand.

    Wenn gar keine Daten in die Datei geschrieben werden, wird der gesamte Sensor in /sys/bus/w1/devices nicht angezeigt. Ein sehr ähnliches Problem gab es vor einigen Monaten schon einmal mit dem ersten Sensor. Auch fehlenden Bereiche und falsche Temperaturen. Damals allerdings hauptsächlich der Default-Wert von 85 Grad Celsius. Ich tauschte damals einfach den Sensor durch einen neuen und alles leif wieder wie gehabt.

    Die Frage ist nun, kann es sein das über die Zeit das verhältnismäßig lange Kabel und der 4k7 Ohm Widerstand einen zu hohen Widerstand entwickeln und dementsprechend der Sensor gar nicht mehr erkannt wird, bzw die Daten fehlerhaft/unvollständig ankommen?
    Oder hat der Sensor einfach eine zu geringe Lebensdauer (übrigens der hier [Anzeige]) und ich muss damit leben ihn alle paar Monate zu erneuern?

    Der Vollständigkeit halber hier noch die Skripte zum auslesen und schreiben der Temperatur:

  • Zum Sensor kann ich nichts sagen, meiner ist noch nicht alt genug.

    Aber ich wuerde es meinem Pi ersparen, das C-Programm jede Minute neu zu compilieren:

    gcc -O3 -fPIC -g -Wall -Werror /home/pi/Watertemp/temp.c -o temp

    Ein einmal compiliertes Programm kann man problemlos wieder starten, besonders wenn man ihm einen schlauen Namen gibt...

  • Servus,
    ich geh' sogar noch einen Schritt weiter ... wozu das C-Programm, wenn Du die Werte doch auch direkt in Deinem bash script verfügbar hast?

    btw: -1 und 80 sind, wenn ich mich recht entsinne, Fehler-Indikatoren. In solch einem Fall solltest Du das Ergebnis verwerfen und eine neue Messung durchführen. Zumindest wäre das die allgemein übliche Vorgehensweise ...


    cu,
    -ds-

  • Okay, ja das C-Programm kann ich weglassen und nur das bash script nutzen. Allerdings erklärt das meiner Erachtens noch nicht das Problem. Eine weitere Messung durchführen, sollte das Ergebnis -1 oder 85 sein ergibt Sinn und wird eingefügt. Nur wie kommen diese Fehler und der komplett fehlende Sensor plötzlich zustande? Ich würde lieber versuchen bei der Ursache anzusetzen und weniger die Symptome behandeln. :)

    Einmal editiert, zuletzt von BallerNacken (6. Januar 2017 um 16:20)

  • Diese Fehler sind imho relativ "normal" und treten meiner Erfahrung nach immer wieder mal auf.
    Ich habe z.B. den 80° Fehler bei vielen Sensoren am Bus beim Einschalten und anschliessend erstem Auslesen. Danach tritt monatelang kein Fehler mehr auf (Bus mit ca. 20 Sensoren).
    Du kannst mal ein wenig mit dem Pullup herumspielen ( ein Poti wäre das Gold wert) ... bei längeren Verbinundungen kann der statt 4k7 auch gerne mal 2k2 haben.

    cu,
    -ds-

  • Einen Poti habe ich noch rumliegen. Das werde ich mal testen, sobald ich an den Pi und den Sensor rankomme. Könnte das Kabel auch noch um etwa 2.5 Meter verkürzen. Hatte ein wenig reserve drin gelassen, falls es mal verlängert werden muss.

    Nur frage ich mich, warum es monatelang funktioniert und auf einmal der Sensor Probleme bekommt. Mit der Temperatur kann es ja eigentlich nichts zu tun haben, da diese ja eher gefallen ist und dementsprechend auch der Widerstand des Kabels gefallen sein sollte...

    Ich werde mit dem Poti mal ein wenig rumspielen und mich wieder melden. Das bash script werde ich auch gleich noch umschreiben und das C-Programm ausmustern.

  • Es hat sich herausgestellt, dass mein Poti den ich noch hatte, nicht wirklich funktionsfähig ist. Ich habe es dementsprechend einfach mal mit einem 2k2 anstatt des 4k7 probiert. Zudem habe ich soviel vom Kabel weggenommen, wie es möglich war. Deises ist jetzt noch etwa 5m lang.
    Das Setup habe ich so mal über das Wochenende laufen lassen, allerdings haben ich schon nach ein paar Stunden die ersten Lücken in der Ausgabedatei ergeben. Als nächstes werde ich dann nochmal die Lotstellen zwischen Verlängerung und Sensorkabel überprüfen/ersetzen. Da diese aber eigentlich einwandfrei sein sollten, bin ich momentan überfragt, ob es noch andere Ursachen außer eines "defekten" Sensors geben könnte?

  • Es können nor Störungen sein, welche auf den Sensor einwirken, also ein Handy daneben, Funken, Schwankungen in der Stromversorgung (des Pi). Dann kann der ADC keinen vernünftigen Messwert ermitteln, oder die Datenübertragung hat Bit-Fehler. Sonst vielleicht noch: Sensor kaputt oder nicht mehr vorhanden (Hat ein Fisch gefressen), oder Wasser ist eingedrungen und löst nun den Chip auf (Magensäure vom Fisch?).


  • Es können nor Störungen sein, welche auf den Sensor einwirken, also ein Handy daneben, Funken, Schwankungen in der Stromversorgung (des Pi). Dann kann der ADC keinen vernünftigen Messwert ermitteln, oder die Datenübertragung hat Bit-Fehler. Sonst vielleicht noch: Sensor kaputt oder nicht mehr vorhanden (Hat ein Fisch gefressen), oder Wasser ist eingedrungen und löst nun den Chip auf (Magensäure vom Fisch?).

    Der Sensor ist momentan nichtmal im Wasser. Liegt trocken auf meinem Schreibtisch. Das einzige was in der Nähe des Sensors ist und Funkt, ist momentan ein Wlan router. Aber der war da schon immer und hat bei vorherigen Tests nie Probleme bereitet. Die Stromversorgung vom Pi hatte ich schonmal getestet. Waren konstant 3.3V über mehrere Stunden. Allerdings ist der Sensor in der Zeit auch nicht ausgesetzt. Muss mal sehen, ob ich das irgendwie reproduzieren kann.

  • Was spricht denn dagegen, die Messung zu wiederholen, wenn der Sensor einen Fehler bei der Umsetzung meldet?
    Ich mache das immer so: Messen - Messung auf Plausibilität bzw. auf fehlerhafte Rückgaber prüfen - ggf. Messung wiederholen - Messwert verwenden.

    Die DS18... setzen auch bei mir ab und zu mal kurz aus... (ich verwende die blanken ICs, die dann in Silikon bzw Schrumpfschlauch eingebettet sind).


  • Was spricht denn dagegen, die Messung zu wiederholen, wenn der Sensor einen Fehler bei der Umsetzung meldet?
    Ich mache das immer so: Messen - Messung auf Plausibilität bzw. auf fehlerhafte Rückgaber prüfen - ggf. Messung wiederholen - Messwert verwenden.

    Die DS18... setzen auch bei mir ab und zu mal kurz aus... (ich verwende die blanken ICs, die dann in Silikon bzw Schrumpfschlauch eingebettet sind).

    Der Sensor meldet gar nichts. Er wird vom Pi schlicht nicht gesehen. Und das teilweise für mehr als 20 Minuten, bevor er dann wieder ganz normal funktioniert, bis er wieder ausfällt. Das deutet eben auf ein Problem in der Stromversorgung hin oder auf einen defekten Sensor. Nur wenn der Sensor defekt wäre, würde er dann noch in 80% des Tages ordentliche Messwerte liefern?
    Also wohl am ehesten die Stromversorgung. Nur konnte ich bis dato absolut keine Probleme mit eben dieser feststellen.

    Natürlich kann ich die Messung wiederholen, mache ich ja auch so, wenn der Messwert 0, -1 oder 85 ist. Aber bei langen Ausfällen bei denen ich nicht weiß wann der Sensor wieder ansprechbar ist, macht das meines Erachtens wenig Sinn.

  • Ok, den Fall hatte ich auch schon (Sensor komplett weg), hatte damals (vor ca. 10 Monaten) hier im Forum nachgefragt, aber keinen hat es damals interessiert...

    Bei mir half nur entweder den Sensor kurz abzuschalten (Vcc weg) oder den RP rebooten.

    Nach einigem Hin- und her hab ich dann ein anderes Netzteil (eins mit 5,1V und stabilerer Spannung) verwendet und damit ging es plötzlich ohne Aussetzter.
    Es könnte tatsächlich ein Stromversorgungsproblem (wie so oft) sein.

  • Hallo BallerNacken,

    ich habe mal einen Satz von DS18B20 eingesetzt und dies folgendermaßen gemacht.
    - Vor jedem Mess-Zyklus werden die IDs der Sensoren ausgelesen, die sich aus den Verzeichnisnamen ergeben, und in eine Liste gespeichert. Jeder ID ist ein physikalischer Ort zuordenbar.
    - Nur die Sensoren werden ausgelesen, die im System "angemeldet" sind.
    - Messungen werden wiederholt, wenn der Messwert nicht hinreichend plausibel ist.

    Auf diese Weise ist es vollkommen schnurz, wenn mal ein Sensor längere Zeit "nicht da ist". Obwohl ich ehrlich sagen muss, dass mir das bislang auch noch nicht passiert ist. Die Liste der Sensoren ist immer unverändert.

    Als ich mich damals mit diesen Sensoren beschäftigt habe, ist mir aufgefallen, dass ein spontanes Verschwinden eines Sensors sowohl Ursache der Spannungsversorgung als auch eines nicht optimalen Widerstandes zwischen VCC und DQ sein kann.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • Hallo BallerNacken,

    ich habe mal einen Satz von DS18B20 eingesetzt und dies folgendermaßen gemacht.
    - Vor jedem Mess-Zyklus werden die IDs der Sensoren ausgelesen, die sich aus den Verzeichnisnamen ergeben, und in eine Liste gespeichert. Jeder ID ist ein physikalischer Ort zuordenbar.
    - Nur die Sensoren werden ausgelesen, die im System "angemeldet" sind.
    - Messungen werden wiederholt, wenn der Messwert nicht hinreichend plausibel ist.

    Beste Grüße

    Andreas

    Soll heißen: War ein Sensor mal nicht "angemeldet", wurde dieser nach dem ID Abgleich einfach übersprungen? das würde dann ja auch wieder in fehlenden Daten enden. Ich werde mich gleich auf jeden Fall nocheinmal ran setzen und mit der Stromversorgung ein wenig testen.

    Einmal editiert, zuletzt von BallerNacken (16. Januar 2017 um 15:07)

  • Hallo BallerNacken,


    Soll heißen: War ein Sensor mal nicht "angemeldet", wurde dieser nach dem ID Abgleich einfach übersprungen? das würde dann ja auch wieder in fehlenden Daten enden. Ich werde mich gleich auf jeden Fall nocheinmal ran setzen und mit der Stromversorgung ein wenig testen.


    Fast: Der Sensor wird nicht übersprungen, weil er für diesen Lauf gar nicht existiert. Was nicht existiert, braucht auch nicht ausgelesen zu werden. Eine Datei in einem nichtvorhandene Verzeichnis lesen zu wollen, gibt immer unschöne Fehler. Aber nur die Dateien auszulesen, die auch wirklich gerade in den bekannten Verzeichnissen stehen, läuft stabil.
    Und wenn beim nächsten Durchlauf andere Kombinationen von Sensoren abgefragt werden, wen stört's?

    Das Ganze ist kein Problem der Sensor-Abfrage und der Programmierung - es war und bleibt ein Problem der Spannungsversorgung und des Widerstandes. Ich kann mir auch vorstellen, dass es von individuellen DS18B20-Sensoren abhängt. N Sensoren funktionieren unter sich störungsfrei. Sensor N+1 verursacht Probleme mit jeder Kombination der N Sensoren. Den Störenfried gilt es zu finden und aus dem Spiel zu nehmen.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Nach einigen Tagen Testerei habe ich das grundsätzliche Problem zwar immer noch nicht gefunden, die Ausfälle sind aber deutlich reduziert. Das mag auf diesem kurzen Testzeitraum aber auch einfach nur Zufall sein.

    Was habe ich gemacht:

    1) Den Pi nochmal komplett geupdated (update+upgrade)
    2) sämtliche Verbindungen neu verlötet und keine jumper wire mehr verwendet, sondern direkt auf die GPIO pins gelötet. Die jumper stecker die ich verwendet habe, fielen oft von alleine ab
    3) Stärkere Stromversorgung verwendet (5.1V; 2.5A)

    Mit diesem Setup hatte ich gestern (in 24h) Ausfälle von etwa 15 minuten aufgeteilt auf 3-4 minütige Phasen in denen der Sensor nicht erkannt wurde. Das ist weniger als 1% und liegt im Rahmen, aber dennoch würde ich die Ursache gerne finden. Ich denke ich werde auf jeden Fall nochmal einen Sensor bestellen und diesen im exakt gleichen Setup testen.

    Was ich außerdem noch implementieren werde ist eine Art "gap fill". Wenn die Lücke kleiner als 5 Minuten ist, soll diese mit den davor und dahinter liegenden Werten gefüllt werden. Da Wasser einen sehr langsamen Temperaturgang hat, sollte das auf diese Dauer völlig okay sein.


  • Wie groß ist der PullUp-Widerstand und hast du damit mal etwas "gespielt"?

    Üblicherweise macht man den so um die 4,7-10k groß... bei langen Leitungen hilft es oft, den zu reduzieren (aber ca. >1k)...

    Es war ein 4k7 als die Probleme auftraten. Inzwischen verwende ich einen 2k2, welcher aber quasi die gleichen Ergebnisse liefert. Ich sollte morgen ein paar neue Teile, mit unter Anderem einen neuen Poti, bekommen. Dann werde ich nochmal andere "Widerstaende" testen.

    Einmal editiert, zuletzt von BallerNacken (19. Januar 2017 um 18:15)

  • Es lag defintiv am Sensor. Wie schon zuvor hat es diesen nach etwa 5 Monaten dahin gerafft. Ich ging eigentlich davon aus das diese Sensoren etwas laenger durchhalten. Aber was will man von Wasserdichten Sensoren fuer ein paar Euro auch erwarten. Habe die Kabellaenge jetzt aber auf jeden Fall auf das mindest moegliche verkuerzt und den Aufbau modular gemacht. Nun muss ich bei einem fehlerhaften Sensor einfach nur noch diesen am Stecker austauschen und nichtmehr das ganze Geraffel neu verloeten usw.

    Gibt es aber unter Umstaenden eine Moeglichkeit die Lebensdauer des Sensors zu erhoehen? Spontan wuerde mir nur einfallen ihn nicht ununterbrochen mit Strom zu versorgen, sondern nur fuer die eigentliche Messung den 3v3 pin frei schalten und nach der Messung die Last wieder abnehmen? Nur kann ich im Datenblatt nichts bezueglich einer Vorlaufzeit fuer den Sensor finden? Ich gehe einfach mal davon aus das diese benoetigt wird.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!