Forum: Mikrocontroller und Digitale Elektronik HTU21 Mögliches Problem mit CRC Erzeugung im Sensor


von Gerhard O. (gerhard_)


Lesenswert?

Problemhintergrund:

Ich habe ein mysteriöses Problem mit chinesisch eBay vermarkteten HTU21 
Bords (GY-21). Obwohl der Sensor plausible Daten liefert, bekomme ich 
keine brauchbaren CRC Werte zurück. Der empfangene CRC Wert ist immer 0. 
auch kann ich scheinbar keine Werte ins User Register schreiben. 
SHT21,25,15,75 funktionieren übrigens alle mit der selben FW anstandslos 
und der CRC Wert ist korrekt und wird von der CRC Prüfroutine 
anstandslos als korrekt bewertet. Die HTU21 Meßwerte zeigen sonst gute 
Übereinstimmung mit den SHTxx Vergleichs Sensoren.

An der FW und Hardware scheint es nicht zu liegen. Kontroller ist ein 
18LF2620. Die HTU21 sollen mit SHTxx Typen auswechselbar sein. Mein 
Referenz Design wurde direkt von Sensirion Beispiel übernommen und auf 
dem PIC lauffähig gemacht. Wie gesagt alle SHT Sensoren laufen mit 
dieser FW Version einwandfrei. Meine FW erkennt ob ein wahrer I2C 
Protokoll Sensor angeschlossen ist oder das frühere SHT11-75 Protokoll 
verwendet. Und ja, ich setze das NOACK bit erst beim Lesen des CRC 
Wertes um die Transaktion zu beenden.( Wenn man den CRC nicht braucht 
kann man schon vorher durch NOACK die Transaktion beenden.)

Hat jemand im Forum ähnliche Erfahrungen gemacht? Mir ist es, wie einige 
von Euch bemerkt haben, schon öfters passiert den Balken vor dem Auge 
nicht bemerkt zu haben und immer gleich die anderen zu verdächtigen ohne 
bemerkt zu haben, daß ich nur auf das Subjekt auf dem Sessel vor dem PC 
schauen hätte müssen um den besagten Fehler zu finden:-)

Jedenfalls stellt sich die Frage, liegt es am Sensor (Fake? Rejects, 
etc.), oder habe ich irgendein subtiles FW oder HW Problem. Ich habe 
schon fast Lust einen HTU2x aus zuverläßiger Quelle zu besorgen um 
festzustellen ob da ein Unterschied zu vielleicht zweifelhaften 
Produkten aus unbeksnnter Herstellung existiert.

Bitte kritisiert mich nicht, ja der Gerhard verdächtigt wieder mal die 
Chinesen zu unrecht. Aber wenn man noch keine Erfahrungen mit einem 
neuen Teil hat, dann ist man eben unsicher. Es könnten ja tatsächlich 
fehlerhafte Produkte sein die irgendwie den Weg in den Markt gefunden 
haben.

Dagegen spricht aber interessanterweise, noch niemand im Internet 
scheint solche Probleme gehabt zu haben.

Um ganz sicher zu gehen möchte ich noch oszillographisch untersuchen ob 
der zurückgeliefete Wert tatsächlich 0 Bit Werte hat.

Ich kann den HTU21 Default User Register Wert von 0x02 lesen, aber nicht 
verändern. Das weiß ich weil ich beim initialisieren das Heater Bit für 
10 s einschalte um den Sensor zu testen. Bei den SHTxx funktioniert das 
immer einwandfrei. Bit 2 ist gesetzt und nach 10s wird es rückgesetzt. 
Beim HTU21 tut sich gar nichts. Auch wenn ich T und RH abfrage ist der 
CRC Wert immer Null. Bei den SHT Typen stimmt der CRC.

Was meint ihr?

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Hier sind noch ein paar Diagnostic Messages:

SHT2X V1.08, 18-Jul-16 22:39:09


HTU21 (GY-21 Board):

u2e -> Command to test Sensor Operation

SHT2x_Diagnostics:

Executing SHT2x_SoftReset

SHT2x_GetSerialNumber:      11 32 2b 68 3e 00 54 48
SHT2x_ReadUserRegister:     02h 4 - "4 = CRC Error", sollte 0x06 sein
SHT2x_WriteUserRegister:    02h 4 - CRC Error
Sensor Type Detected:       SHT21 (HTU21)
SHT2x_MeasureHM (RH)        7a8ah 31368 4 - CRC Error
SHT2x_MeasureHM (T):        65c4h 26052 4 - CRC Error
SHT2x_MeasurePoll (RH):     7a7ah 31352 4 - CRC Error
SHT2x_MeasurePoll (T):      65c4h 26052 4 - CRC Error
SHT2x_CalcTemperatureC:     23.00 C
SHT2x_CalcRH:               53.79 %
SHT2x_CalcDewpoint:         13.13 C
SHT2x_ReadUserRegister:     02h 4
SHT2x_Battery Status =      GOOD

Rel. Humidity:53.79 %
Temperature  :23.00 C

Error occurred
Humidity RH: --.-- %
Temperature: --.-- C
End

Note: Die "4" ist der RETURN Wert der READ/WRITE Funktionen

// Error codes
typedef enum{
  ACK_ERROR                = 0x01,
  TIME_OUT_ERROR           = 0x02,
  CHECKSUM_ERROR           = 0x04,
  UNIT_ERROR               = 0x08
}etError;


----------------------------------------------------------------

Hier mit SHT21 und anfangs mit Heater ON:

u2e


SHT2x_Diagnostics:

Executing SHT2x_SoftReset

SHT2x_GetSerialNumber:      53 00 0b 0e b3 04 45 00
SHT2x_ReadUserRegister:     0eh 0 - "No CRC error, Heater is ON"
SHT2x_WriteUserRegister:    0eh 0
Sensor Type Detected:       SHT21
SHT2x_MeasureHM (RH)        897fh 35196 0
SHT2x_MeasureHM (T):        65b8h 26040 0
SHT2x_MeasurePoll (RH):     896fh 35180 0
SHT2x_MeasurePoll (T):      65b8h 26040 0
SHT2x_CalcTemperatureC:     22.97 C
SHT2x_CalcRH:               61.10 %
SHT2x_CalcDewpoint:         15.06 C
SHT2x_ReadUserRegister:     0eh 0
SHT2x_Battery Status =      GOOD

Rel. Humidity:61.10 %
Temperature  :22.97 C
End

-----------------------------------------------------------------------

Hier mit SHT21 und anfangs mit Heater OFF:

u2e


SHT2x_Diagnostics:

Executing SHT2x_SoftReset

SHT2x_GetSerialNumber:      53 00 0b 0e b3 04 45 00
SHT2x_ReadUserRegister:     0ah 0 - "No CRC Error, Heater is now OFF"
SHT2x_WriteUserRegister:    0ah 0
Sensor Type Detected:       SHT21
SHT2x_MeasureHM (RH)        87cfh 34764 0
SHT2x_MeasureHM (T):        6548h 25928 0
SHT2x_MeasurePoll (RH):     87cfh 34764 0
SHT2x_MeasurePoll (T):      6548h 25928 0
SHT2x_CalcTemperatureC:     22.67 C
SHT2x_CalcRH:               60.30 %
SHT2x_CalcDewpoint:         14.58 C
SHT2x_ReadUserRegister:     0ah 0
SHT2x_Battery Status =      GOOD

Rel. Humidity:60.30 %
Temperature  :22.67 C
End

von Gerhard O. (gerhard_)


Angehängte Dateien:

Lesenswert?

Hier sind zwei Oszi Bilder die das CRC Problem zeigen:

Das erste ist der SHT21 mit korrekter CRC:

Die Sequenz: HOST: START 0x80 ACK Start/Address
             HOST:       0xE7 ACK SHT READ USER REG CMD
             HOST  START 0x81 ACK Send SHT READ CMD with bit0=1
             SHT: (USER) 0x0E ACK vom HOST
             SHT:  (CRC) 0x1F NOACK vom host
             HOST:       STOP (nicht sichtbar)

Das zweite ist der HTU21 mit der falschen oder fehlenden CRC:

Die Sequenz: HOST: START 0x80 ACK Start/Address
             HOST:       0xE7 ACK SHT READ USER REG CMD
             HOST  START 0x81 ACK Send SHT READ CMD with bit0=1
             SHT:  (USER)0x06 ACK vom HOST
             SHT:  (CRC) 0x00 NOACK vom host - sollte 0xA6 sein
             HOST:       STOP (nicht sichtbar)

Die Störspitzen sind durch den offenen Meßaufbau bedingt.

Im normalen Test Betrieb bekomme ich immer 0x02. in der 1s Loop ist es 
immer 0x06. Das ist möglicherweise bedingt durch die vorherige Abfrage 
der Serien Nummer. Muß ich noch ergründen warum das so ist.

Nachtrag: Der SoftReset scheint dem HTU21 nicht gut zu bekommen. Wenn 
ich den SOFTRESET weglasse bekomme ich die 0x06. Hier ist vll. ein 
Clue...

Beim SHT21 funktioniert das einwandrei.

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Ja. nach einen SoftReset gibt das User Register 0x02 aus. Ohne Reset ist 
es 0x06. Dem Datenblatt nach sollte es aber 0x02 sein.

von Hosenmatz (Gast)


Lesenswert?

Leider kann ich Dir keinen auf die Sensoren bezogenen Hinweis geben.

Allerdings, und bis jemand kommt, der die Sensoren gut kennt, würde ich 
Dir gerne folgenden Rat geben, da Du selbst anmerkst, dass eine 
Selbstbetrachtung schwierig ist.

Mache eine Liste von Dingen, die es "ganz sicher nicht" sind. Ordne sie 
nach Deiner Einschätzung von "Das wäre ein Wunder" nach "Hm. Das wäre 
doch seltsam". Du verstehst was ich meine? Ganz doll unwahrscheinlich 
bis naja, vielleicht möglich.
Dann fange an sie zu überprüfen - und wenn Du Dir noch so dumm dabei 
vorkommst. Es geht ja gerade darum Deiner Intuition mit ein wenig 
Erfahrung zu unterfüttern.
Ob Du nun mit dem Wunder anfängst oder dem am wenigsten 
unwahrscheinlichsten ist eigentlich egal. Nach Murphy sind die Wunder am 
wahrscheinlichsten, aber was weiß der schon? :-)

Nur so eine Idee von mir. Kann man übrigens auch iterieren und dem man 
zu immer wahrscheinlicheren unwahrscheinlichen Ursachen kommt.

Viel Erfolg.

von Gerhard O. (gerhard_)


Lesenswert?

Hallo,

Bin überrascht im dies Stunde noch einen Leser zu finden. Bei mir ist es 
ja erst 19:00 MST.

Danke für Deine Ratschläge. Prinzipiell könnte das sicherlich nützlich 
sein.
Ich werde nach meinem Kaffee die bisherigen Untersuchungsergebnisse 
katalogisieren. Es könnte inmitten tatsächlich zu neuen Erkenntnissen 
führen.

Allerdings macht mir Satz "...ganz sicher nicht..." etwas Sorgen weil 
man dann leicht Opfer geschloßener Augen wird und dann naheliegendes 
leicht übersieht. Normalerweise sollte man so objektiv wie möglich sein. 
Wie Inspektor Clouseau statuierte "I suspect everone and I suspect 
nobody!"

Es dreht sich halt hauptsächlich darum ob der besagte Sensor sich in 
allen Einzelheiten an das Datenblatt hält oder ob es da aus irgendeinen 
unbekannten Grund Abweichungen gibt. Wenn man beiden Datenblättern 
glauben darf, müßten sich beide Sensortypen weitgehend bis auf kleine 
Hersteller Unterschiede funktionsmäßig gleich verhalten. Es ist ja 
irgendwie möglich, daß noch Unbekanntes im Spiel ist. Vielleicht spielt 
mir auch die FW einen bösen Streich, auch wenn man selber vollkommen 
überzeugt ist, keinen Fehler gemacht zu haben. Jetzt darf man halt nicht 
aufgeben.

Grüße,
Gerhard



Hosenmatz schrieb:
> Leider kann ich Dir keinen auf die Sensoren bezogenen Hinweis geben.
>
> Allerdings, und bis jemand kommt, der die Sensoren gut kennt, würde ich
> Dir gerne folgenden Rat geben, da Du selbst anmerkst, dass eine
> Selbstbetrachtung schwierig ist.
>
> Mache eine Liste von Dingen, die es "ganz sicher nicht" sind. Ordne sie
> nach Deiner Einschätzung von "Das wäre ein Wunder" nach "Hm. Das wäre
> doch seltsam". Du verstehst was ich meine? Ganz doll unwahrscheinlich
> bis naja, vielleicht möglich.
> Dann fange an sie zu überprüfen - und wenn Du Dir noch so dumm dabei
> vorkommst. Es geht ja gerade darum Deiner Intuition mit ein wenig
> Erfahrung zu unterfüttern.
> Ob Du nun mit dem Wunder anfängst oder dem am wenigsten
> unwahrscheinlichsten ist eigentlich egal. Nach Murphy sind die Wunder am
> wahrscheinlichsten, aber was weiß der schon? :-)
>
> Nur so eine Idee von mir. Kann man übrigens auch iterieren und dem man
> zu immer wahrscheinlicheren unwahrscheinlichen Ursachen kommt.
>
> Viel Erfolg.

von Gerhard O. (gerhard_)


Lesenswert?

In der Zwischenzeit hat sich einiges getan.

Falls es interessiert hier noch ein paar Infos:

Die Moral von der Geschicht ist: Die Sensirion und 
Silabs/Amsys/Meas-Spec Sensoren sind nur bedingt Source Code kompatibel. 
Wenn man wie ich eine universelle Firmware haben will die mit allen 
diesen Typen automatisch funktionieren soll, müssen unbedingt die 
Sensortypen erkannt werden.

Meine zur Verfügung stehenden HTU21 Typen geben bei keinen einzigen 
Kommando gültigen CRC Werte aus. Die CRC Werte sind ausnahmslos immer 
Null. Da mir im Augenblick nur die chinesischen UTH21 zur Verfügung 
stehen kann ich nicht beurteilen ob ein offizieller UTH21 sich anders 
verhalten würde. (Dem Datenblatt nach muessten RH/T und Seriennummern 
CRCs ausspucken). Es ist zweifelhaft, ob nach allen Tests sich noch ein 
Fehler in der FW verstecken könnte.

Bei allen SHT21 und 25 Typen funktioniert es genau nach Datenblatt bei 
allen Kommandos einwandfrei. Es sieht so aus als ob Sensirion alle 
Funktionen mit CRCs ausstatteten.

Leider habe ich z. Zt. keine SI7021-A20 zur Verfügung.

Beim Silabs Si7021-A20 Sensor Datenblatt steht wiederum auf Seite 9:

"The checksum byte is optional after initiating an RH or temperature 
measurement with commands 0xE5, 0xF5, 0xE3, and 0xF3. The checksum byte 
is required for reading the electronic ID with commands 0xFA 0x0F and 
0xFC
0xC9. For all other commands, the checksum byte is not supported."

Ich sah mir die Sourcen für den Si7021-A10 und den HTU21-D (Meas-spec) 
an. Dort werden auch keine CRCs beim User Register abgefragt obwohl das 
in den Sensirion Referenz Design Sourcen getan wird (und bei 
funktioniert).

http://www.amsys.info/products/htu21d.htm
https://www.sparkfun.com/products/13763

* Tested Sensors serial numbers and user register default
* -------------------------------------------------
* Fields:   A1 A0 B3 B2 B1 B0 C1 C0 UR Comments
* -------------------------------------------------
* SHT21#1 - 00 45 04 b8 d0 88 00 53 0a all CRC OK
* SHT21#2 - 00 45 04 b3 0e 0b 00 53 0a all CRC OK
* SHT25   - 00 80 02 f3 4d 8b 01 01 3a all CRC OK
* HTU21#1 - 48 54 00 3e 68 2b 32 11 02 all CRC FAIL
* HTU21#2 - 48 54 00 3e 68 40 32 11 02 all CRC FAIL
* HTU21#3 - 48 54 00 3e 67 1e 32 11 02 all CRC FAIL
* HTU21#4 - 48 54 00 3e 68 1c 32 11 02 all CRC FAIL

SN Felder A1, A0, C1 sind feste Felder

Ich werde versuchen einen UTH21 von einem lokalen Distri zu besorgen. Es 
interessiert mich nun doch ob irgend etwas mit den Chinesischen Sensoren 
"komisch" ist.

Wer von Euch hat ähnliche Erfahrungen gemacht? Ist das ein Einzelfall?

Das UR mit den 0x02/0x06 war ein Versuch der FW den drolligen Sensor 
wieder rückzusetzen. In Wirklichkeit wurde der Heater wie beabsichtigt 
eingeschaltet und hat dann ohne meine Wissen von der automatischen 
Ablaufsteuerung State Machine wegen dem CRC Fehler wieder zurück 
gesetzt. Konnte mich daran nicht mehr erinnern.

von Pieter (Gast)


Lesenswert?

moin moin,

fast das selbe Problem:

>>Meine zur Verfügung stehenden HTU21 Typen geben bei keinen einzigen
Kommando gültigen CRC Werte aus.

Meine HTUs geben richtige CRC aus.

Ich verwende Si7051(ClosedCube) und HTU21(China) und bei mir gibt es 
unterschiede in der I2C Abarbeitung.

Anwendung ist ein STM32F103, I2C Umschaltung zwischen PB67 und PB89.

Mit 2x Si7051 funktioniert das. Mit HTU21 funktioniert es nach dem 
Einschalten genau 1mal.
Mit einem I2C-Multiplexer funktionieren die HTU schon.
Im Moment sehe ich da keinen Unterschied in der Ansteuerung.

Hat jemand ähnliche Erfahrungen?

VG
Pieter

Bitte 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
Noch kein Account? Hier anmelden.