search

b3nn0 / stratux

Fork of the original cyoung/stratux with multiple patches for flying in europe
BSD 3-Clause "New" or "Revised" License
140 stars 62 forks source link

Cannot get BMP388 / ICM20948 sensors to work #286

Open hchahine opened 4 weeks ago

hchahine commented 4 weeks ago

  1. Stratux version: Latest

  2. Stratux config:

    SDR

    • [x] single
    • [ ] dual

    GPS

    • [x] yes
    • [ ] no type:ublox9

    AHRS

    • [x] yes
    • [ ] no

    power source: Wall wart

    usb cable: n/a

  3. EFB app and version: (e.g., WingX Pro7 8.6.2) N/A

    EFB platform: (e.g., iOS 9.2)

    EFB hardware: (e.g., iPad Mini 2)

  4. Description of your issue:

I'm trying to use a GY-912 module (which includes a BMP388 and a ICM20948). I'm unable to get data from the sensor(s) with error:

2024/06/20 22:12:39 Error identifying BMP: remote I/O error 2024/06/20 22:12:39 Error identifying IMU: remote I/O error

I know both sensors are good because I was able to read their data successfully using an Arduino and some basic Arduino libraries.

The I2C addresses (as read via Arduino) are as follows:

BMP388 - 0x76 ICM20948 - 0x68

I also know the stratux setup I'm testing with is good because I have no issue reading both BMP280 and MPU-9250 sensor boards.

Is there any specific config I need to do to get these sensors to work? Any thoughts on the issue?

FileGo commented 2 weeks ago

I've got exactly the same issue with the same module.

oriagranat9 commented 1 week ago

had this issue while adding the support for the sensor i used the exact same module, this module is designed to be used with an arduino so the i2c wires are expected to be 5V instead of 3.3V, to fix this you need to remove 2 resistors that drop the voltage from 5V to 3.3V as the raspberry pi output is 3.3V image

FileGo commented 1 week ago

Fantastic, it now works flawlessly with the two resistors removed. Thanks @oriagranat9

hchahine commented 1 week ago

I have not had much time to play with this since posting but I did put it on the scope shortly after and noticed that at certain times an I2C line (forget which one - e.g. SCL vs SDA) sat at half bus voltage during comms and did not return to Vbus. So I thought there was some contention between the two I2C devices during or after they are initially configured. Almost as though one is trying to hold the line high while the other is holding the line low.

Didn't get much time to spend on it beyond that but if the above solution works, then great. I'll try it out shortly.

It is odd though that it's rated to operate from 1.8-5V. I think the above solution is possibly a work-around and not addressing the core issue. When I get a chance, I'll try to play around with in on a controlled 3.3V Arduino setup to confirm either way what the underlying issue is - be it hardware or software.