Tach zusammen, ich habe hier scheinbar falsche Temperaturangaben. Wenn ich über den owfs-werbserver abfrage bekommen ich 60-80 Grad angezeigt. Konfiguriert habe ich das ding auf auf Celsius mit "owfs -C". Was soll das Bedeuten? Da stimmt wohl generell was nicht? Wenn ich meine DS direkt über das System abfrage mit: /sys/bus/w1/devices/10-00080234149b/w1_slave dann bekomme ich etwa 18 Grad also 18625 (Milligrad) angezeigt. Beim Raumthermometer zeigt 15,2 °C an. Ein paar Milligrad Abweichung würde ich für normal halten, aber das sind immerhin über 3° K Abweichung. Sind die Dinger wirklich so ungenau? Gruß PS: Angeschlossen habe ich den DS hiernach: http://webshed.org/wiki/File:Fritzing_rPI_DS1820.png Das mit dem 4,7k R müsste doch so richtig sein oder? Was mir außerdem noch auffällt ist, dass die Messungen teilweise von Sekunde zu Sekunde um bis zu 3K abweichen! ... Man kann zwar 5 Messungen glätten, wäre ja auch kein Ding. Aber gibts da nicht etwas, dass ein bisschen genauer arbeitet, oder könnte es noch einen anderen Grund haben, warum das Ding so ungenau zu sein scheint?
Gast
#3067834
Ice Rage schrieb: > Wenn ich meine DS direkt über das System abfrage mit: > /sys/bus/w1/devices/10-00080234149b/w1_slave dann bekomme ich etwa 18 > Grad also 18625 (Milligrad) angezeigt. Beim Raumthermometer zeigt 15,2 > °C an. Ein paar Milligrad Abweichung würde ich für normal halten, aber > das sind immerhin über 3° K Abweichung. Sind die Dinger wirklich so > ungenau? Wenn du ein Orginateil von Maxim hast, dann gibt Maxim +/- 0.5 Genauigkeit an. Was schon sehr beachtlich ist. Wenn du allerdings einen DS18S20 aus Fernost / China o.Ä. hast, dann erwischst du leicht eine nette Fälschung. Auf der steht zwar auch DS18S20 - aber natürlich nicht mit der Genauigkeit. Ansonsten ein Raumthermometer - kommt halt auf das Raumthermometer an. Wenn das Ding (wie die meisten) einen NTC/PTC verbaut hat, dann kannst du getrost +/-3 Grad rechenen. Die Dinger sind selbst in besseren Preiklassen höchstens Schätzeisen. Ich hatte mal 2 identische von Hama da. Halt die für 29€. Sind nen Tag nebeneinander gestanden und hatten immernoch 2 Grad Abweichung voneinander. Bei der Luftfeuchtigkeit waren es sogar 7% rel. Luftfeuchte Abweichung.
HDD-Sucher schrieb: > Wenn du ein Orginateil von Maxim hast, dann gibt Maxim +/- 0.5 > Genauigkeit an. Was schon sehr beachtlich ist. Wenn du allerdings einen > DS18S20 aus Fernost / China o.Ä. hast, dann erwischst du leicht eine > nette Fälschung. Auf der steht zwar auch DS18S20 - aber natürlich nicht > mit der Genauigkeit. Hast du da mal eine Quelle dazu? Hast du ein gefälschtes Teil? Allein mir fehlt sonst der Glaube. Ich habe jetzt schon sehr viele von denen aus Fernost gekauft und die haben sich exakt so verhalten wie die von Digikey oder Reichelt. Nie eine abweichende Temperatur. Immer diese Märchen. gruß cyblord
Also die Temperaturanzeige in der Konsole passt jetzt irgendwie. Aber wenn ich den selben sensor über owfs mit python abfrage, kommt da nur Müll dabei raus. http://666kb.com/i/cbzv42qgnbv5tu1aw.jpg Hat jemand ne Ahnung woran das liegen kann?
Angehängte Dateien:
hat jemand schon mal solche merkwürdigen werte über das owfs ausgelesen?
Gast
#3068267
Ice Rage schrieb: > hat jemand schon mal solche merkwürdigen werte über das owfs ausgelesen? Du bist bestimmt nicht der erste, der owfs auf pi einsetzt, um DS18S20 Daten zu entlocken. Die Sache mit den Milligrad mußt du dir wohl abschminken. Wenn der Sensor nicht genug rauscht, bringt auch Oversampling nicht.
Ich würde mir mal die Raw-Werte anschauen, die vom Sensor kommen, die werden bestimmt bloß falsch konvertiert. Übrigens: Dieses Forum ist aktiv genug, um nicht drei Threads mit demselben Thema zu eröffnen und die ständig durch doppelte Beiträge zu pushen. Warte doch einfach ein bisschen, dann antwortet schon jemand.
Nerd schrieb: > Ice Rage schrieb: >> hat jemand schon mal solche merkwürdigen werte über das owfs ausgelesen? > > Du bist bestimmt nicht der erste, der owfs auf pi einsetzt, um DS18S20 > Daten zu entlocken. Die Sache mit den Milligrad mußt du dir wohl > abschminken. Wenn der Sensor nicht genug rauscht, bringt auch > Oversampling nicht. Die Milligrad interessieren mich auch nicht. Ich lege keinen Wert auf eine derartige Genauigkeit. Wenn das Ding +- 0,5 Grad Abweichung hat, dann ist das schon in Ordnung. Das sah aber wie gesagt eine Zeit über nicht so aus, deshalb der Thread hier. Du musst scohn richtig lesen, bevor du auf etwas antwortest, dass überhaupt nichts mit der Frage zu tun hat. Was heißt rauschen und was meinst du mit Oversampling? In welchem Zusammenhang steht das mit meiner Frage ... kann ich nicht erkennen. Tut mir leid. Sven B. schrieb: > Ich würde mir mal die Raw-Werte anschauen, die vom Sensor kommen, die > werden bestimmt bloß falsch konvertiert. > > Übrigens: Dieses Forum ist aktiv genug, um nicht drei Threads mit > demselben Thema zu eröffnen und die ständig durch doppelte Beiträge zu > pushen. Warte doch einfach ein bisschen, dann antwortet schon jemand. Wieso 3? Ich habe diesen Thread hier eröffnet, weil ich dachte es hätte vielleicht etwas mit den Sensoren zu tun -> also Forum µKontroller. Dann habe ich, nach dem für mich geklärt ist, dass es am Sensor nicht liegen kann einen Thread in der PC-Programmierung eröffnet, weil ich ebenfalls davon ausgehe, dass es ein Softwareproblem ist. Es wird wohl etwas im ow Paket nicht richtig konfiguriert sein. Was das deiner Meinung nach speziell mit µKontrollern zu tun haben soll, musst du mir mal erklären! Es handelt sich hier bei um den 1-wire Bus! So gesehen könnte ich dann hier auch Fragen zu Miksrohsoft Office posten, weil das auch auf Systemen läuft die was mit µKontrollern zu tun haben?! .... naja ....
Gast
#3068403
Ice Rage schrieb: > Was heißt rauschen und was meinst du mit Oversampling? http://de.wikipedia.org/wiki/Rauschen_%28Physik%29 http://de.wikipedia.org/wiki/Oversampling Anschließend Mittelung zur Verringerung des Quantisierungsrauschens ... Aber wenn dich die Milli-Grad sowieso nicht interessieren, ist das auch egal.
Ich habe 8 Stück dieser Sensoren (aus China) an einem Atmega644 hängen. Die sind von 3 verschiedenen Lieferanten und zur Hälfte gekapselt. Alle liegen im Bereich von 1 K Fehler bei 20 °. Ich habe aber den Widerstand zwischen Datenausgang und +5V auf 2,7 K reduziert.
Gert Kawa schrieb: > Ich habe 8 Stück dieser Sensoren (aus China) an einem Atmega644 hängen. > Die sind von 3 verschiedenen Lieferanten und zur Hälfte gekapselt. > Alle liegen im Bereich von 1 K Fehler bei 20 °. > > Ich habe aber den Widerstand zwischen Datenausgang und +5V auf 2,7 K > reduziert. Hm, ok. Was bewirkt das schaltungstechnisch mit dem 2,7K ?
Ice Rage schrieb: > Hm, ok. Was bewirkt das schaltungstechnisch mit dem 2,7K ? Der 4,7K ist ein Pullup um die DQ-Leitung auf HIGH Pegel zu ziehen. Je kleiner der Pullup wird, desto mehr Strom kann der DS18S20 ziehen. Wenn der Sensor parasitär betrieben wird, dann wirst Du bei einer langen Leitung einen stärkeren Pullup brauchen (Strong Pullup = 2,7k). Versuche es einfach mal. Allerdings tippe ich bei dem Python Problem eher darauf, dass Du den falschen Code verwendest. Der DS18S20 liefert andere Daten als ein DS18B20. Die werden unterschiedlich berechnet. Darauf musst Du achten.
Florian Trück schrieb: > Ice Rage schrieb: >> Hm, ok. Was bewirkt das schaltungstechnisch mit dem 2,7K ? > > Der 4,7K ist ein Pullup um die DQ-Leitung auf HIGH Pegel zu ziehen. > Je kleiner der Pullup wird, desto mehr Strom kann der DS18S20 ziehen. > Wenn der Sensor parasitär betrieben wird, dann wirst Du bei einer langen > Leitung einen stärkeren Pullup brauchen (Strong Pullup = 2,7k). Versuche > es einfach mal. jo besten dank. betreiben will ich den tatsächlich an einer längeren leitung. > > Allerdings tippe ich bei dem Python Problem eher darauf, dass Du den > falschen Code verwendest. Der DS18S20 liefert andere Daten als ein > DS18B20. Die werden unterschiedlich berechnet. Darauf musst Du achten. die sache ist nur, dass ich den vollkommen typunabhängig auslese über owfs. der typ wird mir korrekt angegeben, also kann zwar ermittelt werden. aber für die initialisierung gebe ich gar keinen typ an. und es gibt auch keine typspezifischen methoden.
Gast
#3069150
Ice Rage schrieb: > ... und es gibt auch keine typspezifischen methoden. Du meinst: "es sind keine typspezifischen Methoden implementiert, obwohl die Register der Bausteine unterschiedlich interpretiert werden müßten" Komm mal von deinem Abstraktionslevel runter, guck in die Datenblätter und dann in die DS18S20 bzw. DS18B20 Treiber in den owfs-Sourcen. Beim DS18S20 liegen die Temperaturdate komplett im LS Byte, beim DS18B20 liegt die oberen drei Bits im MS Byte und der Rest im LS Byte. Die Bausteine unterscheiden sich im 1-Wire Family Code (DS18S20 10h bzw. DS18B20 28h). Kontrollier doch mal, ob owfs den richtig ausliest.
So schlecht sind die China Teile nicht, habes mal 5 Teile vermessen in Eiswasser und in Heisses wasser. Abweichungen waren immer in Zehntel Bereich. Die Absolut temperatur kan naturlich mehr abweichen.
Angehängte Dateien:
-
DS18B20.png
12 KB
Ice Rage schrieb: > Also die Temperaturanzeige in der Konsole passt jetzt irgendwie. Aber > wenn ich den selben sensor über owfs mit python abfrage, kommt da nur > Müll dabei raus. Sehe ich da im Bild zwei verschiedene IDs? Shell: 10-0008021daef0 Python: 10.67c6697351ff
Christian H. schrieb: > Ice Rage schrieb: >> Also die Temperaturanzeige in der Konsole passt jetzt irgendwie. Aber >> wenn ich den selben sensor über owfs mit python abfrage, kommt da nur >> Müll dabei raus. > > Sehe ich da im Bild zwei verschiedene IDs? > Shell: 10-0008021daef0 > Python: 10.67c6697351ff Schau dir doch mal ganz genau die beiden Seriennummern an. Was fällt dir auf? Einerseits Punkt, andererseits Strich. Wie sollen das beides änliche Seriennummern sein? Eines ist eine Seriennummer, die in der Konsole. owfs vergibt dann noch mal intern Nummern wie es aussieht und das ist die mit dem Punkt, die dann auch im Pythonfenster benutzt werden muss. Also: Nein! Daran liegt es sicher nicht. Nerd schrieb: > Ice Rage schrieb: >> ... und es gibt auch keine typspezifischen methoden. > > Du meinst: "es sind keine typspezifischen Methoden implementiert, obwohl > die Register der Bausteine unterschiedlich interpretiert werden müßten" > > Komm mal von deinem Abstraktionslevel runter, guck in die Datenblätter > und dann in die DS18S20 bzw. DS18B20 Treiber in den owfs-Sourcen. > Beim DS18S20 liegen die Temperaturdate komplett im LS Byte, beim DS18B20 > liegt die oberen drei Bits im MS Byte und der Rest im LS Byte. > > Die Bausteine unterscheiden sich im 1-Wire Family Code (DS18S20 10h bzw. > DS18B20 28h). Kontrollier doch mal, ob owfs den richtig ausliest. Ich weiß nicht ob du mit dem Konzept objektorientierter Programmierung vertraut bist, aber irgendwie macht das auf mich nicht den Eindruck. Es gibt also überhaupt gar keinen Grund, warum ich von irgendwas runter kommen müsste. Alle spezifischen Low-level-routinen, die nötig sind um sensorspezifisch anzusteuern, sind in den beiden Methoden die ich benutze gekapselt. Da ist es mir vollkommen wumpe was da dranhängt. Das ist ja eben gerade der Grund, warum man eine api verwendet!
Hat hier echt keiner jemals owfs benutzt und damit erfolgreich Temperaturwerte ausgelesen?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.