fix(bme680): fixed bme680 loss of precision int math error in pressure and altitude measurements#2149
Closed
NickDunklee wants to merge 1 commit into
Closed
Conversation
NickDunklee
force-pushed
the
fix-bme680-pressure-altitude
branch
2 times, most recently
from
b5feb58 to
1c14441
Compare
…asurements BME680.pressure / 100 was integer division before being passed onward resulting in loss of sensor resoluiton for both altitude and pressure changes. - Changed to float math to fix the value only moving in 1hPa steps - Pressure/altitude should no longer appear "stuck" waiting to jump the next 1hPa change - Tested on RAK19003+BME680 It looks like BME280, BMP280, etc. should not be affected as their readPressure() is a float. BMP085 may have a similar problem, but I do not have one to test with.
NickDunklee
force-pushed
the
fix-bme680-pressure-altitude
branch
from
1c14441 to
96f8786
Compare
Author
Left side of graph was before change, right side after. Updated this comment with a better graph. |
robekl
added a commit
to robekl/MeshCore
that referenced
this pull request
Mar 31, 2026
Corrects integer math errors in the BME680 sensor reading logic where integer division was causing loss of precision in pressure and altitude telemetry. By using floating point constants for division (100.0f), accuracy is significantly improved. Based on meshcore-dev/MeshCore PR meshcore-dev#2149.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always MCU and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
NickDunklee
added a commit
to NickDunklee/MeshCore
that referenced
this pull request
Apr 18, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
JosiahWI
pushed a commit
to uwl-cpe-2025/MeshCore
that referenced
this pull request
May 7, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
JosiahWI
pushed a commit
to uwl-cpe-2025/MeshCore
that referenced
this pull request
May 7, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
tuzzmaniandevil
pushed a commit
to tuzzmaniandevil/MeshCore
that referenced
this pull request
May 7, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
musznik
pushed a commit
to musznik/MeshCoreMx
that referenced
this pull request
May 23, 2026
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
Author
|
I am going to write a consolidated bme680 PR that will make this and the other irrelevant, but will leave these both open in case people want to see these changes to utilize them in their own builds for now. Will close them both once I have that PR up. |
Author
|
Finally integrated my BME680 changes so closing this, commit for that is at #2634 |
ripplebiz
pushed a commit
that referenced
this pull request
Jun 1, 2026
This is a consolidation of my changes for BME680 on RAK4631 nodes. I will close my other PRs related to this and link back to this one. *Background on change:* This change replaces the Adafruit BME680 driver on RAK4631 with the Bosch BSEC library. Other boards continue to use the existing Adafruit path via ENV_INCLUDE_BME680. This makes the IAQ portion of the sensor functional, and more accurate. It also contains the math and/or CayenneLPP fixes from my other PRs. The Bosch code also appears to handle calibrating sensor aging as well, whereas the Adafruit code is just looking at blind values that can drift with time. Pretty cool to see this shooting out useful data! RAK4631 platform.io is set to override to ENV_INCLUDE_BME680_BSEC while leaving the Adafruit code for other node types. (If this becomes applicable for other node types in future, awesome! I just don't have hardware to test against.) Using the BSEC library introduces IAQ sensor calibration, and saves the calibration state periodically so it does not have to calibrate again later. At startup the IAQ sensor takes 30 minutes to heat and to hit a baseline, then starts calibrating. Once calibrated, it will save those settings and will only write settings again if calibration falls back and restores back to state 3. This fix also has the gas resistance math fix that was in [pull 2146](#2146) so the adafruit path also can at least show accurate values instead of looping negative. Also includes the fix from [pull 2149](#2149) so the pressure output isn't truncated to 1hPa steps. *Fixes/Changes:* - Add bsec_config_iaq[] with the 3.3V/3s-LP/28d calibration profile - BSEC init applies setConfig() for voltage-correct heater targeting - IAQ, heat-compensated temperature/humidity, pressure, and altitude reported over CayenneLPP - IAQ accuracy reported as analog input over CayenneLPP (0,1,2,3) - Calibration state persisted to /bsec_state.bin on nRF52 internal flash; written only when iaqAccuracy improves to >= 2, should keep write frequency well within flash endurance over device lifetime - Fix non-BSEC query_bme680: float pressure division, addGenericSensor for gas resistance (was addAnalogInput, overflows at > 327 Ohm) - loop() correctly gated for both GPS and BSEC-only builds - Add fix_bsec_lib.py extra_script to resolve nRF52840 hard-float ABI mismatch in Bosch's PlatformIO packaging, silly Bosch One general note outside of this code change: I noticed while BME680 _functions_ in companion nodes, since companion nodes run Bluetooth, BLE preempts the CPU, and can do so mid-I2C-transaction. This can cause the BME680 to see an anomaly and drop calibration and start a recalibrate. This is behavior that will exist (and has existed) regardless of using the Adafruit or Bosch paths. This particular companion behavior does not seem to occur in sensor or repeater nodes since their BLE is off. Probably affects other I2C devices as well. *Tests:* - RAK19003 - RAK19007 - RAK19001 - repeater, sensor, companion
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BME680.pressure / 100 was integer division before being passed onward resulting in loss of sensor resoluiton for both altitude and pressure changes.
It looks like BME280, BMP280, etc. should not be affected as their readPressure() is a float. BMP085 may have a similar problem, but I do not have one to test with.