I2C_HDC1008: Fehler in Lese-Logik?

[yoda_gh]

Hallo!

Ich habe mir einen HDC1080 gekauft und ihn auch an meinem Raspi mit dem HDC1008-Modul zum Laufen zu bekommen, erstmal Danke dafür!! Nachdem ich jedoch sporadische Lese-Fehler habe, habe ich mal die I2C-Kommunikation angeschaut und das Datenblatt für meinen HDC1080 und auch für den HDC1008 gelesen.

Soweit ich das sehe, ist die Lese-Operation für HDC1008 und HDC1080 gleich beschrieben - aber im Modul aktuell nicht korrekt umgesetzt. Man kann ja Temperatur & Feuchte getrennt oder zusammen messen - aktuell macht das Modul aber für mein Dafürhalten eine Mischung aus beidem.

Ich verstehe das Datenblatt so:

• Setze in Reg.2, Bit 12 auf 1 für Lesen von T&H
• Wenn Du T&H lesen willst, setze Adresse auf 0, um BEIDE Messungen zu starten
• Warte, bis die Messungen komplett sind - hier ist das Datenblatt für mich nicht ganz klar, aber ich vermute, man muss die Conversion Time für T UND für H abwarten
• Lese BEIDE Werte auf einmal (also 4 Byte)

Das Modul macht aber aktuell:

• Setze in Reg.2, Bit 12 auf 1
• setze Adresse auf 0
• Warte T-Conversion Time
• Lese T (2 Byte)
• setze Adresse auf 1
• Warte H-Conversion Time
• Lese H (2 Byte)

Das ist nach meinem Verständnis das Prozedere für getrenntes Lesen, dann sollte aber Reg.2, Bit 12 auf 0 gesetzt werden.

Ich sehe bei mir auch, dass das Lesen von T IMMER einmal schiefgeht und erst beim zweiten Versuch klappt.

Versuchsweise habe ich Bit 12 auf 0 gesetzt für getrenntes Lesen und damit scheint es fehlerfrei durchzulaufen.

Besser wäre aber wohl, gemeinsam zu lesen. Soll ich dafür mal einen Patch versuchen? Ich habe hier leider nur einen HDC1080 zum Testen, aber mir scheint es, als wäre das Prozedere für HDC1080 und HDC1008 identisch.

Gernot

[yoda_gh]

So, ich glaube, ich habe mein eigentliches Problem jetzt auch gefunden. Aus irgendwelchen Gründen (vielleicht weil meine I2C-Kabel direkt neben der FritzBox, also DECT & WLAN-Basis vorbei laufen) habe ich regelmäßig I2C-Fehler.

Beim Lesen werden diese auch sauber von I2C_HDC1008 über eine Exception behandelt und das Lesen wird wiederholt.

Wenn aber beim Schreiben etwas schief geht, dann wird das ignoriert - und hier ist I2C_HDC1008 in guter Gesellschaft, das Egebnis vom Schreiben scheint in den meisten I2C-Modulen ignoriert zu werden. Die I2CRec-Funktion wird trotz des Namens auch nach erfolgtem Schreiben aufgerufen und darüber mitgeteilt, ob das Schreiben geklappt hat.

In meinem Fall geht wohl das Schreiben der Register-Adresse sporadisch schief und damit kann der Sensor natürlich keine vernünftigen Daten liefern. Folgerichtig bekomme ich Dutzende Lese-Fehler, aber dann komischerweise irgendwann FF FF zurück, was sich in 125 °C und/oder 100% Luftfeuchte umrechnet...

Ich habe jetzt also einen Patch geschrieben, der...

• den SENDSTAT für i2cwrite auswertet und nur wenn das Schreiben geklappt hat, den DEVICE_STATE weiterschaltet (Zustandsumschaltung jetzt in I2CRec statt UpdateValues)
• Temparatur & Feuchte kombiniert liest wie im Datenblatt beschrieben (siehe Post oben)

Seitdem scheint das Lesen immer korrekt durchzulaufen, auch die oben beschriebene Wiederholung tritt nicht mehr auf.

Siehe Anhang...

Über ein kurzes Feedback würde ich mich freuen - wenn gewünscht, kann ich den Patch auch gerne aufspalten/umschreiben etc.

Gernot

[jensb]

Hallo Gernot,

SENDSTAT auszuwerten ist empfehlenswert. Du kannst dir das auch z.B. in 51_I2C_TSL2561.pm ansehen. Den TLS2561 kann man nämlich auch indirekt über einen Arduino/ESP8266 mit Firmata anbinden. Das ist spätestens mit WiFi keine Festverkabelung mehr. Geht dann mal ein Zugriff schief, wird das bemerkt und der Zugriff wiederholt oder das Ergebnis verworfen. Dadurch gibt es so gut wie keine Fehlmessungen.

Grüße,
Jens

[yoda_gh]

Hallo Jens!

Ah, interessant, Du liest in I2C_TSL2561 den Sendstat sofort synchron nach einem i2cwrite. Ich hatte gedacht, ich müsste warten, bis meine I2CRec-Funktion aufgerufen wird und müsste das asynchron behandeln? Ich hatte daher mit Zuständen gearbeitet.

Ist denn irgendwo dokumentiert, wie das I2C-Interface hier gedacht ist, also ob ich mich immer darauf verlassen kann, dass der Sendstat sofort nach einem i2cwrite verfügbar ist? Wenn ja, warum wird das dann nicht einfach als Return-Wert zurückgegeben?

Generell wäre auch wichtig zu wissen, ob schlawiano überhaupt das I2C_HDC1008 noch pflegt und welche Variante er bevorzugt - ich habe leider weder hier etwas von ihm gehört, noch hat er auf eine persönliche Mail, verschickt über das Forum reagiert. In der MAINTAINER.txt ist I2C_HDC1008 auch gar nicht eingetragen, aber vielleicht wurde das damals schlicht vergessen?

Bei mir sind auf jeden Fall seit der Änderung die Lesefehler drastisch weniger geworden - vorher hatte ich ca. alle 90 Minuten 125 °C bei 100% Feuchte in der Wohnung, seit meinem Patch nur noch ein einziges Mal in drei Wochen. Man sollte die Änderung also auf jeden Fall in der einen oder anderen Form einbringen.

schlawiano, ping?

[jensb]

Hallo Gernot,

zu schlawiano kann ich leider auch nicht viel sagen. Das Modul ist von 2016, er hat vor fast 1 Jahr seinen letzten Beitrag gepostet und war zuletzt vor mehr als 3 Monaten im Forum angemeldet. Versuche es vielleicht noch einmal mit einer Mail. Außerdem solltest du dir vorher die Hinweise für das Einbringen von Patches in der Wiki ansehen und eine Patch-Thread öffnen. Wenn sich dann selbst nach längerem Warten trotzdem nichts tut und du bereits bist, die Betreuung des Moduls zu übernehmen, kannst du Rudi ansprechen.

Ob es in jedem Fall etwas bringt, SENDSTAT beim Write auszuwerten, sei dahingestellt - spätestens beim Read sollte man es aber wirklich tun.

Eine klare Definition, ob SENDSTAT sofort verfügbar ist, kann ich dir nicht geben. Das liegt vor allem daran, dass der Zugriff auf I2C indirekt realisiert ist und mehrere Schnittstellen möglich sind (RPII2C, FRM, ...), die sich in ihrem Verhalten z.T. deutlich unterscheiden. Die einen sind schnell und blockend, die andern langsam und nicht blockend (und es gibt möglicherweise auch Mischformen). Das Modul des TSL2561 macht ein Auto-Detect und stellt sich entsprechend ein. Das ist vor allem dann wichtig, wenn man ein bestimmtes Timing zwischen Writes und Reads einhalten will und hat weniger mit SENDSTAT an sich zu tun. Empfehlung: Wenn möglich mehrere Schnittstellen ausprobieren. Das Ergebnis wäre auch was für die Wiki.

Grüße,
Jens

[yoda_gh]

Zur Info: ich habe die Maintenance von dem Modul jetzt übernommen und die Änderungen wie oben beschrieben eingepflegt sowie weitere Plausibilitäts-Checks. Damit sollten auch bei schlechter I2C-Verbindung (dafür habe ich wohl das beste Test-Bett) (fast) keine unsinnigen Readings mehr auftauchen.