BMP280 am I2C Bus sporadisch falsche Werte

Wenn die Datenübertragung nicht CRC gesichert ist, dann kann es sein 
dass Bits kippen. entweder mehrfach auslesen oder die Kabel besser 
schirmen.

Benjamin S. schrieb:
> Wenn die Datenübertragung nicht CRC gesichert ist, dann kann es sein
> dass Bits kippen. entweder mehrfach auslesen oder die Kabel besser
> schirmen.

Japp, würde auch auf kippende Bits tippen.

Wolfgang schrieb:
> M. K. schrieb:
>> Japp, würde auch auf kippende Bits tippen.
>
> Auch dafür müsste man einen Blick auf die Rohdaten oder besser gleich
> mit Oszi und LA auf die Signale am I2C-Bus werfen.

Ich würd erstmal fragen: Wie groß sind die Pull-Ups aber auch die 
Signalform allgemein könnte interessant sein um zu sehen, ob die 
Pull-Ups zumindest die passende Größe haben.

vielen Dank für den schnellen Feedback! Dann habe ich erstmal zu tun :-)

ich habe einfach die Standard Breakout boards benutzt, die es überall zu 
kaufen gibt, werde mal ein Oszi besorgen, Zeichnung anhand der 
Datenblätter zur Übersicht erstellen.

Eventuell die Pullups von einem Breakoutboard ablöten? Kann man die 
Frequenz vom I2C Bus runter setzen? Ja, ich weiß, ist nicht das beheben 
der Ursache, aber geht vielleicht auch erst einmal

wie kann ich die denn bei I2C per CRC überprüfen?

Sebastian K. schrieb:
> Eventuell die Pullups von einem Breakoutboard ablöten? Kann man die
> Frequenz vom I2C Bus runter setzen? Ja, ich weiß, ist nicht das beheben
> der Ursache, aber geht vielleicht auch erst einmal

Mit welcher Frequenz fährst du denn? Zwei sollten mindestens möglich 
sein, 100 kHz für Standard und 400 kHz für Fast. Wenn du mit 400 kHz am 
Start bist kannst du mal versuchen auf 100 kHz runter zu gehen.

M. K. schrieb:
> Mit welcher Frequenz fährst du denn? Zwei sollten mindestens möglich
> sein, 100 kHz für Standard und 400 kHz für Fast. Wenn du mit 400 kHz am
> Start bist kannst du mal versuchen auf 100 kHz runter zu gehen.

in der /boot/config.txt steht nichts, also 100kHz?? gibt es einen Befehl 
die aktuelle aktive Bautrate auszulesen?

ansonsten mache ich mich an die Arbeit die Hardware anzugucken, kann ein 
bisschen dauern, ist ja Hobby

Wie das genau beim Raspberry geht weiß ich leider auch nicht aber ich 
gehe auch davon aus, dass er default-mäßig auf 100 kHz steht.

Hast du den Hinweis im Datenblatt berücksichtigt die Daten in einem 
Rutsch auszulesen, damit du keine Sensorwerte von verschiedenen 
Messvorgängen gemischt bekommst?

Kapitel 4 und 4.1

Würde deinen Fehler genau beschreiben, wenn du im "Normal mode" einfach 
regelmäßig die Werte durch mehrere Byte-Weise Lesevorgänge ausliest. 
Dann trifft manchmal genau der Update-Zeitpunkt zwischen deine 
Lesevorgänge und du erhällst Unsinn.

Tim S. schrieb:
> Hast du den Hinweis im Datenblatt berücksichtigt die Daten in einem
> Rutsch auszulesen, damit du keine Sensorwerte von verschiedenen
> Messvorgängen gemischt bekommst?
>
> Kapitel 4 und 4.1
>
> Würde deinen Fehler genau beschreiben, wenn du im "Normal mode" einfach
> regelmäßig die Werte durch mehrere Byte-Weise Lesevorgänge ausliest.
> Dann trifft manchmal genau der Update-Zeitpunkt zwischen deine
> Lesevorgänge und du erhällst Unsinn.

Im Eröffnungspost hat er den Link zum Script gepostet, dass er zum 
Auslesen benutzt. Das liest die Daten (24 Byte, also Sensorwerte incl. 
Kalibrierwerte) in einem Rutsch, daher dürfte genau das nicht sein 
Fehler sein es sei denn er hat das Script verändert und davon noch 
nichts gesagt, das wäre natürlich blöd.

Danke, den hatte ich nicht gesehen.

laut scope sind es eindeutig 100kHz. gemessen an SCK zu GND

sind das die "kippenden Bits"? Die Spannung geht nur verhältnismäßig 
langsam runter. Wieso geht für das nächste Bit die Spannung dann ins 
negative (Messfehler?)?

Liegt das an der Kapazität der Leitung? Die sind ca. 10cm lang. 
ansonsten sind da noch Cs von VDD zu GND ( 
https://www.electroschematics.com/wp-content/uploads/2017/09/3-BMP280-Module_Schematic-400x212.jpg 
)

Wolfgang schrieb:
> Fehler im Aufbau, Oszi falsch eingestellt/angeschlossen.
> ...
> Der I2C-Pegel muss sich zwischen 0 und 3.3V abspielen. Woher soll eine
> negative Spannung kommen?

so, jetzt noch mal...

Wolfgang schrieb:
> Wie sieht dein Schaltplan aus?

sind einfach zwei Standardboard zusammengeschlossen, kann eine Skizze 
erstellen bei Bedarf

Sebastian K. schrieb:
> sind einfach zwei Standardboard zusammengeschlossen, kann eine Skizze
> erstellen bei Bedarf

Also die Flanken sehen IMO scheiße aus und diese komischen Spikes aus. 
Ne Skizze wäre echt spannend. Auf jeden Fall müssen bei 2 Boards die 
Pull-Ups angepasst werden.

M. K. schrieb:
> Also die Flanken sehen IMO scheiße aus
Die Flanken sehen für I²C völlig normal aus. Die I²C Signale werden nur 
durch die PullUp Widerstände gegen Vcc gezogen und vom Master/Slave via 
Open-Drain gegen GND. Darum ist die fallende Flanke steiler als die 
steigende weil diese aktiv gegen GND gezogen wird. Darum muss man bei 
höherem I²C Clock auch irgendwann die Pullups verkleinern

Timmo H. schrieb:
> M. K. schrieb:
>> Also die Flanken sehen IMO scheiße aus
> Die Flanken sehen für I²C völlig normal aus. Die I²C Signale werden nur
> durch die PullUp Widerstände gegen Vcc gezogen und vom Master/Slave via
> Open-Drain gegen GND. Darum ist die fallende Flanke steiler als die
> steigende weil diese aktiv gegen GND gezogen wird. Darum muss man bei
> höherem I²C Clock auch irgendwann die Pullups verkleinern

Ich meine da, wo er zwei Module dran hatte, also bei den Bildern von 
12:36 Uhr. Da sieht das Signal auch für i2c scheiße aus. Wenn das so 
verschliffen ist wundert es mich nicht wenn ihm hin und wieder Werte 
durch die Lappen gehen.

Wolfgang schrieb:
> Das sieht doch viel besser aus ;-)
> Woran lag das (nur so interessehalber)?

Kopplung stand auf AC, Tastkopf auf 1x gestellt, Voreinstellung war noch 
auf 10x gestellt... Klassiker würde ich sagen ;-)