BME250 i2c Fehler beim Auslesen

  • Moinsens!

    Ich hab letztens als "Bonscher" bei einer Bestellung zusätzlich 2x den BME250 (blueberry) zugeschickt bekommen. Das ist ein kleines Breakout-Board mit 6 Pins. Wenn ich es richtig verstanden habe, dann sollte ich mit folgender Verkabelung hinkommen:
    1 (GND) mit schwarz an Pin 6 des RasPi
    4 (SDI/SDA) mit blau an Pin 3
    5 (SCK/SCL) mit gelb an Pin 5
    6 (3V3) mit rot an Pin 1

    Im Gegensatz zu anderen Modulen mit diesem Sensor unterscheidet sich dieser hier:
    a) Adresse ist 0x76 (sonst üblich wohl eher 0x77)
    b) ausdrücklich nur 3,3V (sonst üblich wohl 3,3 bis 5V)

    i2cdetect findet das Modul, ein Python-Script zum Auslesen der Sensor-Werte schmiert aber weg:

    (Nicht durch den Prompt verwirren lassen: Das ist kein RasPi3, sondern nur mein 3. RasPi.)

    Das komplette Script habe ich aus dem Beitrag auf der Seite
    http://www.raspberrypi-spy.co.uk/2016/07/using-…nsor-in-python/
    per

    Code
    wget -O bme280.py http://bit.ly/bme280py


    geholt.

    Mein Problem jetzt: Ich weiß nicht so recht, wo ich jetzt ansetzen soll, den Fehler zu beheben. Die Verkabelung scheint ja ok zu sein, wenn i2cdetect das Dng findet, oder? Und die Adresse 0x76 im Script ist das Einzige, was anzupassen wäre.

    Kann mir hier jemand helfen?

    Gruß, Michael

  • Hallo zu später Stunde.
    Kommentiere doch in main einfach mal deie Stelle aus. Sollte dann so aussehen


    Ich kenne mich mit python nicht aus, aber es scheint mir als würde da versucht zwei Bytes aus einem Register zu lesen.

  • Kommentiere doch in main einfach mal deie Stelle aus.

    Naja, damit verlager ich das Problem nur auf die nächste Zeile:

    Code
    pi@raspi3:~/python/sensors/bme280 $ python bme280.py
    Traceback (most recent call last):
      File "bme280.py", line 163, in <module>
        main()
      File "bme280.py", line 156, in main
        temperature,pressure,humidity = readBME280All()
      File "bme280.py", line 74, in readBME280All
        bus.write_byte_data(addr, REG_CONTROL, control)
    IOError: [Errno 5] Input/output error

    Gruß, Michael

  • Hi fred,

    Code
    i2cdetect -y 1 0x76


    ich denke, da hast Du den typischen Fehler nach dem Motto "das richtige gedacht aber das falsche geschrieben" reinbekommen.
    Das sollte imho doch eher

    Code
    pi@pi-zero:~ $ i2cget -y 1 0x76


    heissen ;)

    cu,
    -ds-

  • Funktioniert denn das auslesen überhaupt ?

    Code
    i2cget -y 1 0x76

    Hmmm... Weiß nicht, ob das "gehen" ist:

    Code
    pi@raspi3:~/python/sensors/bme280 $ i2cget -y 1 0x76
    0x00

    Es kommt keine Fehlermeldung, aber ich hab bislang auch nur 0x00 als Wert gesehen.

    Gruß, Michael

  • Versuche es mal mit

    Code
    i2cdump -y 1 0x76


    Da sollten alle Register ausgelesen werden und zumindest das ChipID Register sollte dann 0x60 sein. Drei weitere Register sollten 0x80 sein. Ich kann morgen auch noch ein kleines C Porgramm zum kompilieren und testen hochladen.

  • Versuche es mal mit

    Code
    i2cdump -y 1 0x76


    Da sollten alle Register ausgelesen werden und zumindest das ChipID Register sollte dann 0x60 sein. Drei weitere Register sollten 0x80 sein.

    Ich weiß ja jetzt nicht, welches das ChipId Register ist, aber einige 60er-Werte sehe ich, auch einige 80er:

    Gruß, Michael

  • D0 ist das Chip ID Register


    Hmpf... Da hätte ich auch selbst drauf kommen können. Im Script steht ja eindeutig und klar verständlich:

    Code
    def readBME280ID(addr=DEVICE):
      # Chip ID Register Address
      REG_ID = 0xD0
      (chip_id, chip_version) = bus.read_i2c_block_data(DEVICE, REG_ID, 2)
      return (chip_id, chip_version)

    Ich hatte mir noch mit

    Code
    print DEVICE


    ausgeben lassen, ob auch wirklich die 118 ankommen. Ja, tun sie.

    Und auch ein

    Code
    global bus


    brachte keine Besserung.

    Zitat

    Hast Du mal versucht das Programm als root auszuführen, bzw. ist der Benutzer pi in der Gruppe i2c?


    Das Script mit

    Code
    sudo su
    python bme280.py


    brachte leider nach wie vor den gleichen Fehler. Und auch

    Code
    sudo usermod -aG i2c pi


    macht die Sache nicht besser.

    Gruß, Michael

  • Hast Du mal versucht das Programm als root auszuführen, bzw. ist der Benutzer pi in der Gruppe i2c?

    Ich hab jetzt nochmal die ganze Seite von

    http://www.netzmafia.de/skripten/hardw…/RasPi_I2C.html

    durchgeackert. Das meiste war schon erledigt, aber einen Tippfehler in /etc/modules fand ich noch. i2x-dev war wohl nicht ganz richtig.

    Das alleine war's aber nicht. Und zwischenzeitlich ging sogar i2cget gar nicht mehr.

    Aber letztendlich, nach einem weiteren reboot dann endlich:

    Code
    pi@raspi3:~/python/sensors/bme280 $ python bme280.py
    Chip ID     : 96
    Version     : 0
    Temperature :  21.33 C
    Pressure :  639.116544721 hPa
    Humidity :  58.4384104504 %

    Ich weiß letzten Endes noch immer nicht, woran es nun genau lag. Aber was zählt ist ja das Ergebnis. ;)

    Gruß, Michael
    Automatisch zusammengefügt:

    Ich weiß letzten Endes noch immer nicht, woran es nun genau lag. Aber was zählt ist ja das Ergebnis. ;)

    Nachtrag:

    Von Zeit zu Zeit gibt's durch das Script wieder den i/o-error. Dann geht auch i2cget nicht mehr. Es sieht aber so aus, als wenn ich dann durch i2cdetect den Sensor wieder "aufgeweckt" kriege und dann das Script wieder funktioniert.

    Kann das irgendeine "standby"-Funktion sein, oder ist das jetzt nur Zufall?

    reproduzierbar:


    Gruß, Michael

    Einmal editiert, zuletzt von miriki (6. Dezember 2016 um 23:25)

  • Hallo,
    As erstes mal die Frage:
    Hast Du auch das gleiche Problem, wenn Du mehrfach hintereinander mit I2Cget den Wert abfragst?

    Falls nicht, funktioniert das bei mir:
    habe meinen BME280 gerade nochmal angeschlossen. (Trotzdem natürlich ohne Gewähr :p)

    Benenne BME280.txt in BME280.h um (Wieso darf man hier keine Header hochladen??) Kompiliere die Dateien mit

    Code
    gcc -o main BME280_neu.c

    und führe sie aus.
    (Habt bitte Nachsicht, das war eines meiner ersten C-Programme)

    Wenn Du nicht alle 0,5 Sekunden einen Wert ausgespuckt bekommst, muss Dir ein Experte für das I2C Setup helfen. :s

  • Hast Du auch das gleiche Problem, wenn Du mehrfach hintereinander mit I2Cget den Wert abfragst?


    Wenn der Sensor erstmal "weg" ist, bleibt es kontinuierlich beim "read error". Wenn ich i2cget in kürzeren Abständen aufrufe, scheint der Sensor aber "aktiv" zu bleiben. Nur, wenn ich dann länger mal den Prompt stehen lasse und es dann wieder versuche, gibt's den Fehler. Dann ist i2cdetect fällig und es geht wieder. ("länger" = ein paar Minuten)

    Zitat
    Code
    gcc -o main BME280_neu.c

    und führe sie aus.


    Jau, funktioniert, so grundsätzlich. Aber ich mußte mehrmals Mit Ctrl-C abbrechen und neu starten, bis die Temperatur einen sinnvollen Wert bekam. So nach dem 3. oder 4. Start paßte es dann:
    (Glaub mir: Bei 0,15°C würde ich hier nicht sitzen wollen... ;) )

    Ach, und übrigens: Wenn der Sensor "weg" ist, krieg ich mit Deinem Programm trotzdem wieder Werte raus. Und: Das erste i2cget danach liefert dann anscheinend jedesmal 0x80, jedes weitere dann wie gehabt 0x00.

    Gruß, Michael

  • Hi,
    0,15°C kommen aber bei dem Luftdruck, den das Python script ausgibt ungefähr hin. Der Druck entspricht nämlich ungefähr dem Druck auf der Zugspitze, oder Du hattest sehr schlechtes Wetter. ;)
    Doofe Frage: Du sagtest Du hast den Sensor zwei mal. Macht der zweite die gleichen Probleme? Wie weit ist es vom Pi bis zum Sensor und was nimmst Du für Kabel? Die einfachen Jumper Kabel sollte es tun.
    Achso. Und woher kommt eigtl. Die Ausgabe für MSB LSB und xLSB?

    Einmal editiert, zuletzt von El_Zetto (8. Dezember 2016 um 22:09)

  • Der Druck entspricht nämlich ungefähr dem Druck auf der Zugspitze, oder Du hattest sehr schlechtes Wetter. ;)


    Naja, im norddeutschen Flachland herrscht dieser Druck normalerweise wohl eher nicht. Aber unser Wetter hier würden die meisten wohl trotzdem als "sehr schlecht" bezeichnen. ;)

    Zitat

    Doofe Frage: Du sagtest Du hast den Sensor zwei mal. Macht der zweite die gleichen Probleme?


    Ich hab den 2. noch nicht angeschlossen, aber ein anderer Sensor BH1750FVI (Helligkeit), der ebenfalls über i2c läuft, macht, wie ich mittlerweile festgestellt habe, genau das gleiche Problem. Nach i2cdetect funktioniert er klaglos stundenlang. Aber einmal paar Minuten Pause und dann gibt's den I/O-Error. Das scheint aber auf _diesem_ Pi symptomatisch, denn auf dem anderen, an dem der 1750 schon seit einigen Tagen läuft, hatte ich dieses Problem bislang noch nicht.

    Zitat

    Wie weit ist es vom Pi bis zum Sensor und was nimmst Du für Kabel? Die einfachen Jumper Kabel sollte es tun.


    Yep, einfache 20cm Jumper-Kabel.

    Zitat

    Achso. Und woher kommt eigtl. Die Ausgabe für MSB LSB und xLSB?


    Die hab ich mit eingebastelt auf die Schnelle.

    Gruß, Michael

  • Hallo nochmal,

    Sehr mysteriös alles. Das merkwürdige ist, dass die Kommunikation ja eigentlich funktioniert. Ich würde bei weiteren Versuchen nicht das Startregister auslesen. Das Verhalten ist im Datenblatt nicht definiert. Besser ist

    Code
    i2cget -y 1 0x76 0xD0

    Das sollte immer der gleiche Wert (Chip ID) sein.
    Ich würde es noch mit einem

    Code
    sudo apt-get update
    Code
    sudo apt-get upgrade


    versuchen.

    Wenn

    Einmal editiert, zuletzt von El_Zetto (10. Dezember 2016 um 20:58)

  • Code
    sudo apt-get update
    sudo apt-get upgrade


    Das läuft hier auf allen RasPi schon per Cron-Job täglich, wenn sie über Nacht laufen.

    Zitat

    Das merkwürdige ist, dass die Kommunikation ja eigentlich funktioniert.


    Genau, hier scheint auf dem RasPi3 irgendwas geringfügig anders zu sein, als auf dem RasPi2 (also: mein 2. und 3. RasPi, es sind beides 2+). Was ich gerne herausfinden würde: Was macht i2cdetect mehr, als einfach nur die Sensoren zu scannen? Da scheint ja noch eine Art Initialisierung des i2c zu passieren, die beim i2cget oder i2cdump nicht passiert.

    Wenn man diese Initialisierung bei jedem Script am Anfang mit einbaut, wäre das Problem ja gelöst. Denn wenn das Auslesen erstmal funktioniert, dann läuft es auch durchgehend weiter.

    Gruß, Michael

  • Hallo,

    Ich habe auch ein RasPi 3.
    Meinen BME280 (irgendein China Breakout) kann ich mit dem Python script, meinem C Programm und allen I2CTools lesen.

    //Edit:

    Wie sieht denn die Auslastung des RasPi aus wenn Du die Fehlermeldung bekommst? Ist dein RasPi übertaktet?
    Was Du noch versuchen könntest, ist probehalber mal die Baudrate des I2C Bus ändern (Standard sind 100000). Schau vorher mal mit

    Code
    dmesg | grep i2c

    wie deine Baudrate eingestellt ist.
    Zum Ändern in der Datei /boot/config.txt einfach z.B.

    Code
    dtparam=i2c_baudrate=50000


    einsetzen, rebooten und neu versuchen. Vielleicht kommt das Breakout nicht mit der Baudrate zurecht.

    Einmal editiert, zuletzt von El_Zetto (13. Dezember 2016 um 12:58)

  • Ich habe auch ein RasPi 3.


    ;) Deswegen schrieb ich extra: Der Prompt zeigt nur meinen 2. oder 3. RasPi, es sind aber beides 2+ Modelle, keine 3er. (Und RasPi1, ebenfalls ein 2+, läuft seit einigen Monaten als Web- und Mud-Server hinterm Fernseher in einer Ecke im Wohnzimmer.)

    Zitat

    Wie sieht denn die Auslastung des RasPi aus wenn Du die Fehlermeldung bekommst? Ist dein RasPi übertaktet?


    Keine Übertaktung und Auslastung vernachlässigbar gering. Selbst 2 Sessions mit jeweils einer Python-Instanz und einem Dauerlauf-Script sowie einer 3. Session mit "top" bringen den RasPi kaum über 0,3us.

    Zitat

    Was Du noch versuchen könntest, ist probehalber mal die Baudrate des I2C Bus ändern


    Ok, ja, das werde ich mal angehen. Ja, sie steht bei mir auf 100000.

    Was mir aber heute abend so beim Herumprobieren aufgefallen ist:

    Ich hab mir ein Template zum allgemeinen Sensor-Auslesen geschrieben. Das funktioniert im Groben so:
    a) die "main" Schleife schaut im 1-Sekunden-Takt (einstellbar) in der globalen Variable "SensorValue" nach, ob etwas "ungleich None" drinsteht. Wenn ja, wird ein formatierter String ausgegeben und SensorValue auf "None" gesetzt.
    b) Ein Hintergrund-Thread liest im 10-Sekunden-Takt (einstellbar) den Sensor aus und speichert den Wert in der globalen SensorValue.
    c) Ein 2. Hintergrund-Thread, wenn aktiviert, schreibt im 10-Minuten-Takt (einstellbar) die gesammelten Werte in ein Log-File - Damit werden die Schreibzugriffe reduziert. (Liste aus CSV-Zeilen im Arbeitsspeicher, die nach dem Schreiben ins Log geleert wird)

    Beim BME280 scheint die Sensor-Schleife bei irgendwas zwischen 5 und 6 Sekunden kritisch zu werden. Nach ein paar Minuten bricht das Script mit dem altbekannten i/o-error 5 ab. Bei 7,5 Sekunden z.B. nach 2 Minuten, bei 7,0 Sekunden nach 3 bis 4 Minuten usw. Bei 5 Sekunden läuft das Script jetzt seit ca. 1/2 Stunde stabil durch.

    Jetzt das Merkwürdige:

    Ich hab eine 2. Session aufgemacht und dort den BH1750FVI mit dem entsprechenden Script (Ablauf s.o.) aufgerufen. Beide Sensoren stecken auf dem gleichen Breadboard und teilen sich den i2c. Der Helligkeits-Sensor wird im 10-Sekunden-Intervall ausgelesen.

    Beim Start des 2. Script scheint es auch Einfluß auf den 1. Sensor, also den BME280, zu haben. Jetzt wirft der mir nämlich plötzlich im Wechsel (fast genau abwechselnd, manchmal auch 2 gleiche Werte hintereinander) 640 bzw. 1015 für Luftfruck und entsprechend 19,5 bzw. 21,3 Grad für Temperatur aus. Der Wert für die Luftfeuchtigkeit bleibt bei 58 Prozent stabil. Nachdem ich jetzt das 2. Script in der anderen Session abgebrochen habe, liefert der BME280 wieder konstante Werte 58, 19,5 und 1015 zurück.

    Irgendwo hatte ich beim googeln noch einen Hinweis gefunden, wo jemand einfach auf die Adresse des BME280 ein 0xAA geschrieben hat und damit seine i/o-error behoben hatte. Das will ich noch ausprobieren, wenn ich weiß, was genau das eigentlich bewirken soll. Aber es klang so nach einem Timeout-Problem.

    Und woanders fand ich noch den Hinweis, zwischen den Lese- und ggf- Schreib-Operationen unbedingt noch eine kleine Zwangspause (0,5 Sekunden ca.) einzubauen, um ein "Verhaspeln" des Sensors zu verhindern. Auch das werde ich noch Ausprobieren.

    Gruß, Michael

    PS: Zu früh gefreut... Die 5-Sekunden-Schleife ist soeben nach 45 Minuten abgeschmiert mit dem i/o-error.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!