Forum: Mikrocontroller und Digitale Elektronik BMP280 + AHT10 auf dem gleichen I2C Bus


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Hat jemand beide Sensoren auf dem gleichen I2C-Bus zum laufen bekommen?

In einem Test an einer Blue-Pill laufen beide Sensoren einzeln 
problemlos, jedoch wenn man diese parallel schaltet, schlägt die 
Initialisierung öfters fehl und es werden falsche Werte gelesen.
Zum Beispiel in einem Wohnraum:
1
AHT = 77.52 % 2.29 °C
2
BMP = 761.73 mBar 7.22 °C

Nun steht im Datenblatt tatsächlich drinn, das der AHT10 keine anderen 
Götter neben sich auf dem Bus zu dulden scheint (s. Screenshot S. 8)

Andererseits werden scheinbar Module verkauft, wo zumindest ein AHT20 
zusammen mit einem BMP280 betrieben wird:
http://embedded-things.blogspot.com/2021/02/test-aht20bmp280-temperature-humidity.html

Hat jemand bereits Erfahrungswerte dazu, bevor man viele (vergebliche) 
Stunden in die Analyse des I2C Bus investiert?

: Bearbeitet durch User
von Sobald (Gast)


Lesenswert?

Du solltest das Datenblatt anhängen.

Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht 
der Aussage unter Punkt 3.

von mitlesa (Gast)


Lesenswert?

Sobald schrieb:
> Das widerspricht der Aussage unter Punkt 3.

Oder es spricht für einen nicht ausgebesserten Design-Fehler.

von Wolfgang (Gast)


Lesenswert?

Sobald schrieb:
> Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht
> der Aussage unter Punkt 3.

Woran hast du das gesehen?

Im Datenblatt AHT20 steht davon nichts (Table 5, S.6)
https://www.evelta.com/content/datasheets/AHT20.pdf

von Sobald (Gast)


Lesenswert?

Wolfgang schrieb:
> Sobald schrieb:
>> Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht
>> der Aussage unter Punkt 3.
>
> Woran hast du das gesehen?
>
> Im Datenblatt AHT20 steht davon nichts (Table 5, S.6)
> https://www.evelta.com/content/datasheets/AHT20.pdf

Könnte es daran liegen, dass Du ein Datenblatt eines ATH20 angehängt 
hast, während der TO von einem ATH10 schreibt (siehe Eingangsbeitrag)?

von Wolfgang (Gast)


Lesenswert?

Sobald schrieb:
> Könnte es daran liegen, dass Du ein Datenblatt eines ATH20 angehängt
> hast, während der TO von einem ATH10 schreibt (siehe Eingangsbeitrag)?

Ja, könnte sein. Dann soll der TO mal das Datenblatt verlinken. Ein 
AHT20 ist kein AHT10, aber nach diesem User Guide sollte auch der AHT10 
ein normales I2C Interface besitzen.
https://www.handsontec.com/dataspecs/sensor/AHT10.pdf

von ...-. (Gast)


Lesenswert?


von Jobst Q. (joquis)


Lesenswert?


von Wolfgang (Gast)


Lesenswert?

...-. schrieb:
> https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf

Danke - merkwürdig das Asong beim AHT10 keine aktuelle Version auf der 
Web-Site verlinkt hat.

In dem Datenblatt gibt es zwar den Pin 1 mit Bezeichnung "ADR", aber der 
soll fest auf Gnd gelegt werden, ist also beim Betrieb des Sensors aus 
dem Spiel. Auch ist die gleiche I2C-Adresse wie für den AHT20 angegeben 
(0x38).

Karsten W. schrieb:
> Hat jemand bereits Erfahrungswerte dazu, bevor man viele (vergebliche)
> Stunden in die Analyse des I2C Bus investiert?

Dann wäre das jetzt eine gute Gelegenheit, um zu üben, damit es in 
Zukunft schneller geht ;-)
Erstmal hilft vielleicht schon ein Oszi. Wie groß sind deine Pull-Ups 
und mit welcher Spannung läuft dein I2C bzw. deine Sensoren?

von Wolfgang (Gast)


Lesenswert?

Jobst Q. schrieb:
> Notfalls nimmt man einen I2C- Multiplexer.

Was soll das den jetzt für ein Nebenschauplatz sein. Erstmal sollte man 
doch klären, was los ist und nicht gleich vor dem Problem Reißaus 
nehmen.

Beide Sensoren nennen ihre Schnittstelle I2C und die Adressen kommen 
sich nicht in die Quere (AHT10/20: 0x38, BMP280: 0x76 oder 0x77). 
Mehrere AHT10/20 auf einem Bus wird natürlich nichts, ist aber hier 
nicht das Thema.

von ...-. (Gast)


Lesenswert?

Im Datenblatt steht ausdrücklich

Only a single AHT10 can be connected to the I2C bus and no other I2C
devices can be connected

von Wolfgang (Gast)


Lesenswert?

...-. schrieb:
> Only a single AHT10 can be connected to the I2C bus and no other I2C
> devices can be connected

Dann ist das Datenblatt falsch.
  [ ] AHT10 ist kein I2C Device
  [ ] "and no other I2C devices can be connected" ist falsch

von Wolfgang (Gast)


Lesenswert?

Um zu verstehen, was dort los ist, müsste man eben mal auf den Bus 
gucken und das Thema nicht einfach in die Cloud auslagern.
Mit Serienwiderstände in den Busleitung sieht man auch noch, von wem ein 
(evtl. fehlerhafter) dominanter Pegel kommt.

von ...-. (Gast)


Lesenswert?

und 10k Pullup ist bei 3.3 Volt eh viel zu viel.

von Wolfgang (Gast)


Lesenswert?

...-. schrieb:
> und 10k Pullup ist bei 3.3 Volt eh viel zu viel.

Meine Glaskugel ist leider etwas getrübt, aber vielleicht hat auch 
einfach nur das Steckbrett Kontaktprobleme oder es fehlt eine 
Masseverbindung ;-)

von c-hater (Gast)


Lesenswert?

Wolfgang schrieb:

> Dann ist das Datenblatt falsch.
>   [ ] AHT10 ist kein I2C Device
>   [ ] "and no other I2C devices can be connected" ist falsch

So ist es.

Entweder es ist ein I2C-Device, dann muss es mit anderen I2C-Devices auf 
demselben Bus koexistieren können, solange jedes seine eigene Adresse 
hat. Das macht halt schließlich einen Bus aus. Oder es ist halt kein 
I2C-Device.

Also ist entweder das Device Schrott oder das Datenblatt. Oder beides...

Genauer kann man das halt nur mit einer Analyse der Bus-Kommunikation 
herausbekommen.

Ich persönlich würde darauf tippen, dass die Aussage "and no other I2C 
devices can be connected" falsch ist.

Das Problem steckt vermutlich hier:

> 5.1 Start sensor
> [...]
> After power-on, the sensor
> needs at most 20 milliseconds time SCL is high) to
> reach the idle state, ready to receive commands sent
> by the host (MCU).

Das muss vermutlich ergänzt werden durch die Aussage: "If the startup 
conditions are not satisfied (even due to accesses to concurrencing 
I2C-devices), the sensor will never reach it's idle state".

Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck. 
Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu 
beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp 
eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem 
I2C-Bus gequasselt wir, mit wem auch immer.

von Wolfgang (Gast)


Lesenswert?

c-hater schrieb:
> Das Problem steckt vermutlich hier: ...

Da der BMP280 auch Mist macht, würde es entweder bedeuten, dass der 
AHT10 in dem fehlerhaften Zustand blöd dazwischen quatscht oder der 
Fehler im Aufbau/Programm vom TO steckt.

Schade, dass er sich seit seinen einführenden Worten nicht mehr gemeldet 
hat und nichts zur Lösung SEINES Problems beiträgt.

von Karsten W. (lsmod)


Lesenswert?

So viele Antworten in der Abwesenheit - Danke!

mitlesa schrieb:
> Oder es spricht für einen nicht ausgebesserten Design-Fehler.

Das wäre dann eine einleuchtende Erklärung für ein chinesisches Produkt.


Wolfgang schrieb:
> Im Datenblatt AHT20 steht davon nichts (Table 5, S.6)
> https://www.evelta.com/content/datasheets/AHT20.pdf

Und hier anscheinend der Grund warum es einen AHT20 gibt.

Ärgerlich einen Satz AHT10 gekauft zu haben.
Wer geht schon beim Kauf davon aus, das ein I2C-Sensor ein Problem damit 
hat, wenn andere Teilnehmer auf dem Bus sind!


...-. schrieb:
> https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf

Ja genau - hier ist der Fund auf Seite 8.
Das Datenblatt ist Draft genauso wie das Produkt! :-(


Jobst Q. schrieb:
> Notfalls nimmt man einen I2C- Multiplexer.
> 
https://www.reichelt.de/entwicklerboards-platine-i2c-multiplexer-tca9548a-debo-i2c-multi2-p291436.html

Interessant was es nicht alles gibt!
Der STM32F103 hat noch einen zweiten I2C-Bus (auf Reserve), aber das ist 
ja eigentlich nicht der Sinn eines I2C Bus, wenn daran nur ein Slave 
betrieben werden kann.

: Bearbeitet durch User
von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Wolfgang schrieb:
> In dem Datenblatt gibt es zwar den Pin 1 mit Bezeichnung "ADR", aber der
> soll fest auf Gnd gelegt werden, ist also beim Betrieb des Sensors aus
> dem Spiel. Auch ist die gleiche I2C-Adresse wie für den AHT20 angegeben
> (0x38).

Korrekt - wenn man den AHT10 einzeln anschließt, dann wird dieser bei 
einem Scan des Bus auf 0x38 gefunden.

Der BMP380 entsprechend auf 0x76.

Einzeln werden dann schön korrekte Werte gelesen:
1
BMP = 1004.57 mBar 23.54 °C
2
BMP = 1004.52 mBar 23.46 °C
3
4
AHT = 51.66 % 24.57 °C
5
AHT = 51.44 % 24.41 °C

> Erstmal hilft vielleicht schon ein Oszi. Wie groß sind deine Pull-Ups
> und mit welcher Spannung läuft dein I2C bzw. deine Sensoren?

Das ist gerade in der Analyse ...

Die Pullup's sind diejenigen die auf den Sensor-Platinen als Standard 
bereits vorhanden sind.
Das müssten bei dem BMP280 10K sein und bei dem AHT10 4K7.
Im parallelen Betrieb beider Sensoren also 3,2K was vielleicht schon zu 
wenig ist?

Auf dem DHT10-Platinchen sind ein Spannungsregler und Pegelumsetzer mit 
drauf.


Wolfgang schrieb:
> Um zu verstehen, was dort los ist, müsste man eben mal auf den Bus
> gucken und das Thema nicht einfach in die Cloud auslagern.
> Mit Serienwiderstände in den Busleitung sieht man auch noch, von wem ein
> (evtl. fehlerhafter) dominanter Pegel kommt.

Interessanter Tip - Danke!


Wolfgang schrieb:
> Meine Glaskugel ist leider etwas getrübt, aber vielleicht hat auch
> einfach nur das Steckbrett Kontaktprobleme oder es fehlt eine
> Masseverbindung ;-)

Das ist schon ein Aufbau mit richtigen Platinen und Pin-Headern, wo die 
Platinen aufgesteckt sind.

: Bearbeitet durch User
von Karsten W. (lsmod)


Lesenswert?

c-hater schrieb:

> Das Problem steckt vermutlich hier:
>
>> 5.1 Start sensor
>> [...]
>> After power-on, the sensor
>> needs at most 20 milliseconds time SCL is high) to
>> reach the idle state, ready to receive commands sent
>> by the host (MCU).
>
> Das muss vermutlich ergänzt werden durch die Aussage: "If the startup
> conditions are not satisfied (even due to accesses to concurrencing
> I2C-devices), the sensor will never reach it's idle state".
>
> Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck.
> Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu
> beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp
> eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem
> I2C-Bus gequasselt wir, mit wem auch immer.

Gute Idee - die Wartezeit ist schnell im Code integriert!

Aber erst einmal kurz ein Oszi drann.


Wolfgang schrieb:
> Schade, dass er sich seit seinen einführenden Worten nicht mehr gemeldet
> hat und nichts zur Lösung SEINES Problems beiträgt.

Hehehe - so ist das manchmal am Wochenende - da planen andere die Zeit 
einfach weg ...
Hatte auch sein Gutes, denn nun kann mit jede Menge Ideen fortgefahren 
werden. :-)

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Die Pullup's sind diejenigen die auf den Sensor-Platinen als Standard
> bereits vorhanden sind.
> Das müssten bei dem BMP280 10K sein und bei dem AHT10 4K7.
> Im parallelen Betrieb beider Sensoren also 3,2K was vielleicht schon zu
> wenig ist?

Was ist denn das für eine eigenwillige Konfiguration?
An jede Busleitung gehört normalerweise ein einziger Pull-Up. Sonst 
bricht der Bus zusammen, wenn man plötzlich mal auf die Idee kommt, 10 
Module drauf zu hängen, aber sei´s drum. Zu wenig sind die 3.2kΩ 
bestimmt nicht. Im Datenblatt des AHT10 ist ein Maximalstrom von 10mA 
angegeben. Da liegst du einen Faktor 10 drunter - also alles gut. 1mA 
sollte eigentlich ok sein.

Mit welchem Clock lässt du den I2C laufen?

Guck dir die Signale (Signalform, Ack, Dateninhalte, Startzeit) und dein 
Programm an.

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Auf dem DHT10-Platinchen sind ein Spannungsregler und Pegelumsetzer mit
> drauf.

Ich blicke durch deine Schaltplanfragmente gerade nicht ganz durch. Was 
ist mit den jeweils 4.7kΩ auf den Pegelwandlern. Ziehen die den Bus 
nicht auch hoch?

von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

So - hier die Oszi-Messungen:

Der Bus läuft mit 100 KHz und die Pegel sehen eigentlich immer sauber 
aus.

Aber - wenn beide Sensoren angeschlossen sind ist es mir nur einmal 
gelungen, auf SDA etwas nach einem Reset per Trigger aufzuzeichnen!

Wenn die Sensoren ausgelesen werden, triggert nichts mehr, weder auf SCL 
noch auf SDA!

von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Wolfgang schrieb:
> Ich blicke durch deine Schaltplanfragmente gerade nicht ganz durch. Was
> ist mit den jeweils 4.7kΩ auf den Pegelwandlern. Ziehen die den Bus
> nicht auch hoch?

Tssss - warum denn nicht - sind doch nur die üblichen China-Schaltpläne! 
:-)

So wie dieser BME280, der in Wirklichkeit immer nur ein BMP280 ist 
(rechtes Platinchen im Bild).
Die Pullup-Widerstände sind dort im Schaltbild gar nicht dargestellt.

Zu Deiner Frage: Wie bereits geschrieben wurden jeweils Module 
verwendet, weil die kleinen Mistdinger von Sensoren sonst kaum 
kontaktiert werden können.

Wenn es an den Pullup-Widerständen liegt, könnte man ja noch ein paar 
einfach auslöten.

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Aber - wenn beide Sensoren angeschlossen sind ist es mir nur einmal
> gelungen, auf SDA etwas nach einem Reset per Trigger aufzuzeichnen!

Dann lass deinen µC auf irgendeinem GPIO ein Signal ausgeben, dass du 
auf den Externen Trigger vom Welec geben kannst und dann zeichne mit 
Single Shot auf.
Damit die Zeitzusammenhänge klar werden, solltest du SCL und SDA 
parallel messen - wozu hat das Oszi mehrere Kanäle.
Die Signalqualität, insbesondere Flankenlage und -steilheit lassen sich 
bei höherer Zeitauflösung besser beurteilen, auch wenn man dann nicht 
das ganze Signal drauf hat.

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Wenn es an den Pullup-Widerständen liegt, könnte man ja noch ein paar
> einfach auslöten.

Solange der Gesamtwiderstand nicht unter 1.5kΩ ist, brauchst du bestimmt 
nicht dranrum zu löten. Bei zu kleinem Widerstand würde in deinen 
Signalen evtl. der L-Pegel ansteigen, aber der sieht gut aus.

von I2C (Gast)


Angehängte Dateien:

Lesenswert?

Karsten W. schrieb:
> Der Bus läuft mit 100 KHz und die Pegel sehen eigentlich immer sauber
> aus.

Und was ist DAS hier ... ???

von Wolfgang (Gast)


Lesenswert?

I2C schrieb:
> Und was ist DAS hier ... ???

Das ist wohl eine kleine Lücke zwischen Signal vom Master und dem Signal 
vom Slave. Entscheidend ist, wie dir Flanken vom SCL dazu liegen.

von Wolfgang (Gast)


Lesenswert?

p.s.
Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was 
von wem kommt

von I2C (Gast)


Lesenswert?

Wolfgang schrieb:
> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was
> von wem kommt

Das kommt vom AHT10, siehe Grafik weiter oben. Bei einem I2C-Bus habe 
ich das noch nie gesehen.

von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Sobald schrieb:
> Du solltest das Datenblatt anhängen.
>
> Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht
> der Aussage unter Punkt 3.

Der Download-Link wurde oben schon genannt.
https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf

Hier noch einmal als Upload.


Weitere Tests leider erst morgen, da erneut ein Zeitraub vorliegt ...

von Karsten W. (lsmod)


Lesenswert?

I2C schrieb:
> Karsten W. schrieb:
>> Der Bus läuft mit 100 KHz und die Pegel sehen eigentlich immer sauber
>> aus.
>
> Und was ist DAS hier ... ???

Gute Frage - könnte ein Sampling-Fehler sein oder ein Glitch.
Müsste ich noch Mal genauer wiederholen und auflösen.


Wolfgang schrieb:
> Das ist wohl eine kleine Lücke zwischen Signal vom Master und dem Signal
> vom Slave. Entscheidend ist, wie dir Flanken vom SCL dazu liegen.

Bei einer Wiederholung müsste also direkt mit 2 Kanälen gearbeitet 
werden.


Wolfgang schrieb:
> p.s.
> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was
> von wem kommt

Nicht unbedingt, weil der Trigger irgendwie nicht geklappt hat.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Wolfgang schrieb:
>> p.s.
>> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was
>> von wem kommt
>
> Nicht unbedingt, weil der Trigger irgendwie nicht geklappt hat.

Doch, jeder Slave hängt über ein eigenen Serienwiderstand am Bus. Dann 
kann man mit einer Messung alles sehen.
Wenn die Widerstände unterschiedlich sind, erkennt man am Pegel auf dem 
Bus, wer ihn runter zieht. Die Widerstände müssen so gewählt werden, 
dass der L-Pegel auf dem Bus trotzdem noch sicher erreicht wird.

von Karsten W. (lsmod)


Lesenswert?

c-hater schrieb:
> Das Problem steckt vermutlich hier:
>
>> 5.1 Start sensor
>> [...]
>> After power-on, the sensor
>> needs at most 20 milliseconds time SCL is high) to
>> reach the idle state, ready to receive commands sent
>> by the host (MCU).
>
> Das muss vermutlich ergänzt werden durch die Aussage: "If the startup
> conditions are not satisfied (even due to accesses to concurrencing
> I2C-devices), the sensor will never reach it's idle state".
>
> Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck.
> Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu
> beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp
> eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem
> I2C-Bus gequasselt wir, mit wem auch immer.

Der I2C Bus wurde ohnehin erst nach 2 Sekunden mit Wire.begin() 
initialisiert, weil zuvor noch eine Startmeldung auf einem LCD 
ausgegeben wird.

Sicherheitshalber wird nun direkt nach dem Start SCL als Output 
geschaltet und auf High gelegt, aber dies hat leider keine Änderung 
erbracht.

von Karsten W. (lsmod)


Lesenswert?

Wolfgang schrieb:
> Doch, jeder Slave hängt über ein eigenen Serienwiderstand am Bus. Dann
> kann man mit einer Messung alles sehen.
> Wenn die Widerstände unterschiedlich sind, erkennt man am Pegel auf dem
> Bus, wer ihn runter zieht. Die Widerstände müssen so gewählt werden,
> dass der L-Pegel auf dem Bus trotzdem noch sicher erreicht wird.

Gibt es einen konkreten Vorschlag für passende Widerstände?

von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Ein paar neue Messungen mit 2 Kanälen.

Wenn beide Sensoren angeschlossen sind passiert auf dem I2C-Bus nach dem 
Power-On und der Initialisierung nichts mehr.
Offensichtlich läuft hier nur noch die Initialisierung des AHT10, welche 
im Code zuerst stattfindet.
Interessanterweise gibt die Initialisierung des BMP280 keine 
Fehlermeldung zurück.

Die Messwerte die von den Leseroutinen geliefert werden sind daher 
Unsinn - diesbezüglich müsste der Code geprüft werden.

: Bearbeitet durch User
von Karsten W. (lsmod)


Lesenswert?

Die Software wurde nun dahingehend geändert, daß vor jeder einzelner 
Abfrage komplett der I2C-Bus und der jeweilige Sensor neu initialisiert 
wird.
Im Ergebnis schlägt die Initialisierung der Sensoren fehl, sobald beide 
Sensoren am Bus angeschlossen sind.
Einzeln funktioniert dies wunderbar.

Somit ist die Aussage des Datenblatt vom AHT10 korrekt, daß nur ein 
AHT10 an einem I2C-Bus angeschlossen sein kann.
Dieser Sensor ist als I2C-Device einfach nur Müll!

Eine weitere Analyse von chinesischem Design-Müll hilft hier daher nicht 
weiter.
Man muß also einen AHT20 kaufen, wenn weitere Sensoren am gleichen Bus 
betrieben werden sollen.

Hier ist übrigens der Kombisensor mit AHT20:
https://www.aliexpress.com/item/1005003128566196.html

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Sicherheitshalber wird nun direkt nach dem Start SCL als Output
> geschaltet und auf High gelegt, aber dies hat leider keine Änderung
> erbracht.

SCL als Output zu schalten und auf High zu legen, kann bei einer 
Push-Pull Ausgangsstufe ziemlich ins Auge gehen. Ein I2C-Slave, der aus 
irgendeinem Grund die Busleitung auf Low ziehen will (z.B. Clock 
stretching), beißt sich daran die Zähne aus und macht (im Rahmen seiner 
Möglichkeiten) einen KURZSCHLUSS. Beim I2C ist für den High-Zustand der 
Bus-Leitungen einzig und alleine der Pull-Up Widerstand zuständig.

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Im Ergebnis schlägt die Initialisierung der Sensoren fehl, sobald beide
> Sensoren am Bus angeschlossen sind.
> Einzeln funktioniert dies wunderbar.
>
> Somit ist die Aussage des Datenblatt vom AHT10 korrekt, daß nur ein
> AHT10 an einem I2C-Bus angeschlossen sein kann.

So weit warst du auch schon in deinem ersten Post.
Guck auf dem Bus nach, was bei der Initialisierung genau anders/schief 
läuft, wenn du beide Sensoren dran hast. Nimm z.B. das lauffähige 
Programm vom AHT10 und hänge dann den BMP280 zusätzlich mit auf den Bus, 
ohne etwas am Code zu ändern.
Hast du einen Logikanalysator, der die Busaktivität etwas 
übersichtlicher aufschlüsselt?

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Gibt es einen konkreten Vorschlag für passende Widerstände?

In den Datenblättern steht der maximal zulässig Low-Pegel. Und der Rest 
ist jeweils ein einfacher Spannungsteiler, bestehend aus den Pull-Ups 
und dem Serienwiderstand.
Wenn selber rechnen zu mühselig ist, probier's aus. Bei Serienwiderstand 
0 siehst du auf dem Oszi keinen Unterschied, bei zu hohem 
Serienwiderstand steigt der L-Pegel auf der Bus-Leitung zu weit an und 
der Empfänger kann die Daten nicht mehr lesen.

von Karsten W. (lsmod)


Lesenswert?

Wolfgang schrieb:
> So weit warst du auch schon in deinem ersten Post.

Stimmt. Aber man durfte ja hoffen das es doch noch eine Lösung gibt.

> Guck auf dem Bus nach, was bei der Initialisierung genau anders/schief
> läuft, wenn du beide Sensoren dran hast. Nimm z.B. das lauffähige
> Programm vom AHT10 und hänge dann den BMP280 zusätzlich mit auf den Bus,
> ohne etwas am Code zu ändern.

Nun - dann kann man auch direkt einen Pin von einem Port benutzen, um 
wahlweise die Versorgungsspannung von einer der beiden Sensoren 
aufzuschalten.

> Hast du einen Logikanalysator, der die Busaktivität etwas
> übersichtlicher aufschlüsselt?

Ja - so einen China-Adapter, der scheinbar bei 3V3-Pegeln keine 
brauchbaren Pegel erkennt.
Daher nur das Oszi.

von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Nun - dann kann man auch direkt einen Pin von einem Port benutzen, ...

Willst du verstehen, was los ist oder willst du nur irgendwie die Daten 
lesen?
Wenn du einem Sensor die Versorgung abschaltest und ihn trotzdem auf dem 
Bus lässt, wird der Sensor lt. Datenblatt anscheinend über den Bus 
versorgt  (parasitäre Versorgung über ESD Schutzdioden) - keine gute 
Idee.

> Ja - so einen China-Adapter, der scheinbar bei 3V3-Pegeln keine
> brauchbaren Pegel erkennt.

Da habe ich andere Erfahrung, aber es mag verschiedene geben.
Du hast doch die I2C Pegelwandler. Da könntest du dich notfalls mit dem 
LA auf die 5V-Seite setzen.

Karsten W. schrieb:
> AHT10-schematic.jpg

von Karsten W. (lsmod)


Lesenswert?

Wolfgang schrieb:
> Wenn selber rechnen zu mühselig ist, probier's aus. Bei Serienwiderstand
> 0 siehst du auf dem Oszi keinen Unterschied, bei zu hohem
> Serienwiderstand steigt der L-Pegel auf der Bus-Leitung zu weit an und
> der Empfänger kann die Daten nicht mehr lesen.

Es ist leider nur Zeitverschwendung die Design-Fehler einer chinesischen 
Firma zu analysieren.
Fest steht das der I2C-Bus nicht mehr läuft, sobald ein AHT10 zusätzlich 
angeschlossen ist.

Nun kann man nur noch einen weiteren I2C-Bus, oder wie bereits 
vorgeschlagen einen TCA9548A verwenden, oder die Versorgungsspannung der 
Sensoren schalten.
Die beste Lösung jedoch ist einen AHT10 nicht zu verwenden, wenn der 
I2C-Bus noch für andere Clients zur Verfügung stehen soll.

von Karsten W. (lsmod)


Lesenswert?

Wolfgang schrieb:
> Karsten W. schrieb:
>> Nun - dann kann man auch direkt einen Pin von einem Port benutzen, ...
>
> Willst du verstehen, was los ist oder willst du nur irgendwie die Daten
> lesen?

Die Verwendung von Sensoren hat im allgemeinen das Ziel damit Daten zu 
erfassen und nicht Fehler zu analysieren, warum diese nicht 
funktionieren. :-)
Chinesischer Schrott sollte auf jeden Fall keine schlaflosen Nächte 
bereiten.

> Wenn du einem Sensor die Versorgung abschaltest und ihn trotzdem auf dem
> Bus lässt, wird der Sensor lt. Datenblatt anscheinend über den Bus
> versorgt  (parasitäre Versorgung über ESD Schutzdioden) - keine gute
> Idee.

Gutes Argument - also streichen wir diese Möglichkeit.
Diese wäre ohnehin keine elegante Lösung.

> Da habe ich andere Erfahrung, aber es mag verschiedene geben.

Kann sein - die Analyse dieses Problems führt zur Zeit leider ebenfalls 
zu keiner neuen Lösung und motiviert daher nicht.

> Da habe ich andere Erfahrung, aber es mag verschiedene geben.
> Du hast doch die I2C Pegelwandler. Da könntest du dich notfalls mit dem
> LA auf die 5V-Seite setzen.

Nein - weil alles auf 3,3V Pegeln arbeitet.

Dennoch Danke für Eure Gedanken und Unterstützung.
Oftmals ist es einfach nur so, daß man etwas Triviales übersehen hat.

In jedem Fall wurde in diesem Thread dokumentiert, wann der Kauf eines 
AHT10 nicht sinnvoll ist.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Nein - weil alles auf 3,3V Pegeln arbeitet.

Wozu ist dann der Pegelwandler da?
Manche Dinge muss man nicht verstehen ...

von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Wolfgang schrieb:
> Karsten W. schrieb:
>> Nein - weil alles auf 3,3V Pegeln arbeitet.
>
> Wozu ist dann der Pegelwandler da?
> Manche Dinge muss man nicht verstehen ...

Weil dieser auf einem AHT10 Breakout nun Mal immer mit drauf ist.
Schließlich arbeitet der überwiegende Teil bei Arduino mit 5V Atmel und 
da ist dies von Vorteil.
Im Einzelbetrieb stört dieser Pegelwandler ja anscheinend bei 3,3V 
nicht.

In dem Bild sieht man sogar das Innenleben eines AHT10.

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Karsten W. schrieb:
> Schließlich arbeitet der überwiegende Teil bei Arduino mit 5V Atmel und
> da ist dies von Vorteil.

Das könntest du auch tun und hättest dann keine Probleme mit dem Pegel 
für den LA. Den BMP280 würde man dann auf der 3.3V-Seite mit auf den Bus 
hängen, falls du einen Lötkolben besitzt, um ein paar Drähte an die 
3.3V-Pull-Ups zu löten.

Hast du denn jetzt heraus bekommen, was sich an den Signalen auf dem Bus 
ändert, wenn man beim funktionierenden AHT10-Aufbau den BMP280 mit auf 
den Bus hängt?

Karsten W. schrieb:
> AHT10-glitch.png

Das was du als Glitch bezeichnest, ist die Reaktionszeit des Sensors. 
Die Daten kommen vom µC und das ACK müsste vom Sensor kommen. Hältst du 
die Setup- und die Hold Zeit auf dem Bus ein - auch nach dem 
Pegelwandler (falls der bei deinem aktuellen Aufbau im Signalweg sitzt)?
Auf deinen Oszi-Bilder reicht die Zeitauflösung leider nicht, um das zu 
verifizieren. Vergleiche einfach mit den I2C-Zeitdiagrammen in den 
Datenblättern.

Aber egal, du wirst schon eine Lösung finden oder es mit anderen 
Komponenten probieren. Viel Erfolg

von Karsten W. (lsmod)


Lesenswert?

Wolfgang schrieb:
> Das könntest du auch tun und hättest dann keine Probleme mit dem Pegel
> für den LA. Den BMP280 würde man dann auf der 3.3V-Seite mit auf den Bus
> hängen, falls du einen Lötkolben besitzt, um ein paar Drähte an die
> 3.3V-Pull-Ups zu löten.

Das Breakout für den BMP280 hat keinen Pegelwandler mit drauf.
Deshalb harmoniert dieses sehr schön mit einer Blue-Pill.

> Hast du denn jetzt heraus bekommen, was sich an den Signalen auf dem Bus
> ändert, wenn man beim funktionierenden AHT10-Aufbau den BMP280 mit auf
> den Bus hängt?

Nein - leider habe ich wie gesagt die Lust verloren.
Es werden nur chinesische Probleme analysiert, die dann trotzdem nicht 
abgestellt werden können.

> Karsten W. schrieb:
> Das was du als Glitch bezeichnest, ist die Reaktionszeit des Sensors.
> Die Daten kommen vom µC und das ACK müsste vom Sensor kommen. Hältst du
> die Setup- und die Hold Zeit auf dem Bus ein - auch nach dem
> Pegelwandler (falls der bei deinem aktuellen Aufbau im Signalweg sitzt)?

Es wird über #include <Wire.h> der Hardware-I2C vom STM32F103 benutzt.
Wohlwollend will ich davon ausgehen das dieser ein korrektes Timing hat.
Da es schwer ist im Detail den I2C durch den HAL bei einem ARM 
nachzuverfolgen, kann es sein das hier der Bus bei Fehlern automatisch 
deaktiviert wird.
Das würde zumindest erklären, warum weder SCL noch SDA zu messen ist, 
wenn beide Sensoren angeschlossen sind.

> Auf deinen Oszi-Bilder reicht die Zeitauflösung leider nicht, um das zu
> verifizieren. Vergleiche einfach mit den I2C-Zeitdiagrammen in den
> Datenblättern.

Dieser Ehrgeiz besteht zur Zeit nicht.

> Aber egal, du wirst schon eine Lösung finden oder es mit anderen
> Komponenten probieren. Viel Erfolg

Ja Danke - gerade wird der AHT10 auf die zweite Hardware I2C vom 
Controller gelötet.

: Bearbeitet durch User
von Karsten W. (lsmod)


Angehängte Dateien:

Lesenswert?

Abschließend soll hier noch eine funktionierende Lösung für das Problem 
mit dem blockierten I2C-Bus weitergegeben werden.
Sowohl für die Nutzung der zweiten I2C-Schnittstelle als auch für eine 
Software-I2C muß die Library für den AHT10 angepasst werden.

Da die Pins für die zweite I2C bereits belegt waren, wurde auf die 
Software-I2C https://github.com/felias-fogg/SlowSoftI2CMaster 
zurückgegriffen, da diese mit STM32Duino verwendet werden kann.
Die AHT-10 Library basiert auf https://github.com/enjoyneering/AHT10

Mit dieser Lösung können beliebige 2 Port-Pins verwendet werden, um 
einen AHT10 auszulesen.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.