marcelbuesing / bme680 Goto Github PK

The chip supports storing up to 10 gas heater profiles, so that can be selected by simply setting the index into nb_conv register before toggling into forced mode. There doesn't seem to be a way to configure profiles 1-9 right now.

See:

The Sensor Settings logged do appear to match those explicitly set in the example code.
For example in the below the temperature_offset is logged as None but the example code sets it to -2.2. Is there something wrong here?

pi@raspberrypi:~/bme680 $ RUST_LOG=reading_temperature ./target/debug/examples/reading_temperature
[2018-12-31T13:02:49Z INFO  reading_temperature] Profile duration 1.533s
[2018-12-31T13:02:49Z INFO  reading_temperature] Setting sensor settings
[2018-12-31T13:02:49Z INFO  reading_temperature] Setting forced power modes
[2018-12-31T13:02:49Z INFO  reading_temperature] Sensor settings: Ok(SensorSettings { gas_sett: GasSett { nb_conv: 0, heatr_ctrl: None, run_gas_measurement: false, heatr_temp: Some(113), heatr_dur: Some(215ms), ambient_temperature: 0 }, tph_sett: TphSett { os_hum: Some(OS2x), os_temp: Some(OS8x), os_pres: Some(OS8x), filter: Some(Size3), temperature_offset: None } })
[2018-12-31T13:02:54Z INFO  reading_temperature] Sensor power mode: Ok(SleepMode)
[2018-12-31T13:02:54Z INFO  reading_temperature] Setting forced power modes
[2018-12-31T13:02:54Z INFO  reading_temperature] Retrieving sensor data
[2018-12-31T13:02:54Z INFO  reading_temperature] Sensor Data FieldData { status: 176, gas_index: 0, meas_index: 0, temperature: 2409, pressure: 101531, humidity: 28124, gas_resistance: 102715 }
[2018-12-31T13:02:54Z INFO  reading_temperature] Temperature 24.09°C
[2018-12-31T13:02:54Z INFO  reading_temperature] Pressure 1015.31hPa
[2018-12-31T13:02:54Z INFO  reading_temperature] Humidity 28.124%
[2018-12-31T13:02:54Z INFO  reading_temperature] Gas Resistence 102715Ω

    let settings = SettingsBuilder::new()
        .with_humidity_oversampling(OversamplingSetting::OS2x)
        .with_pressure_oversampling(OversamplingSetting::OS4x)
        .with_temperature_oversampling(OversamplingSetting::OS8x)
        .with_temperature_filter(IIRFilterSize::Size3)
        .with_gas_measurement(Duration::from_millis(1500), 320, 25)
        .with_temperature_offset(-2.2)
        .with_run_gas(true)
        .build();

    let profile_dur = dev.get_profile_dur(&settings.0)?;
    info!("Profile duration {:?}", profile_dur);
    info!("Setting sensor settings");
    dev.set_sensor_settings(settings)?;
    info!("Setting forced power modes");
    dev.set_sensor_mode(PowerMode::ForcedMode)?;

    let sensor_settings = dev.get_sensor_settings(settings.1);
    info!("Sensor settings: {:?}", sensor_settings);

First of all, thanks for making this crate available!

I am trying to use it to retrieve sensor data, but it seems that I need to set forced power mode no less than three times in order to be able to get a valid read.

My code looks as follows:

fn main() {
    // env_logger::init();
    env_logger::Builder::from_env(Env::default().default_filter_or("debug")).init();

    let i2c = hal::I2cdev::new("/dev/i2c-1").unwrap();
    let mut dev = Bme680::init(i2c, Delay {}, I2CAddress::Primary).unwrap();

    let settings = SettingsBuilder::new()
        .with_humidity_oversampling(OversamplingSetting::OS2x)
        .with_pressure_oversampling(OversamplingSetting::OS4x)
        .with_temperature_oversampling(OversamplingSetting::OS8x)
        .with_temperature_filter(IIRFilterSize::Size3)
        .with_gas_measurement(Duration::from_millis(1500), 320, 25)
        .with_temperature_offset(-2.2)
        .with_run_gas(true)
        .build();

    let profile_dur = dev.get_profile_dur(&settings.0).unwrap();
    info!("Profile duration {:?}", profile_dur);
    info!("Setting sensor settings");
    dev.set_sensor_settings(settings).unwrap();

    info!("Setting forced power modes");
    dev.set_sensor_mode(PowerMode::ForcedMode).unwrap();
    dev.set_sensor_mode(PowerMode::ForcedMode).unwrap();
    dev.set_sensor_mode(PowerMode::ForcedMode).unwrap();

    let (data, _state) = dev.get_sensor_data().unwrap();
    info!("Sensor Data {:?}", data);
    info!("Temperature {}°C", data.temperature_celsius());
    info!("Pressure {}hPa", data.pressure_hpa());
    info!("Humidity {}%", data.humidity_percent());
    info!("Gas Resistence {}Ω", data.gas_resistance_ohm());
}

If I remove even just one of the 3 calls to set_sensor_mode, I get consistently wrong results, e.g.:

Oct 16 22:26:34 raspberrypi hello-world[23731]: [2020-10-16T21:26:34Z INFO  hello_world] Temperature 31.24°C
Oct 16 22:26:34 raspberrypi hello-world[23731]: [2020-10-16T21:26:34Z INFO  hello_world] Pressure 655.98hPa
Oct 16 22:26:34 raspberrypi hello-world[23731]: [2020-10-16T21:26:34Z INFO  hello_world] Humidity 100%
Oct 16 22:26:34 raspberrypi hello-world[23731]: [2020-10-16T21:26:34Z INFO  hello_world] Gas Resistence 806516Ω

Could it be some race condition, or am I doing something wrong?

This crate is awesome but without a bit more for the example it can be difficult to try it simply

The i2cdetect command on the README is very helpful !

For example I was running cargo run --release and did not see any output but it needed RUST_LOG=info cargo run --release

Cargo dependencies should be written in a Cargo.toml file for example so you do not have to pick them one by one until it compiles

[dependencies]
bme680 = "0.6.0"
embedded-hal = "0.2.6"
linux-embedded-hal = "0.3.0"
log = "0.4.14"
env_logger = "0.9.0"

Conclusion: with dependencies and RUST_LOG=info it works !

THANK YOU for saving me from the Python HELL !

Should we make the following fields of the FieldData struct public?

    temperature: i16,
    pressure: u32,
    humidity: u32,
    gas_resistance: u32,

My first requirement is to encode these fields into a packet for wireless communication. I'd prefer to avoid the floating point functions such as temperature_celsius given the additionally complexity with decoding floating point precision (I'm thinking about a JS API for transforming data that is in my world).

Related: should I be concerned with just 20 bits of the u32s? I'm looking for the most compact representation of the above data.

Hi,

i always get the following error when i try to run your example on my rpi2:

Error: I2CWrite(Io(Os { code: 121, kind: Other, message: "Remote I/O error" }))

What device are you using? Or do i need to do anything before running the example?

Greetings

The python library provides this (pimoroni/bme680-python#13) based on details gleamed from the Bosch drivers (pimoroni/bme680-python#11) which also allows to set a temperature offset as the device is not factory calibrated.

Sadly the crate is atm not no_std compatible anymore since f32.signum and f32.abs are std functions.

I added a test in #13 for the future.
But I am still a bit unsure how to change this line (https://github.com/marcelbuesing/bme680/blob/master/src/calc.rs#L58) to make it no_std compatible once more.

As the BME680 supports I2C and SPI, support for SPI would be a nice feature in the future

Add a feature flag for serde support on pure data structs like FieldData.

Thanks for providing this library.

I'm trying to use the library in the context of an embedded-hal. When initing your library I must provide a delayer:

    let mut delayer = Delay::new(board.SYST);

    let mut dev = Bme680::init(i2c, delayer, I2CAddress::Primary).unwrap();

The problem with the above is that, because your library now owns the delayer, I'm no longer able to use it elsewhere.

Do you have any thoughts on what I might do in this situation?

Using an Adafruit BME688 with version 0.6.0 of this lib and the example code, I always get constant readings for humidity and gas.
Temperature and Pressure do slightly change and seem to be correct.

FieldData { status: 176, gas_index: 0, meas_index: 0, temperature: 2222, pressure: 103645, humidity: 100000, gas_resistance: 12917167 }

Hello,
sorry for bugging you once more :-D

But the Gasresistance stays the same for the newest github commit even over very long times ( i have it running for 3 hours now - and a second shorter test with a different bme which returned a different constant value).

I must happened between the i2c-address enum commit and the newest commit.
Or is this an error in my program settings and it works on your end? (although they should be the same as the examples :-D )

Greetings and thanks for your amazing work,
Chris