Skip to content
This repository has been archived by the owner on Sep 23, 2021. It is now read-only.

Commit

Permalink
Fix #157
Browse files Browse the repository at this point in the history
  • Loading branch information
@ojousima
ojousima committed Sep 4, 2019
1 parent 259f91b commit 7d008bc
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion drivers/bme280/bme280.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -311,7 +311,8 @@ static uint32_t compensate_H_int32(int32_t adc_H)

v_x1_u32r = (v_x1_u32r - (((((v_x1_u32r >> 15) * (v_x1_u32r >> 15)) >> 7) * ((int32_t)bme280.cp.dig_H1)) >> 4));
v_x1_u32r = (v_x1_u32r < 0 ? 0 : v_x1_u32r);
v_x1_u32r = (v_x1_u32r > 419430400 ? 419430400 : v_x1_u32r);
// Cap maximum reported value to 120%
v_x1_u32r = (v_x1_u32r > 503316480 ? 503316480 : v_x1_u32r);

return (uint32_t)(v_x1_u32r >> 12);
}
Expand Down

5 comments on commit 7d008bc

@DG12
Copy link
Contributor

@DG12 DG12 commented on 7d008bc Sep 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This still reports odd and varying values when calculation is between 100 and 120.

  2. Why not use the (slightly) clearer 120<<10<<12 instead of the magical 503316480. The compiler will resolve it at compile time anyway.

  3. I would rather see
    v_x1_u32r = (v_x1_u32r > (100<<10<<12) ? (120<<10<<12) : v_x1_u32r);

@ojousima
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Why? The ADC reading and parser interpretation should be a constant for all values in range 100 ... 120
  2. The comment is there to clarify the constant, of course it could be calculated as you suggested but I think the meaning of the line is clear enough now.
  3. This would return 120% whenever value is in range of 100 ... 120, which would prevent user applying offset to the reading.

@DG12
Copy link
Contributor

@DG12 DG12 commented on 7d008bc Sep 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. By 'odd and varying values' I meant that values over 100 do not make any sense.
  2. comment doesn't suggest where 503316480 came from .
  3. Yes. My intention is to return a constant whenever the sensor returns "junk"
    Please clarify 'applying offset' . No inference as to actual value should be made if sensor returns "junk"

@ojousima
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. If the sensor has a constant 10 % offset, 95 % would be reported as 105 %. If this constant 10 % offset is known, values in range of 100 ... 110 % can be mapped to actual values.
  2. True, if you have a better wording in mind please open a pull request with updated comment
  3. See 1

@ojousima
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussion with Bosch and some feedback from users we're revisiting this decision and will cap the humidity to 100%, i.e. v_x1_u32r = (v_x1_u32r > (100<<22) ? (100<<22) : v_x1_u32r);

Please sign in to comment.