ich lese an einem Raspberry Pi einen BMP280 regelmäßig aus, der ab und
zu falsche Messwerte liefert. Immerhin liefert er dann zwar falsche,
aber immerhin welche. Am I2C Bus hängt auch ein HTU21 der aber permanent
richtige Werte liefert.
gestartet wird das Skript regelmäßig mit Cronjob, Weiterleitung an
OpenHab mit MQTT
code habe ich von
http://www.netzmafia.de/skripten/hardware/RasPi/Projekt-BMP280/index.html
benutzt, in Python
ab und an springt der Wert des Drucks in einen sehr kleinen Bereich,
dies habe ich mit provisorisch abgefangen:
Sebastian K. schrieb:> jemand eine Idee was das sein kann?
Rohdaten für die Temperatur falsch oder Rechenfehler
Prüfe mal, ob die Druckwerte ok sind, wenn du mit dem richtigen
Temperaturwert rechnest.
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.
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.
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.
Sebastian K. schrieb:> werde mal ein Oszi besorgen
Gibt doch erstmal die empfangenen Rohdaten vor der Berechnung aus und
schaue, ob es da Auffälligkeiten gibt.
Andere Möglichkeiten wären:
- Du fragst zu schnell ab und der Sensor antwortet nicht immer: Alle
Bits auf 1.
- Das Acknowledge wird nicht richtig ausgewertet.
- Bestimmte Werte erzeugen einen Fehler in der Berechnung.
Die Berechnung der Bosch-Sensoren ist nicht trivial. Ich hab schon zu
viel Mist in diversen Libs gesehen, als dass ich ihnen blind trauen
würde.
Sebastian K. schrieb:> ich weiß, ist nicht das beheben> der Ursache
Bei I2C kann es das schon sein. Da spielt das Timing nunmal eine große
Rolle. Es kann bereits Fehler geben, wenn SCL und SDA unterschiedliche
Leitungskapazitäten haben - zum Beispiel wenn an nur einer der Leitungen
ein Tastkopf hängt.
Karl schrieb:> Andere Möglichkeiten wären:> ...........> ...........
... und Hardware Fehler durch schlechten Aufbau kommen
natürlich auf keinen Fall in Frage!
Und überhaupt .... was die Hardware nicht kann wird mit
Software-Fakes kompensiert.
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
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.
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
)
Sebastian K. schrieb:> Wieso geht für das nächste Bit die Spannung dann ins> negative (Messfehler?)?
Fehler im Aufbau, Oszi falsch eingestellt/angeschlossen.
Wie sieht dein Schaltplan aus?
Der I2C-Pegel muss sich zwischen 0 und 3.3V abspielen. Woher soll eine
negative Spannung kommen?
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
M. K. schrieb:> Also die Flanken sehen IMO scheiße aus ...
Hast du dich überhaupt schon mal mit I2C beschäftigt und verstanden, wie
der Bus funktioniert, damit du dir so ein Urteil erlauben kannst?
Sebastian K. schrieb:> so, jetzt noch mal...
Das sieht doch viel besser aus ;-)
Woran lag das (nur so interessehalber)?
Jetzt müsstest du mal auf einen Ausreißer triggern und dazu die am
Raspberry angekommenen Rohdaten zusammen mit dem daraus abgeleiteten
Anzeigewert anzeigen.
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 ;-)
Thread beobachten
Seitenaufteilung abschalten