Ich habe drei DS18B20. Ich kann nicht sagen, ob einer von ihnen richtig funktioniert

Ich habe drei DS18B20 (oder ich glaube, mindestens zwei davon sind DS18B20). Ich lese sie derzeit über ein eingebettetes Linux-Board (in diesem Fall Raspberry Pi).

Ich habe zwei der Sensoren in einem Steckbrett, sie geben scheinbar genaue Temperaturen. Der dritte ist einer dieser DS18B20, der in einem "wasserdichten" Kabel von Ebay eingeschlossen ist:

Geben Sie hier die Bildbeschreibung ein

Wenn ich die Sensoren auslese, bekomme ich folgende Werte:

pi@raspberrypi:~ $ cat /sys/bus/w1/devices/28-*/w1_slave
45 01 4b 46 7f ff 0b 10 84 : crc=84 YES
45 01 4b 46 7f ff 0b 10 84 t=20312
57 01 4b 46 7f ff 09 10 c7 : crc=c7 YES
57 01 4b 46 7f ff 09 10 c7 t=21437
60 01 80 80 1f ff 80 80 2e : crc=2e YES
60 01 80 80 1f ff 80 80 2e t=22000

Dieser Befehl ruft also einfach alle Sensoren ab und liest sie aus. Ziemlich einfach. Teilen Sie t=20312durch 1000 und Sie erhalten 20,312 °C

Aber das Seltsame ist, dass der dritte Sensor immer nur Temperaturmessungen innerhalb von 0,5 Grad liefert, während die anderen beiden in der Lage sind, scheinbar bis zu 0,1 Grad zu messen. Zuerst dachte ich, dass das dritte kaputt ist, aber als ich das Datenblatt überprüfte, gibt es eindeutig an, dass das Teil auf ~ 0,5 Grad genau ist.

Ich habe eine Tabelle mit den Werten erstellt, die ich bekomme:

Breadboard Sensor #1 | Breadboard Sensor #2 | Cable Sensor
21.937                 21.562                 22.00
21.812                 21.562                 22.00
20.468                 20.478                 22.50
19.584                 20.201                 27.00
19.625                 19.687                 28.00

Also jetzt bin ich total verwirrt. Sind die Sensoren des Steckbretts defekt oder das Kabel? Wenn sie alle funktionieren, warum scheinen dann zwei von ihnen eine höhere Auflösung zu haben?

Bearbeiten: Ich habe mich mehr umgesehen und es scheint, dass einige Leute darauf gestoßen sind, und andere Leute haben vorgeschlagen, dass es sich um gefälschte Chips handeln könnte!

Update: Der Gerätetreiber für die Sensoren ( https://www.kernel.org/doc/Documentation/w1/slaves/w1_therm ):

Der Treiber unterstützt auch keine reduzierte Genauigkeit (was auch die Konvertierungszeit verkürzen würde).

Warum hat Ihr Kabelsensor nicht die gleiche Empfindlichkeit wie Ihre Steckbrettsensoren? Bist du sicher, dass es ein DS18B20 ist? Ihre Signalkette ist nicht äquivalent, und mit Signalkette meine ich digitale Kommunikation und Mathematik. Debuggen Sie Ihre Kette, listen Sie die Unterschiede auf, beseitigen Sie die Unterschiede oder erklären Sie sie.
"Warum hat Ihr Kabelsensor nicht die gleiche Empfindlichkeit wie Ihre Steckbrettsensoren?". Nun, das versuche ich herauszufinden, indem ich hier poste. Das 28-* bedeutet, dass alle Sensoren aufgelistet sind, die zur "0x28"-Gerätefamilie gehören, die der DS18B20 ist, also sind sie technisch gesehen DS18B20.
Wissen Sie, ob der Gerätetreiber die Geräteauflösung tatsächlich auf das Maximum setzt oder einfach davon ausgeht, dass sie bereits auf Maximum eingestellt ist, und es dort belässt?
Vielleicht möchten Sie die Kabelversion in das Steckbrett stecken und den Vergleich durchführen.
Haben Sie einen Vergleich auf Papier mit den digitalen Werten durchgeführt, die vom Gerät zurückkommen, bevor es Ihre Software erreicht?
Nur ein Kommentar zu Ihrem Satz "sie geben scheinbar genaue Temperaturen an". Dies wird als falsche Genauigkeit bezeichnet . Alle Sensoren liefern eine genaue Temperatur. Das zusätzliche zufällige Rauschen am Ende der Zahlen sind keine gültigen Daten, nur weil es nicht Null ist.

Antworten (4)

Wenn man sich den Quellcode von w1_therm ansieht , berührt er niemals das Konfigurationsregister und verlässt sich daher auf die programmierte Genauigkeitseinstellung im EEPROM.

In der Tat zeigt Ihr eigener Datendump, dass das Konfigurationsbyte 0x7Ffür zwei Ihrer Sensoren und 0x1Ffür einen Ihrer Sensoren ist. Dies entspricht 12 Bit bzw. 9 Bit Genauigkeit.

Sie müssen also nur einmal die Konfiguration Ihres Niederpräzisions-Temperatursensors initialisieren, im EEPROM speichern und können dann den ursprünglichen Treiber wieder verwenden. Natürlich würde die Linux-Community wahrscheinlich einen Beitrag von etwas aufgeräumtem Code zum Festlegen der Genauigkeit begrüßen ;)

Wie würde man mit einem Himbeer-Pi "nur" die Genauigkeitseinstellung ändern und in das EEPROM schreiben?

Das Datenblatt sagt auf Seite 2, Übersicht:

... und das 1 - Byte Konfigurationsregister. Das Konfigurationsregister ermöglicht dem Benutzer, die Auflösung der Temperatur-Digital-Umwandlung auf 9, 10, 11 oder 12 Bit einzustellen . Der T H , T L , und Konfigurationsregister sind nicht flüchtig (EEPROM), sodass sie Daten behalten, wenn das Gerät ausgeschaltet wird .

Seite 8 zeigt die Konfigurationsdetails. Sie müssen diese Bits auf die gewünschte Auflösung einstellen.

Siehe mein Update zur Auflösung, ich glaube der Gerätetreiber unterstützt nur die maximale Auflösung.
dann ist der Gerätetreiber defekt.

Ich würde vermuten, dass da etwas Seltsames daran ist, aber es ist nicht geradezu kaputt.

Der DS18B20 hat mehrere "bewegliche Teile": analoges Frontend, A/D, 1-Draht-Sender. Normalerweise, wenn ein IC wie dieses kaputt ist, wird es entweder still (gibt überhaupt keine Messwerte aus) oder gibt lächerliche Werte aus, die außerhalb der Charts liegen.

DS18B20 hat eine einstellbare Auflösungseinstellung, die im nichtflüchtigen Speicher des DS18B20 gespeichert ist (siehe Konfigurationseinstellungen auf Seite 8 des Datenblatts ). Der 9-Bit-Messwert mit reduzierter Auflösung belegt die höchstwertigen Bits des 12-Bit-Temperaturregisters (siehe letzter Absatz auf Seite 3 im Datenblatt ). Ich würde vermuten, dass diese Sensoren ab Werk mit unterschiedlichen Einstellungen geliefert wurden.
[Haftungsausschluss: Ich habe DS18B20 selbst nicht verwendet. Ich lese gerade das Datenblatt.]

Siehe mein Update zur Auflösung, ich glaube der Gerätetreiber unterstützt nur die maximale Auflösung.
Der DS18B20 speichert die Auflösungskonfiguration auf der Platine in seinem eigenen nichtflüchtigen Speicher. Was macht der Softwaretreiber vor diesem Hintergrund, wenn er einem DS18B20 gegenübersteht, der zufällig für eine niedrige Auflösung konfiguriert ist? Versucht es, den Sensor für eine hohe Auflösung neu zu konfigurieren? Wird eine Ausnahme ausgelöst? (Außerdem ist es nicht unvorstellbar, dass die Kabelkonfektion von eBay einen gefälschten IC enthält. Sie können genauso gut den eBay-Verkäufer um Hilfe bei der Fehlerbehebung bitten.)

Kennen Sie die Herkunft des ungeraden Sensors?

Es ist nicht ungewöhnlich, dass Hersteller durch harte Programmierung so etwas absichtlich verschlechtern. Vielleicht ist der Sensor ein Gerät mit niedrigerem Bin, vielleicht höherem Rauschen oder weniger linear, also hat er eine niedrigere Auflösung, um dies zu maskieren. Es kann DS18-kompatibel sein, ohne es zu sein. Vielleicht wurde es billiger an einen Vertrag verkauft und so "verkrüppelt", um dem Preis gerecht zu werden.