Re: SENSOR_TYPE definition for a gas sensor
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 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 > > 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
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 > 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
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
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
@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
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 = 0x } 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
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
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
Re: SENSOR_TYPE definition for a gas sensor
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