ppm and/or ppb make the most sense to me for units/scale, yes, but it seems like we might need to define a fairly wide set of gas values for this.

Would a mechanism to indicate 'gas' with 1 bit in sensor_type_t (ex. "1 << 16"), and then a follow-up 32-bit gas measurement type value somewhere make sense, where you define one or more values such as eCO2, TVOC, or other common values?

typedef enum {
    SENSOR_GAS_TYPE_ECO2     = (1 << 0),
    SENSOR_GAS_TYPE_TVOC  = (1 << 1),

    SENSOR_GAS_TYPE_USER_DEFINED_1       = (1 << 26),
    SENSOR_GAS_TYPE_USER_DEFINED_2       = (1 << 27),
    SENSOR_GAS_TYPE_USER_DEFINED_3       = (1 << 28),
    SENSOR_GAS_TYPE_USER_DEFINED_4       = (1 << 29),
    SENSOR_GAS_TYPE_USER_DEFINED_5       = (1 << 30),
    SENSOR_GAS_TYPE_USER_DEFINED_6       = (1 << 31),
    SENSOR_GAS_TYPE_ALL                  = 0xFFFFFFFF
} sensor_gas_type_t;

The question of course is where to store the secondary 32-bit value in an way that doesn't break the reset of the API where sensor data values are all compatible.

There may be other sensors types that would benefit from a second 32-bit value to differentiate data types, such as IR, UV, specific wavelength, etc., light in the case of spectographic sensors.

K.


On 19/07/2018 16:32, Andrey Serdtsev wrote:
Hi all,

Suggest to look at CCS811 digital gas sensor.
It outputs two parameters: eCO2 (equivalent CO2, in units of ppm) and TVOC (total volatile organic compound, in units of ppb).

IMO, this is a good starting point.

BR,
Andrey

On 19.07.2018 17:18, Kevin Townsend wrote:
Hi Amr,

I think gas is a common enough value that it should be added, but the
difficulty is what standard/SI type unit and scale should we use for that since 'gas' is pretty generic. For light it's easy (lux), or acceleration
(m/s^2), but do you have any proposition for what value would be an
acceptable fit in the instance of 'gas'?

Thanks for taking the time to put some drivers together and submitting
them, though. I think sensor drivers have a significant influence on platform adoption, and it puts some extra weight behind Mynewt to have things that
work well out of the box.

Kevin


On 19/07/2018 15:18, Amr Bekhit wrote:
Hello,

I'm preparing to commit my library for the Bosch BME680 Environmental
Sensor and have a question. In sensor.h, there are a sensor_type_t
enum that contains definitions for the various values that can be
read. The BME680 contains a gas sensor that reports a resistance. This
is not listed in the sensor_type_t. I have been using
SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a
SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry
on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance
is not in an of itself a final value - further processing is required
by the application to convert it to something more meaningful (in this
case, the resistance is converted to an Indoor Air Quality Index,
which is calculated by a separate third party module - the Bosch BSEC
library - which I intend to commit soon).

Amr



Reply via email to