You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Amr Bekhit <am...@gmail.com> on 2018/07/19 13:18:53 UTC
SENSOR_TYPE definition for a gas sensor
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
Re: SENSOR_TYPE definition for a gas sensor
Posted by Kevin Townsend <ke...@adafruit.com.INVALID>.
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
>>
>
Re: SENSOR_TYPE definition for a gas sensor
Posted by Andrey Serdtsev <an...@yotadevices.com>.
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
>
Re: SENSOR_TYPE definition for a gas sensor
Posted by Kevin Townsend <ke...@adafruit.com.INVALID>.
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
Re: SENSOR_TYPE definition for a gas sensor
Posted by Amr Bekhit <am...@gmail.com>.
I've created a pull request for the BME680 driver, which can be found
at https://github.com/apache/mynewt-core/pull/1286. Regarding the gas
sensor type, as suggested by Kevin, I've allowed that to be modified
via syscfg.
As mentioned previously, the BME680 is ultimately designed to be used
with Bosch's BSEC library. I'll be posting a message to discuss that
on the mailing list soon.
On Thu, 19 Jul 2018 at 20:37, Vipul Rahane <vi...@runtime.io> wrote:
>
> So, I do not feel strongly about one approach Vs another but I think if we are measuring resistance with a sensor, the units need to be in OHMS.
>
> Obviously, the kind of resistance might matter. For example: Gas resistance Vs Fluid resistance, etc. So, SENSOR_TYPE_GAS_RESISTANCE with OHMS as the unit makes sense for me.
>
> Regards,
> Vipul Rahane
>
> > On Jul 19, 2018, at 8:47 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
> >
> > Extending ppb to uint64_t definitely doesn't make sense since maximum value for it is 10^6, which is 32bit value.
> >
> > Sincerely yours, CO :)
> >
> > BR,
> > Andrey
> >
> > On 19.07.2018 18:41, Kevin Townsend wrote:
> >>
> >>> Thanks for your comments @Kevin and @Andrey. I think for the BME680,
> >>> I'll stick with USER_DEFINED for now until we can come up with a more
> >>> general system. Ultimately, the gas sensor resistance is not really a
> >>> final value to be used and so I think it's OK for it to fall under the
> >>> USER_DEFINED category.
> >> We should only define values based on standard and repeatable units, I agree,
> >> so USER_DEFINED makes sense here, though you might want to make which
> >> USER_DEFINED entry (1-6) selectable via syscfg.yml.
> >>
> >> This does still bring up a valid discussion about important sensor groups like 'gas',
> >> though.
> >>
> >> I was thinking, for example, we could define 1-bit for 'gas' and then hijack the
> >> triplet value type, where the first 32-bit value could define the gas type, and then
> >> the second value could contain the value in ppb (which could possibly be extended
> >> to a uint64_t, though I don't know if that's useful in the real world)?
> >>
> >> K.
> >
>
Re: SENSOR_TYPE definition for a gas sensor
Posted by Vipul Rahane <vi...@runtime.io>.
So, I do not feel strongly about one approach Vs another but I think if we are measuring resistance with a sensor, the units need to be in OHMS.
Obviously, the kind of resistance might matter. For example: Gas resistance Vs Fluid resistance, etc. So, SENSOR_TYPE_GAS_RESISTANCE with OHMS as the unit makes sense for me.
Regards,
Vipul Rahane
> On Jul 19, 2018, at 8:47 AM, Andrey Serdtsev <an...@yotadevices.com> wrote:
>
> Extending ppb to uint64_t definitely doesn't make sense since maximum value for it is 10^6, which is 32bit value.
>
> Sincerely yours, CO :)
>
> BR,
> Andrey
>
> On 19.07.2018 18:41, Kevin Townsend wrote:
>>
>>> Thanks for your comments @Kevin and @Andrey. I think for the BME680,
>>> I'll stick with USER_DEFINED for now until we can come up with a more
>>> general system. Ultimately, the gas sensor resistance is not really a
>>> final value to be used and so I think it's OK for it to fall under the
>>> USER_DEFINED category.
>> We should only define values based on standard and repeatable units, I agree,
>> so USER_DEFINED makes sense here, though you might want to make which
>> USER_DEFINED entry (1-6) selectable via syscfg.yml.
>>
>> This does still bring up a valid discussion about important sensor groups like 'gas',
>> though.
>>
>> I was thinking, for example, we could define 1-bit for 'gas' and then hijack the
>> triplet value type, where the first 32-bit value could define the gas type, and then
>> the second value could contain the value in ppb (which could possibly be extended
>> to a uint64_t, though I don't know if that's useful in the real world)?
>>
>> K.
>
Re: SENSOR_TYPE definition for a gas sensor
Posted by Andrey Serdtsev <an...@yotadevices.com>.
Extending ppb to uint64_t definitely doesn't make sense since maximum
value for it is 10^6, which is 32bit value.
Sincerely yours, CO :)
BR,
Andrey
On 19.07.2018 18:41, Kevin Townsend wrote:
>
>> Thanks for your comments @Kevin and @Andrey. I think for the BME680,
>> I'll stick with USER_DEFINED for now until we can come up with a more
>> general system. Ultimately, the gas sensor resistance is not really a
>> final value to be used and so I think it's OK for it to fall under the
>> USER_DEFINED category.
> We should only define values based on standard and repeatable units, I
> agree,
> so USER_DEFINED makes sense here, though you might want to make which
> USER_DEFINED entry (1-6) selectable via syscfg.yml.
>
> This does still bring up a valid discussion about important sensor
> groups like 'gas',
> though.
>
> I was thinking, for example, we could define 1-bit for 'gas' and then
> hijack the
> triplet value type, where the first 32-bit value could define the gas
> type, and then
> the second value could contain the value in ppb (which could possibly
> be extended
> to a uint64_t, though I don't know if that's useful in the real world)?
>
> K.
Re: SENSOR_TYPE definition for a gas sensor
Posted by Kevin Townsend <ke...@adafruit.com.INVALID>.
> Thanks for your comments @Kevin and @Andrey. I think for the BME680,
> I'll stick with USER_DEFINED for now until we can come up with a more
> general system. Ultimately, the gas sensor resistance is not really a
> final value to be used and so I think it's OK for it to fall under the
> USER_DEFINED category.
We should only define values based on standard and repeatable units, I
agree,
so USER_DEFINED makes sense here, though you might want to make which
USER_DEFINED entry (1-6) selectable via syscfg.yml.
This does still bring up a valid discussion about important sensor
groups like 'gas',
though.
I was thinking, for example, we could define 1-bit for 'gas' and then
hijack the
triplet value type, where the first 32-bit value could define the gas
type, and then
the second value could contain the value in ppb (which could possibly be
extended
to a uint64_t, though I don't know if that's useful in the real world)?
K.
Re: SENSOR_TYPE definition for a gas sensor
Posted by Amr Bekhit <am...@gmail.com>.
@Abderrezak
> My question is: does Bosch allow the "re-distribution" of their
> proprietary library?
There are two parts to the Bosch library - the first it the BME680
driver, which, according to the license agreement can be redistributed
in both source and compiled forms no problem. The other is the
precompiled binary which forms the core of the BSEC library. I've
integerated the BME680 library into the mynewt sensor framework. I've
implemented the BSEC library as a separate mynewt module that you can
optionally include into your project. This would either be commited
into the main mynewt code, or available as a separate third party
repository on github. The compiled library however, will not be
distributed with the code and must be downloaded by the user and
placed into the relevant folder in order for the project to compile.
Thanks for your comments @Kevin and @Andrey. I think for the BME680,
I'll stick with USER_DEFINED for now until we can come up with a more
general system. Ultimately, the gas sensor resistance is not really a
final value to be used and so I think it's OK for it to fall under the
USER_DEFINED category.
Re: SENSOR_TYPE definition for a gas sensor
Posted by Abderrezak Mekkaoui <ab...@gmail.com>.
Hi Amr,
I am myself using the bme680. I am looking forward to trying your
implementation.
My question is: does Bosch allow the "re-distribution" of their
proprietary library?
Thanks for the effort.
Abderrezak
On 7/19/2018 9:18 AM, 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