marcelbuesing / bme680

Pure Rust BME680 implementation
MIT License
28 stars 26 forks source link

Logged setting do not match those explicitly set in the example code #12

Closed nickbroon closed 5 years ago

nickbroon commented 5 years ago

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);
caemor commented 5 years ago

The function doesn't retrieve the temperature offset from the sensor, therefore it is set to none ( see function description of the get_sensor_settings e.g. here )

So it might be a bit confusing but it is the currently expected result. :thinking:

marcelbuesing commented 5 years ago

@nickbroon good point, I see why this is confusing. As @caemor stated this is kind of expected since this temperature offset configuration is not stored in the sensor. Here are some options I see:

  1. return the value from `self.tph_sett.temperature_offset, which hides that it does not come from the sensor
  2. not store it in the TphSett struct but separately to distinguish it
  3. add better comments to TphSett.temperature_offset

I favor 1. or 2. but can not decide if it's really relevant to distinguish if this value comes from the sensor or not. What do you both think ? More ideas are welcome =).

nickbroon commented 5 years ago

I think 1 would be preferable, as I don't think there is need to distinguish what is stored in the hardware and what is stored in the driver. I tend to think of the driver and hardware as one unit from an api perspective.

caemor commented 5 years ago

I agree with nick that 1 would be the best from a user view

nickbroon commented 5 years ago

Fixed by 0c90c96a854d2554d071c8269af8ad546cf36706 and released on 0.4.2