Messwert 85°C pauschal als Fehler interpretiert?

[makki]

Ohne jetzt alles gelesen zu haben:
85.0000°C werden ausgefiltert, das geht leider nicht anders (ist etwas dämlich, aber nunmal so; das ist die einzige "Fehlermeldung" des Sensors)

Meine Empfehlung: die Auflösung bei solchen Sensoren, die in den Bereich von 85° kommen können auf 12 Bit stellen, dann wird es sehr, sehr unwahrscheinlich, das exakt 85.0000 dabei rauskommt. (und nur das wird gefiltert!)

Makki

[wuestenfuchs]

In den Grafiken erscheint nichts, weil nichts gesendet wird - genauso als wenn der Sensor nicht angeschlossen wäre.

Perfetto! Ich nehme an, auch Plugins bekommen keinen Wert, analog zu den Grafiken, richtig?

[StefanW]

In der heutigen Vorführung des Softwareteams zum nächsten PL wurde auch das "85 °C -Problem" gezeigt:

Es erscheint nun "Sensor present / Error" anstatt der 85 °C d.h. der Sensor wird als vorhanden angezeigt, aber eben dass er einen Fehler hat. Per Tooltip sind dann noch weitergehende Hinweise geplant. In den Grafiken erscheint nichts, weil nichts gesendet wird - genauso als wenn der Sensor nicht angeschlossen wäre. Die Detektion erfolgt natürlich auf sicheren Wege, normale Sensoren die wirkliche 85 ° C messen, werden natürlich angezeigt.

lg

Stefan

[wuestenfuchs]

Okay, das deckt sich mit meinen Erfahrungen. Ich hatte mit den "alten" Busmastern bisher beobachtet, dass bei einer Überforderung des Busses viele Sensoren auf 85 °C umspringen. Bei Reduktion der Anzahl der Sensoren sowie der Leitungslängen funktionierten diese wieder normal. Da wir hier allerdings von einer Hand voll Sensoren (<10 Stück DS1820) und nicht allzu großen Leitungslängen (teilweise deutlich <100 m) - dafür aber größtenteils in Sternverdrahtung - sprechen, wollte ich weitere Fehlerquellen ausschließen.

Wegen der Sternverdrahtung bin ich derzeit im Test mit dem neuen Busmaster und - ich glaube, soviel darf ich verraten - die bisherigen Erkenntnisse sind ermutigend :-)

[swiss]

Theoretisch beides bzw. eine Kombination daraus...

Es ist anzunehmen dass bei zu fielen Sensoren am BUS die jenigen die am weitesten entfernt liegen am ehsten Probleme haben werden. Auch wenn die Leitungslänge nicht voll ausgeschöpft ist. Hier können dann noch weitere Faktoren dazu führen dass es ab und zu funktioniert und dann wieder nicht. Ein Faktor ist z.B. die Umgebungstemperatur des Sensors.

Hast du denn ein konkretes Beispiel?

[wuestenfuchs]

Und was genau kann Unterspannung auslösen? Zu lange Leitungslängen? Zu viele Sensoren?

[swiss]

Grundsäzlich kann ein POR auch durch Unterspannung ausgelöst werden. Nämlich genau dann wenn die meiste Energie (zum Messen) benötigt wird und die Spannung so weit abfällt dass die Elektronik nicht mehr arbeiten kann. Ist der Punkt erreicht, wird die Messung "abgewürgt" und der Sensor startet mit Defaultwerten neu. Also Spannungsfall ist sicherlich auch ein möglicher Grund für POR.

[wuestenfuchs]

Hallo Stefan,

danke, das ist wirklich sehr gut beschrieben.

Eine Frage: Kann dieser Fehler auch auftreten, wenn der Bus an seine Grenzen kommt, z.B. durch ein zu langes Buskabel oder durch zu viele Busteilnehmer? Oder ist das ausschließlich auf einen Verdrahtungsfehler am entsprechenden Sensor, so wie von dir beschrieben, zurück zu führen?

[StefanW]

Hmm, das scheint ein schwieriges Thema zu sein. Weil es von jedem neu und falsch aufgefasst wird, hab ich das so falsch erklärt?

Ok, hier der ultimative Erklärungsversuch zu dem Thema "Power-On-Reset" und "Parasitär" der DS18B20 Sensoren:

1. Zwei Betriebsmodi: Die Sensoren DS18B20 (und teils auch deren Derivate, bitte jeweiliges Datenblatt lesen) verfügen über zwei Betriebsmodi: "Powered" und "Parasitär".
2. Modi "Powered": Hier erfolgt die Spannungsversorgung über den separaten 5 V Anschluss.
3. Modi "Parasitär": Die Spannungsversorgung soll aus dem Datensignal erfolgen. Das macht mehrere weitere Schritte notwendig. Zunächst muss der Sensor in diesen Modus geschaltet werden. Das erfolgt dadurch, dass der Anschluss VDD (also der 5 V Anschluss) mit dem Anschluss GND verbunden wird (also eine Kurzschlussbrücke zwischen dem Anschluss VDD und dem Anschluss GND des Senbsors.).
   Hinweis: Diese Brücke soll nur sensorseitig angewendet werden und nicht die Anschlüsse des Busmasters miteinbeziehen (ihr werdet es nicht glauben, aber ein Viertel der Kunden hat schon den Busmaster zwischen 5 V und GND kurzgeschlossen).
4. Auslesen des Modi durch Software: Der Sensor teilt in einem seiner Register mit, ob er "Powered" ist, oder nicht (was dann "Parasitär") bedeutet.
5. Ansteuerung durch die Software: Insofern sich ein Sensor als "parasitär" (genau genommen, als "nicht-powered") meldet, muss die Software dies berücksichtigen und den Sensor nach dem Befehl "Convert-T" (das bedeutet: "Miss die Temperatur und wandle diese in ein digitales Format") dadurch mit Spannung versorgen, indem der Busmaster von der Software so gesteuert wird, dass das Datensignal während der Dauer der Konvertierung auf dauerhaft 5 V gehalten wird, d.h. es findet während dieser Zeit keine Datenübertragung statt. Hinweis: Es gibt Software, die diesen Modus "Parasitär" nicht unterstützt, z.B. IPS.
6. Fortsetzung der Datenübertragung: Erst nach erfolgter Wandelung, die je nach gewünschter Auflösung (9 bis 12 Bit) zwischen 63 ms und 750 ms dauert, kann wieder eine Datenübertragung - egal wohin erfolgen. Jede andere Kommunikation muss in dieser Zeit warten.
7. "Power-On-Reset" bei fehlerhafter Konfiguration des Sensors: Wird nun die unter 3. erklärte Brücke zur Konfiguration des Sensors nicht gesetzt (also z.B. offen gelassen) bzw. VDD nicht angeschlossen (was das gleiche bedeutet), dann wähnt sich der Sensor im Modus "Powered". Da die Software den Sensor dann auch "powered" ansteuert, unterbleibt das hochhalten des Datensignals (es gibt noch andere Tricks wie Strong Pullup, dies ist hier zur Vereinfachung nicht beschrieben). Das Ergebnis ist, dass dem Sensor schlicht die Betriebsspannung ausgeht, weil zum einen dessen lokaler Kondensator nur einige Dutzend Millisekunden überbrücken kann und zum anderen die AD-Wandlung deutlich stromintensiver ist. Deshalb "rebootet" der Sensor mangels Strom.
8. Kennzeichen des "Power-On-Reset": Nach dem Power-On-Reset ("POR") stehen die Register in einer Grundstellung. Zum einen ist der Sensor auf maximale Auflösung mit 12 Bit konfiguriert, zum anderen steht im Temeratur-Conversion-Register dann ein Bitmuster, dass dem Wert 85,0000 °C entspricht. Der Sensor hat somit nichts gemessen, weil ihm die Spannungsversorgung ausgegangen ist und nur Default-Werte in den Registern stehen. Es ist Aufgabe der Software, damit richtig umzugehen.

Welche Produkte betrifft dies?: Alle diejenigen, bei welchen der Sensor ohne weitere begleitende Elektronik eingebaut ist, also Hülsen-Fühler, Anlegefühler und der alte Multisensor V 1.3.

Welche Produkte betrifft das nicht?: Alle etwas komplexeren Produkte wie Multisensoren, Temperatursensor auf Platine, Umgebungslicht-Multisensoren usw. bei der B- und Z-Serie sowie bei allen künftigen Serien. Bei diesen neuen Produkten wird - auch bei parasitärem Anschluss der Platine - der Sensor powered betrieben (durch eine entsprechende Schaltung). Es braucht auch keine Brücke. Wir nennen das "Parasitär Typ 2". Damit entfällt diese Fehlerart und eine spezielle Ansteuerung durch die Software ist nicht mehr nötig, so dass auch Kunden mit IPS diese neuen Sensoren mit parasitärem Anschluss nutzen können.


Zusammenfassung:

• Die Anzeige 85.0000 °C in Verbindung mit einer Auflösung von 12 Bit ist mit an Sicherheit grenzender Wahrscheinlichkeit der Default-Wert nach einem Neustart - entstehend durch den Power-On-Reset. Ganz insbesondere dann, wenn der Kunde keine 12 Bit eingestellt hat (weil 9 Bit oder maximal 10 Bit i.d.R. für die meisten Zwecke ausreichend sind). Wenn diese drei Bedingungen geprüft werden, kann der Fall "POR" sicher detektiert werden.
• Ein POR ensteht zum einen bei der Inbetriebnahme bzw. jeweiligen Spannungsanschaltung des Busses oder eben als Folge eines "Absturzes" durch mangelnde Stromversorgung - fast immer bedingt durch Verkabelungsfehler. Entweder die VDD ist nicht angeschlossen oder die sensorseitige Kurzschlussbrücke zu GND fehlt.
• Dieses Verhalten ist das des Sensors und hängt nicht vom Busmaster ab bzw. kann nicht vom Busmaster gebessert werden. Allerdings muss die Software den Busmaster bei einem parasitären Sensor korrekt ansteuern, dass während der Konversionszeit das Data-Signal auf High-Pegel bleibt.
• Bei Auftreten dieses Fehlers ist immer die Verkabelung des jeweiligen Sensors zu prüfen.
• Dieser Fehler betrifft nur die Hülsenfühler nebst Derivaten, den Deckentemperaturfühler sowie die Einschraub- und Kanaltemperaturfühler in der Version 1, sowie den Multisensor 1.3. Alle neueren Produkte haben eine lokale Automatikschaltung welches dieses Problem vermeidet und auch keine Brücken mehr erforderlich macht.

==> Wir können diesen Fall also gut erkennen und werden das in künftiger Software entsprechend berücksichtigen.

Alles klar?

lg

Stefan

[Hauke]

Nun ja, das Problem ist, dass die Sensoren ja nicht zwingend auf 12 Bit Auflösung geschaltet sind.
Wie von mir weiter oben bereits zitiert, sind in der Hilfe die Zeiten, die zur Abfrage benötigt werden, angegeben. Grundsätzlich reichen mir 0,5°C Auflösung aus, und wenn 12 Bit fast um Faktor 10 langsamer sind (bei einer Handvoll Sensoren sprechen wir hier immerhin über 5-10 Sekunden allein für die Abfrage der Temperaturen, während der - wenn ich das richtig verstehe - auch keine Plugins ausgeführt werden können) fahre ich lieber nur mit der minimal benötigten Auflösung. Und da kommen exakt 85°C nun mal leider durchaus vor.
Ich würde daher eine Lösung favorisieren - sofern technisch umsetzbar - die exakt 85°C mit 9, 10 oder 11 Bit nicht wegfiltert. Auf die 85,000 mit 12 Bit Auflösung kann ich verzichten. Die Sensoren sind halt recht exakt und "pendeln" nicht unbedingt stark rauf und runter. Mit 9 Bit bekomme ich teilweise über Stunden hinweg exakt 85°C.

BTW: Verhält sich der neue Professional Busmaster in diesem Punkt genauso?

[StefanW]

Sehr richtig.

Die Auflösung wird bei Power-On-Reset auf 12 Bit geschaltet, die 85 °C entsprechen damit den 85,0000 °C und das darf man getrost ausblenden.

Wenn man ganz vorsichtig sein will, könnte man dann auch noch eine zweite Messung vornehmen. Zudem könnte man mit der Historie vergleichen, ob es eine allmähliche Annäherung an die 85 °C gab oder einen Sprung.

lg

Stefan

[wuestenfuchs]

Wenn ein Sensor in einer Umgebung von 85°C verbaut ist, würde ich nach wie vor die Temperatur auch gerne messen können.

In der Praxis dürfte das keine wesentliche Rolle spielen, denn es geht - je nach Auflösung, um exakt 85 °C (also 85,0 bis IIRC 85,0000 °C). 85,005 und 79,995 Grad werden beispielsweise wieder korrekt angezeigt.

Selbst wenn du wirklich eine Umgebung mit exakt 85 Grad hättest, würde der Sensor aufgrund von Messungenauigkeiten ständig um diesen Bereich herum pendeln - im Fall des DS1820 im Bereich zwischen 79,5 und 80,5 Grad (+- 0,5 Grad Messtoleranz). Tatsächlich gemessene 85,000 Grad wirst du also nicht haben, bei entsprechender Auflösung zumindest nicht über eine relevante Dauer hinweg.

[Hauke]

Ich hatte ursprünglich ein Plugin angedacht, das gewissermaßen als "Temperatur-Brandmeldeanlage" fungiert, d.h. alle Werte über 65 °C lösen gewisse Alarmhandlungen aus.

Dann mach' doch einfach ">85°C", die erreichst du definitiv auch wenn es brennt... Ich behaupte mal die Zeit zwischen >65 und >85 dürfte im Falle eines Feuers nicht wirklich lang sein...

Könnte man nicht in allen Fällen einfach den Wert von 85 °C ausblenden?

Wenn ein Sensor in einer Umgebung von 85°C verbaut ist, würde ich nach wie vor die Temperatur auch gerne messen können.

[StefanW]

Werden die "85 °C" eigentlich nur im Wiregate-Webinterface ausgegeben oder auch an Plugins, auf den Bus, ... weitergegeben?

Muss ich klären. Meiner Errinerung nach, wird es in den RRDs usw. ausgeblendet. Hinsichtlich der Plugins usw. muss ich mich erkundigen, gehört meiner Meinung nach ebenfalls ausgeblendet.

Auch in der Sensoren Anzeige gehört eine Fehlermeldung und kein 85 °C Wert, ist viel zu erklärungsbedürftig.


lg

Stefan

[wuestenfuchs]

Werden die "85 °C" eigentlich nur im Wiregate-Webinterface ausgegeben oder auch an Plugins, auf den Bus, ... weitergegeben?

Ich hatte ursprünglich ein Plugin angedacht, das gewissermaßen als "Temperatur-Brandmeldeanlage" fungiert, d.h. alle Werte über 65 °C lösen gewisse Alarmhandlungen aus. Nachdem in jedem Raum ohnehin mindestens ein 1-Wire Temperatursensor vorhanden ist, wäre das doch nur konsequent weitergedacht. Allerdings würden die Sache mit den 85 °C - je nach Busstabilität - durchaus mal Falschalarme generieren.

Könnte man nicht in allen Fällen einfach den Wert von 85 °C ausblenden? Oder zumindest im Webinterface mit einer Fehlermeldung ersetzen? Denn ein falscher Wert ist manchmal schlimmer als gar kein Wert - siehe obiges Beispiel.