[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1c8c770-18b4-1722-2672-ee0e8abab611@sierrawireless.com>
Date: Mon, 23 Jul 2018 15:16:10 -0700
From: David Frey <dfrey@...rrawireless.com>
To: Himanshu Jha <himanshujha199640@...il.com>,
Daniel Baluta <daniel.baluta@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-iio <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v4] iio: chemical: Add support for Bosch BME680 sensor
On 7/22/2018 3:21 PM, Himanshu Jha wrote:
> On Sat, Jul 21, 2018 at 08:45:34PM +0300, Daniel Baluta wrote:
>> On Sat, Jul 21, 2018 at 6:43 PM, Andy Shevchenko
>> <andy.shevchenko@...il.com> wrote:
>>> On Sat, Jul 21, 2018 at 6:36 PM, Himanshu Jha
>>> <himanshujha199640@...il.com> wrote:
>>>
>>>>>> + /* Look up table 1 for the possible gas range values */
>>>>>> + u32 lookupTable1[16] = {2147483647u, 2147483647u, 2147483647u,
>>>>>> + 2147483647u, 2147483647u, 2126008810u,
>>>>>> + 2147483647u, 2130303777u, 2147483647u,
>>>>>> + 2147483647u, 2143188679u, 2136746228u,
>>>>>> + 2147483647u, 2126008810u, 2147483647u,
>>>>>> + 2147483647u};
>>>
>>> This one needs perhaps a bit of though, but...
>>>
>>>>>> + /* Look up table 2 for the possible gas range values */
>>>>>> + u32 lookupTable2[16] = {4096000000u, 2048000000u, 1024000000u,
>>>>>> + 512000000u, 255744255u, 127110228u, 64000000u,
>>>>>> + 32258064u, 16016016u, 8000000u, 4000000u,
>>>>>> + 2000000u, 1000000u, 500000u, 250000u, 125000u};
>>>
>>> ...this one obviously just a not needed one. You may replace it with a
>>> one constant and simple calculation to get either value (index from
>>> value, or value from index).
>>
>> Indeed this can be reduce to:
>>
>> 125.000 << (15 - idx).
>>
>> The real question here is if we approximate 255.744.255u to 256.00.00u how
>> much different is the result. Being a gas sensor I think it is very
>> hard to appreciate.
>>
>> We can go with this formula + adding a comment with the table with the
>> exact coefficients.
>
> So, I have planned to use this 125000 << (15 - idx) equation with
> approximating the array members.
>
> About the difference in results we would get after approximating isn't
> much of a problem IMHO because gas sensor is primarily used for IAQ, and
> IAQ is relative to the resistance reading.
>
> For eg:
>
> Resistance(ohm) IAQ
> value < 30K Very bad
> 30k < value < 50k worse
> 50k < value < 70k bad
> ...
> ..
> so on..
>
> So, what I simply imply is the scale will be adjusted and nothing else
> changes, unlike if it had been pressure, temperature, humidity.
>
> The IAQ implementation is userspace application suggesting
> good/bad/ugly air quality.
>
> And since we know David Frey is planning to use this sensor in his
> product mangOH board.
>
> So, David, how are you planning to use the gas sensing part in your
> product ? RGB leds, buzzer, alarm ?
>
> Thanks Andy for the suggestion :)
>
My understanding is that the Bosch BSEC (Bosch Sensortec Environmental
Cluster - https://www.bosch-sensortec.com/bst/products/all_products/bsec)
software calculates the indoor air quality (IAQ) which is presented in
the range of 0 to 500. BSEC is proprietary, pre-compiled static
library. I don't know how they derive the IAQ, but it seems that it
could be based on smoothing outlying gas resistance values and
integrating other values such as temperature, humidity and pressure.
Unless this driver can somehow produce IAQ values of equal or greater
reliability to the BSEC library, then I would prefer that it just
present the raw gas resistance value so that a user can write a program
to feed the sensor data into BSEC.
mangOH isn't really a traditional product. It's an open hardware board
designed around Sierra Wireless cellular modules that run Linux. So I
don't have any specific use case in mind, but I want to enable our users
(and thus future products) to make use of air quality measurements.
Powered by blists - more mailing lists