Für meine, nennen wir es mal "Jagdhütte", habe ich ein System gebaut, das u.a. die Raumtemperatur mit einem DS18B20 überwacht und bei Frostnähe einen Alarm absetzt. Soweit so gut, seit 18 Monaten funktioniert das auch. Nur jetzt wurden plötzlich 2 Grad gemessen, obwohl selbst die minimale Außentemperatur dort über 5 Grad lag. Heute habe ich das vor Ort überprüft. Erwärmte ich den Sensor durch Anhauchen/Körperkontakt, wurden vermutlich richtig über 25 Grad gemessen. Als ich den Sensor dann wieder lose in der Luft hängen ließ, sank die gemessene-Temperatur wieder auf 2 Grad. Ein parallel laufendes Thermometer zeigte (richtig) 14 Grad an. Den Sensor habe ich nun mit nach Hause genommen, und hier zeigt er genau wie sein parallel arbeitender Zwilling die korrekte Temperatur an. Hat einer von Euch eine Erklärung für dieses Phänomen? Aufgrund der CRC-Sicherung fällt eine fehlerhafte Datenübertragung "eigentlich" weg. VG Yogy
Hanns-Jürgen M. schrieb: > Ein parallel laufendes > Thermometer zeigte (richtig) 14 Grad an. wer sagt denn, dass das Thermometer richtig ist? Im Zweifel würde ich eher dem DS18B20 trauen, als irgendeinem Thermometer, wo man nicht weiß, welcher Sensor dort verwendet wird.
Der Hund liegt vielleicht in deinem Programm begraben. Wie ist der DSB18B20 angeschlossen und wie sieht das Programm aus?
Hoi schrieb: > Es kann aber auch sein das er einen gefakten 18b20 hat (siehe ftdi) FTDI stellt den 18B20 her?
denn häng doch in deiner "Jagdhütte" noch 2x DS18B20 dazu und lasse die 3 abstimmen. Ich traue den DS auch mehr als dem Thermometer aber 1 DS kann auch mal irren und ich messe bei CRC oder anderen Fehlern noch 2x nach. Man könnte auch 3 Messungen pro DS machen und bei geringen Abweichungen der 3 Messungen je DS den Mittelwert bilden und die 3 DS dann abstimmen lassen. Erst mal kostet ein DS nicht die Welt und der Aufwand 3 hintereinander zu hängen ist auch nicht riesig, das bischen SW wie oben beschrieben bekommt man auch noch vor der Mailverschickung hin solange nicht jedes Byte im Flash oder auf der SD aufgebraucht ist.
Achim schrieb: > FTDI stellt den 18B20 her? Nein, die stellen glanzverzinket Wurstsemmeln her. SCNR @TO Es kann sein, daß über die Anschlüsse Feuchtigkeit in den Sensor eingedrungen ist. Dann mißt er auch nur noch Müll.
Wer sicher gehen will, der verwendet mehrere Sensoren verschiedenen Typs.
Bestes Mann wo gibt schrieb: > Achim schrieb: >> FTDI stellt den 18B20 her? > > Nein, die stellen glanzverzinket Wurstsemmeln her. Bist du tatsächlich so doof, dass du meine Frage nicht verstanden hast?
Hanns-Jürgen M. schrieb: > obwohl selbst die minimale Außentemperatur > dort über 5 Grad lag. Bist Du da wirklich sicher, as der 18B20 auch die Temperatur unter gleichen Bedingungen misst? Nachts zum Beispiel, bei klarem Himmel kann der schwarze 18B20 mehr Wärme abstrahlen als ein aus Glas bestehendes Thermometer und schon ist der 18B20 kälter als das Thermometer. Oder, der 18B20 steckt in einem Block, der nachts abgekühlt ist und morgens noch einige Zeit diese Temperatur hält. Also, untersuche mal, wie/wo der 18B20 und das Vergleichsthermometer platziert sind. Oder stecke beide, 18B20 und das Vergleichsthermometer in ein Wasser- oder Ölbad damit sichergestellt ist, dass sie die gleiche Temperatur annehmen.
Hanns-Jürgen M. schrieb: > Hat einer von Euch eine Erklärung für dieses Phänomen? Hast Du nähere Erklärungen? Handelt es sich um "Ausreißer" bei den Messungen, oder mißt der Sensor fortlaufend und gleichbleibend dieselbe zu niedrige Temperatur? Liest Dein Programm nur das Temperaturregister aus oder wird auch die CRC-Prüfsumme getestet? Wenn die Prüfsumme getestet wird: Ist diese regelmäßig OK oder gibt es viele Messungen mit falsch gelesener CRC-Prüfsumme? Ist das Verhalten der Schaltung nach einem Tausch des Temperatursensors immer noch fehlerhaft? Wenn ja, liegt es an der Hardware oder am Programm. Wenn nein, lag es an einem defekten Sensor.
Danke für die vielen Antworten. Bez SW: Dort liegt der Hund der reinen Messung nicht begraben. Aber ein gefundener Hund bei der Alarmgenerierung. Ist hier aber erstmal irrelevant. Aber ich habe es im "Auge". Zur Temp-Messung DS18B20 / Thermopmeter: Bei haben heute im Innenraum gemessen, als nix mit Strahlungswärme. Und die auf dem Körper gefühlten Temperaturen geben dem Thermometer mehr recht als dem DS. Überghaupt wird nur die Innenraumtemperatur gemessen. Feuchtigkeit wäre zwar grundsätzlich denkbar ist aber IMHO unwahrscheinlich Heute Nacht hängt der DS draußen vor dem Fenster meines Arbeitszimmers. Mal sehen. Ein SW-Fehler wäre zwar prinzipiell naheliegend, aber die Messroutine (Datenauslesen) ist "eigentlich" i.O. Sie arbeitet in einem Timer-Interrupt flaggesteuert (Arduino-Mega als Prozessoreinheit, SW in C). Fehlmessungen (CRC stimmt nicht) filtert das Hauptprogramm. Je nach Ausgang der Messungen heute abend und in den nächsten Tagen muß ich wohl das System zu mir nach Hause holen und den vermeintlichen Bug suchen. Ach ja, wegen mehrere parallel verwendeter Sensoren: Ja, das würde das Problem lösen (siehe "Minority Report" lach), aber wir sind nicht in der Luftfahrt mit Dreifach-Redundanz. Aber ich denke darüber nach, mehrfach hintereinander zu messen und die Ergebnisse miteinander auf Plausibilität zu vergleichen.
Jürgen S. schrieb: > Hanns-Jürgen M. schrieb: >> Hat einer von Euch eine Erklärung für dieses Phänomen? > > Hast Du nähere Erklärungen? > > Handelt es sich um "Ausreißer" bei den Messungen, oder mißt der Sensor > fortlaufend und gleichbleibend dieselbe zu niedrige Temperatur? Es ist kein Ausreißer, Messung erfogt alle paar Sekunden. > > Liest Dein Programm nur das Temperaturregister aus oder wird auch die > CRC-Prüfsumme getestet? CRC wird getestet > > Wenn die Prüfsumme getestet wird: Ist diese regelmäßig OK oder gibt es > viele Messungen mit falsch gelesener CRC-Prüfsumme? Das zähle ich nicht. Bei einer Falschmessung (CRC falsch) wird der letzte gültige Wert beibehalten. > > Ist das Verhalten der Schaltung nach einem Tausch des Temperatursensors > immer noch fehlerhaft? Wenn ja, liegt es an der Hardware oder am > Programm. Wenn nein, lag es an einem defekten Sensor. Ich hatte heute keinen Tauschsensor dabei. Daher war ein Vergleich vor Ort nicht möglich Und "mal eben holen" geht auch nicht bei fast 100 km Distanz. Aber beim näöchsten Besuch dort nehme ich mehrere vorbereitete Sensoren mit.
chris schrieb: > Im Zweifel würde ich eher dem DS18B20 trauen, als irgendeinem > Thermometer, wo man nicht weiß, welcher Sensor dort verwendet wird. Den Unterschied zwischen 2°C und 14°C hat man schnell raus, wenn man mal die Jacke auszieht.
Hanns-Jürgen M. schrieb: > Das zähle ich nicht. Bei einer Falschmessung (CRC falsch) wird der > letzte gültige Wert beibehalten. Dass eine 8-Bit CRC nicht jeden möglichen Datenfehler erkennt, ist Dir aber schon klar? Wenn der Sensor beispielsweise nur noch stochastischen Datenmüll liefert, ist bei einer 8-Bit CRC die Wahrscheinlichkeit bei 1:256 dass Datenmüll mit korrektem CRC-Wert erkannt wird. Dann brauchst Du nur oft genug messen, um eine "CRC gültige" Messung zu erhalten. > Und "mal eben holen" geht auch nicht bei fast 100 km Distanz. Schaltest Du bei Erreichen der Alarm-Temperatur irgendwas in der Hütte automatisch ein, z.B. eine Frostwächter-Heizung? Wenn keine Schaltfunktion notwendig ist, würde ich sonst darüber nachdenken, die Temperatur gar nicht selbst zu messen, sondern möglicherweise nur heuristisch aus Daten des Deutschen Wetterdienstes zu ermitteln. Der DWD stellt laufend für zig Wetterstationen in Deutschland Stundenwerte online, unter anderem mit der Temperatur. Wenn eine DWD-Station in der Nähe ist, brauchst Du für die Temperatur in Deiner Hütte quasi nur eine Tiefpassfilterung der letzten Stundenwerte machen, die Du vom DWD aus dem Internet ziehen kannst. Je besser die Isolierung der Hütte, desto langsamer muß das Tiefpassfilter reagieren. Denn im Endeffekt folgt die Temperaturkurve in einer ungeheizten Hütte immer mit zeitlicher Verzögerung den Außentemperaturen. Vom so durch Tiefpassfilterung ermittelten Temperaturwert ziehst Du dann für je 100 Höhenmeter, die Deine Hütte höher liegt als die nächste DWD-Station ca. 0,6°C ab oder schlägst 0,6°C pro 100 Höhenmeter drauf, wenn Deine Hütte tiefer liegt. Falls in vertretbarer Nähe keine DWD-Station in der Nähe liegt, kannst Du aus Werten mehrerer weiter entfernter DWD-Stationen eine Triangulation durchführen und ermittelst so anhand des Temperaturgradienten die Temperaturen dazwischen, wo Deine Hütte liegt. So funktionieren auch die Temperaturanzeigen moderner Smartphones mit Wetter-App: Die zeigen Dir aus verfügbaren Daten durch Triangulation ermittelte Temperaturen für jeden beliebigen geografischen Ort an - und liegen dabei oft recht nahe an der Realität.
Hoi schrieb: > Es kann aber auch sein das er einen gefakten 18b20 hat (siehe ftdi) Achim schrieb: > Bestes Mann wo gibt schrieb: >> Achim schrieb: >>> FTDI stellt den 18B20 her? >> >> Nein, die stellen glanzverzinket Wurstsemmeln her. > > Bist du tatsächlich so doof, dass du meine Frage nicht verstanden hast? Ich vermute mal das Achim keinen blassen Schimmer davon hat das die Chinesen FTDI-Chips faken (wie jetzt in einigen Medien bekannt wurde). Mit dem "siehe FTDI" war wohl gemeint das der DS18B20 wohl vom Chinesen eine billige Fälschung sein könnte. Ein ATTIny hat ja einen integrierten Tempsensor welcher mittels Software sich so auslesen lässt als wäre es ein DS18B(S)20. Nur das der Tiny total ungenau ist. Oder weshalb bekommt man beim Chinesen 18x20er mit Platine günstiger als der Hersteller die DS einzelln verkauft?
Bei mir gibt es eine ähnliche Fehlmessung, die (ich mir) schwer erklären kann. Es handelt sich allerdings um einen DS18B20PAR, der also nur 2 Leitungen benötigt. Es laufen mehrere DS18B20PAR über einen DS2482-800. Bei demjenigen Fühler, der an der längsten Leitung (ca. 3m) hängt, wird bei einer Temperatur unter 16°C nur Mist abgeliefert. Ich habe das bisher auf eine rel. "lange" Leitung geschoben, ohne es genauer zu untersuchen.
wolle g. schrieb: > Es handelt sich allerdings um einen DS18B20PAR, der also nur 2 Leitungen > benötigt. > Es laufen mehrere DS18B20PAR über einen DS2482-800. > Bei demjenigen Fühler, der an der längsten Leitung (ca. 3m) hängt, wird > bei einer Temperatur unter 16°C nur Mist abgeliefert. bei mir hängen 6 Sensoren DS18B20 an bis zu 70m in Stern Bus Topologie gemischt an nur 2 Drähten, parasitäre Speisung, einer auf dem Balkon am Atmel und seit über einem Jahr. Mit einem Raspi ging das nicht. Klar hatte ich mit der ersten Software "Problemchen" aber diese evtl. unelegant selbst gelöst, aber nun läufts. 1. massiv ins Timing der "Source Software" eingegriffen 2. ich prüfe CRC 3. wenn es CRC oder andere Fehler gibt messe ich nach. seit dem läuft das.......
:
Bearbeitet durch User
Peter R. schrieb: > Nachts zum Beispiel, bei klarem Himmel kann der schwarze 18B20 mehr > Wärme abstrahlen als ein aus Glas bestehendes Thermometer und schon ist > der 18B20 kälter als das Thermometer. Aber keine 12K. Der DS18B20 befindet sich nicht im Vakuum. Mehr als 3..4K wird der Sensor dabei nicht durch Strahlung runtergekühlt.
Ich gehe von einem Softwarefehler aus. Das stimmt was mit dem Timing nicht. Und es ist gut möglich, dass sich das erst bei niedrigen Temperaturen bemerkbar macht.
Joachim B. schrieb: > Klar hatte ich mit der ersten Software "Problemchen" aber diese evtl. > unelegant selbst gelöst, aber nun läufts. > > 1. massiv ins Timing der "Source Software" eingegriffen Uwe K. schrieb: > Ich gehe von einem Softwarefehler aus. > Das stimmt was mit dem Timing nicht. denke ich auch, so ging es mir ja zu Anfang auch wenn es nicht zu niedrige Versorgung ist oder miese Klemmen, Lötstellen o.ä.
:
Bearbeitet durch User
Ja, danke für die vielen Kommentare. @Jürgen S (jurs) Mein System steuert keinen Frostwächter, und diese "Hütte" ist ein kürzlich kernsanierter Massivbau. Mein System soll so gesehen nur einen Heizungsausfall melden. Wetterdaten prüfe ich ohnehin. Aber danke für den Tip. Der Sensor lief bei mir hier zu Hause einwandfrei, so daß ich mittlerweise auch ein SW-Problem vermute. Aber das kann ich nur am Sytem selber und hier zu Hause prüfen.. Ist eine weitere Aufgabe für den Winter..
Hanns-Jürgen M. schrieb: > Aber das kann ich nur am Sytem > selber und hier zu Hause prüfen.. es gibt Kältespray oder den Gefrierschrank, das kann ich also überall auch im Sommer simmulieren.
:
Bearbeitet durch User
Joachim B. schrieb: > Hanns-Jürgen M. schrieb: >> Aber das kann ich nur am Sytem >> selber und hier zu Hause prüfen.. > > es gibt Kältespray oder den Gefrierschrank, das kann ich also überall > auch im Sommer simmulieren. Was soll ich damit simulieren? Es liegt kein "Kälteproblem" vor, es waren 14 Grad im Haus.
Hanns-Jürgen M. schrieb: > Was soll ich damit simulieren? Es liegt kein "Kälteproblem" vor, es > waren 14 Grad im Haus. aber da trat das Problem doch auf oder irre ich? wolle g. schrieb: > Bei demjenigen Fühler, der an der längsten Leitung (ca. 3m) hängt, wird > bei einer Temperatur unter 16°C nur Mist abgeliefert. Uwe K. schrieb: > Und es ist gut möglich, dass sich das erst bei niedrigen Temperaturen > bemerkbar macht. das ist alles mit Kältepray oder im Gefrierschrank testbar Joachim B. schrieb: > wenn es nicht zu niedrige Versorgung ist > oder miese Klemmen, Lötstellen o.ä. das natürlich nur wenn der ganze Aufbau getestet wird, lange Leitung, mit allen Klemmstellen aber wenn es Störungen (Funk, EMV) vor Ort sind natürlich nicht, da hilft nur Analyse.
Joachim B. schrieb: > Hanns-Jürgen M. schrieb: >> Was soll ich damit simulieren? Es liegt kein "Kälteproblem" vor, es >> waren 14 Grad im Haus. > > aber da trat das Problem doch auf oder irre ich? > Nein, die Temperatur war 14 Grad, der aus dem DS wurde ein Wert von 2 Grad ausgelesen. Auch im Sommer steigt die Innenraum-Temperatur nicht besonders an, im Winter fällt sie auf 5..7 Grad (letzter Winter), und da a´waren die Meßwerte okay Zum Thema: Ich gleube, ich werde das System hier nachbauen, halt nur ohne PIR und ohne GSM. Dann kann ich eine Statistik erstzellen, z.B. CRC Fehler/ CRC okay; große Tempabweichung zwischen 2 Meßwerten usw.
Hanns-Jürgen M. schrieb: > Ich gleube, ich werde das System hier nachbauen, halt nur ohne PIR und > ohne GSM. Dann kann ich eine Statistik erstzellen, z.B. CRC Fehler/ CRC > okay; große Tempabweichung zwischen 2 Meßwerten usw. Bei OneWire-Sensoren stellt sich auch immer die Frage: Liegt eine "parasitäre" oder "normale" Stromversorgung des Sensors vor. Die normale Stromversorgung der Sensoren ist um ein vielfaches zuverlässiger.
Jürgen S. schrieb: > Die normale Stromversorgung der Sensoren ist um ein vielfaches > zuverlässiger. klar bei erhöhtem Verdrahtungsaufwand, ich fand parasitär besser weil ich immer noch 2 freie Telefonadern im Haus habe, überall. vernünftig angesteuert in Spannung und Timing und auch kritisch die Werte beguckt läuft das seit 4 Jahren zuverlässig.
Joachim B. schrieb: > klar bei erhöhtem Verdrahtungsaufwand, ich fand parasitär besser Joachim B. schrieb: > 6 Sensoren DS18B20 an bis zu 70m Joachim B. schrieb: > 1. massiv ins Timing der "Source Software" eingegriffen 70m hören sich gut an. Mich würde deshalb interessieren, an welchen Schrauben Du gedreht hast und wie dies in Form von Zahlen (ms, µS) aussieht.
also den Source habe ich von hier: http://siwawi.bauing.uni-kl.de/avr_projects/tempsensor/ was ich alles geändert habe weiss ich nicht mehr da hilft nur der original Weg zu gucken erster Link V 0.9.2 und was draus geworden ist
1 | ein_sensor_lesen_komma_einsetzen(uint8_t wer, uint8_t *id, uint8_t bus ); |
2 | |
3 | -------
|
4 | |
5 | if ( DS18X20_start_meas( DS18X20_POWER_PARASITE, NULL ) == DS18X20_OK) |
6 | { _delay_ms( DS18B20_TCONV_12BIT ); |
7 | do
|
8 | {
|
9 | if(DS18X20_read_decicelsius( (uint8_t *)&sensor_id_str[wer][0], &decicelsius ) == DS18X20_OK ) |
ich glaub ich blicke heute selber kaum noch durch. das hier war auch wichtig Leseversuche
1 | if( diff == OW_PRESENCE_ERR ) |
2 | { retry++; |
3 | //usart_write("No Sensor found \r\n");
|
4 | |
5 | if(retry>2) // jar_retry |
6 | { _ret = OW_PRESENCE_ERR; // jar_retry |
7 | usart_write("No Sensor found \r\n"); |
8 | break; // jar_retry |
9 | } //return OW_PRESENCE_ERR; // <--- early exit! |
10 | else // jar_retry |
11 | { if(retry) // jar_retry |
12 | break; // jar_retry |
13 | }
|
14 | } // if( diff == OW_PRESENCE_ERR ) |
15 | |
16 | if( diff == OW_DATA_ERR ) |
17 | { retry++; |
18 | //usart_write("Bus Error \r\n");
|
19 | if(retry>2) // jar_retry |
20 | { _ret = OW_DATA_ERR; // jar_retry |
21 | usart_write("Bus Error \r\n"); |
22 | break; // jar_retry |
23 | } //return OW_DATA_ERR; // <--- early exit! |
24 | |
25 | { if(retry) // jar_retry |
26 | break; // jar_retry |
27 | }
|
28 | } // if( diff == OW_DATA_ERR ) |
29 | |
30 | |
31 | DS18X20_show_id_uart( id, OW_ROMCODE_SIZE ); |
32 | |
33 | if( id[0] == DS18B20_FAMILY_CODE || id[0] == DS18S20_FAMILY_CODE || |
34 | id[0] == DS1822_FAMILY_CODE ) |
35 | { retry=5; |
ich weiss ja nicht ob du Error abfängst....
Joachim B. schrieb: > ich glaub ich blicke heute selber kaum noch durch. Na, dann werde ich wohl Dir auf die Sprünge helfen müssen. Aber zunächst erst einmal vielen Dank. Ich werde mal versuchen, das für mich brauchbare herauszulesen.
So, auch das Problem ist gelöst. Durch Langzeittests über jeweils Tausende Messungen habe ich festgestellt, daß bei rund 10 % aller Messungen CRC-Fehler auftreten. Ursache ist das Timing-System, da der Systemtimer und damit die Systemuhr die höchste Priorität hat. Das ist so gewollt. Eigentlich dürfte das nichts ausmachen, da in diesem Fall halt der letzte Meßwert weiter verwendet wird bzw. wurde. Aber offensichtlich gibt/gab es Zufälle... Lösung des Problems: 1. Tritt ein CRC Fehler auf, wird das Auslesen des Temperaturwertes bis zu zwei Mal wiederholt. Ist dann immer noch die CRC fehlerhaft, wird der alte Wert beibehalten. Nach erneut vielen Tausend Messungen passiert das jetzt nicht mehr. 2. Um einzelne Fehlmessungen, die wie hier erwähnt trotz CRC durchrutschen könnten, in ihrer Auswirkung zu beschränken, habe ich ein Tiefpassfilter erster Ordnung implementiert, bei dem pro Abtastwert die Auswirkung des neuen Meßwertes auf 1/8 verringert ist.
Hanns-Jürgen M. schrieb: > So, auch das Problem ist gelöst. Durch Langzeittests über jeweils > Tausende Messungen habe ich festgestellt, daß bei rund 10 % aller > Messungen CRC-Fehler auftreten. na aber das CRC Prüfung dazu gehört wurde doch schon geschrieben und wenn der Error oder ein anderer auftritt misst man halt nochmal. Das du das nicht gemacht hast lese ich heute zum ersten Mal......
..Ich hielt das nicht für notwendig, da 15 Messungen pro Minute erfolgen. Ich war auch der Meinung, die CRC Fehler würden deutlich seltener auftreten. Meine Tests haben mich eines besseren belehrt.
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.