Buffert trigger and Power management support for BME680 ?

Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

Hi,

The initial minimal driver has been recently merged[1] and irrespective
of the ending week of Google Summer of Code'18, I would like to extend this
driver and work on it.

I have a few queries for the community:

1. Buffered Trigger Support:
----------------------------

Is it worth to add buffer support for this device ?
The device has 1Hz Forced mode which we need to enable everytime
we need a reading.

Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries for
different platforms, and the software has various modes:

	* Ultra-low power mode.
	* Ultra-low power mode.
	* Continuous mode.

According to datasheet "1.2 Gas sensor specification"

Response time		Continuous mode		0.75s

Now, these details are worth noting and confusing at the same to me!
Since, we only have 1Hz mode, so would it be a problem when adding this
interface to get continuous measurements ?
What other factors/caveats should I look for before proceeding further ?

2. Power Management:
-------------------

3.1 Sensor modes

	Forced mode:
		* Single TPHG cycle is performed
		* Sensor *automatically* returns to sleep mode afterwards
		* Gas sensor heater only operates during gas measurement
	Sleep mode:
		* No measurements are performed
		* Minimal power consumption

So, in my opinion this device is already power managed.
Comments ?

3. Adding more sysfs interface:
-------------------------------

Currently in the driver I have supplied default values to the sensor
at probe which are:

        data->heater_temp = 320; /* degree Celsius */
        data->heater_dur = 150;  /* milliseconds */

Now, these values are:

1. Target heater temperature for the heater plate to be supplied for the
   sensor. This value can be supplied by the user and value should lie
   typically between 200 °C and 400 °C.
2. Target heater duration time for which heater plate would be heated
   before initiating gas sensing measurements. Value lying between
   200-4032ms.

But there is a caveat!
If the sensor doesn't get the right combination of above two values, if
will likely abort since:
[ comment from the current code ]
        
	/*
         * occurs if either the gas heating duration was insuffient
         * to reach the target heater temperature or the target
         * heater temperature was too high for the heater sink to
         * reach.
         */

So, what should be the appropriate channel types for these two
interfaces ?
I had the same question on my RFC patch and Matt Ranostay suggested[2]

	"Just use IIO_TEMP and signal it is an output channel."

Now, I clearly doesn't understand the rationale behind the channel type?
And what does direction(input/output) signify ?

Isn't it that channel type is based on the "what measurement the channel
is actually producing" ?

Anyway, digging further I found that Matt had a slighlty similar situation
in 'TI HDC100x temperature + humidity sensors' driver, where it was
required to enable heater to drive condensation off the sensor. And Matt
used:

                .type = IIO_CURRENT,
                .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
                .extend_name = "heater",
                .output = 1,
                .scan_index = -1,

IIO_CURRENT ? And .output = 1, ? Please shed some insight on this.
And why was extended_name necessary here and creating a new ABI. We
already had an ABI to handle such situation:

Documentation/ABI/testing/sysfs-bus-iio

What:           /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion:  4.1.0
Contact:        linux-iio@vger.kernel.org
Description:
                '1' (enable) or '0' (disable) specifying the enable
                of heater function. Same reading values apply
                This ABI is especially applicable for humidity sensors
                to heatup the device and get rid of any condensation
                in some humidity environment

Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x

What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available
KernelVersion:  4.3 
Contact:        linux-iio@vger.kernel.org
Description:
                Controls the heater device within the humidity sensor to get 
                rid of excess condensation.

                Valid control values are 0 = OFF, and 1 = ON. 

Was this necessary ?
Just curious about these information. It will help me decide how should
I proceed further.

4. Algorith behind Compensation functions:
------------------------------------------

Jonathan suggested[3] to reverse engineer the compensation function and
document the equation/algorithm.

But the compensation are really complex calculations, and I will try to
decipher if possible.

As a better solution, I contacted Bosch Sensortec again for the
algorithm and let's hope they reply back soon. I don't have a direct
contact to Bosch developers but to someone at their office. So, it takes
a while to get constructive feedback.


Thanks Jonathan, Daniel, Matt, Andy, David and all the reviewers. It was
truly a great experience and would need your patience and help for some
more time :)

[1] https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=1b3bd8592780c87c5eddabbe98666b086bbaee36
[2] https://marc.info/?l=linux-iio&m=152968608230844&w=2
[3] https://marc.info/?l=linux-iio&m=153277443604044&w=2
-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Buffert trigger and Power management support for BME680 ?

[Jonathan Cameron]

On Mon, 30 Jul 2018 17:42:41 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> Hi,
>=20
> The initial minimal driver has been recently merged[1] and irrespective
> of the ending week of Google Summer of Code'18, I would like to extend th=
is
> driver and work on it.
>=20
> I have a few queries for the community:
>=20
> 1. Buffered Trigger Support:
> ----------------------------
>=20
> Is it worth to add buffer support for this device ?
> The device has 1Hz Forced mode which we need to enable everytime
> we need a reading.
>=20
> Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries for
> different platforms, and the software has various modes:
>=20
> 	* Ultra-low power mode.
> 	* Ultra-low power mode.
> 	* Continuous mode.
>=20
> According to datasheet "1.2 Gas sensor specification"
>=20
> Response time		Continuous mode		0.75s
>=20
> Now, these details are worth noting and confusing at the same to me!
> Since, we only have 1Hz mode, so would it be a problem when adding this
> interface to get continuous measurements ?
> What other factors/caveats should I look for before proceeding further ?

Technically there is no problem with adding buffered mode, but there may
be no real usecases at these very low rates.

The main convenience is that you could read out the various channels in one
pass (I think - haven't checked the datasheet).

>=20
> 2. Power Management:
> -------------------
>=20
> 3.1 Sensor modes
>=20
> 	Forced mode:
> 		* Single TPHG cycle is performed
> 		* Sensor *automatically* returns to sleep mode afterwards
> 		* Gas sensor heater only operates during gas measurement
> 	Sleep mode:
> 		* No measurements are performed
> 		* Minimal power consumption
>=20
> So, in my opinion this device is already power managed.
> Comments ?

It seems like there is little purpose in sleep mode, are there power
numbers to indicate what 'minimal' means here?

>=20
> 3. Adding more sysfs interface:
> -------------------------------
>=20
> Currently in the driver I have supplied default values to the sensor
> at probe which are:
>=20
>         data->heater_temp =3D 320; /* degree Celsius */
>         data->heater_dur =3D 150;  /* milliseconds */
>=20
> Now, these values are:
>=20
> 1. Target heater temperature for the heater plate to be supplied for the
>    sensor. This value can be supplied by the user and value should lie
>    typically between 200 =B0C and 400 =B0C.
> 2. Target heater duration time for which heater plate would be heated
>    before initiating gas sensing measurements. Value lying between
>    200-4032ms.
>=20
> But there is a caveat!
> If the sensor doesn't get the right combination of above two values, if
> will likely abort since:
> [ comment from the current code ]
>        =20
> 	/*
>          * occurs if either the gas heating duration was insuffient
>          * to reach the target heater temperature or the target
>          * heater temperature was too high for the heater sink to
>          * reach.
>          */
>=20
> So, what should be the appropriate channel types for these two
> interfaces ?

Hmm. I guess this issue here is that the temperature rise time is
dependent on the environment (moisture / temperature etc) so we can't
do the obvious and just put in reasonable defaults (assuming the temperature
is the only controlled channel).=20

I wonder if we can get 'close' enough and retry a few times if we get
an abort?

> I had the same question on my RFC patch and Matt Ranostay suggested[2]
>=20
> 	"Just use IIO_TEMP and signal it is an output channel."
>=20
> Now, I clearly doesn't understand the rationale behind the channel type?
> And what does direction(input/output) signify ?

input is something you read, output is something that is forced.  So
in this case you are literally setting the temperature of the plate.

It's not a perfect interface for this, but it is compliant with the ABI
and reasonably obvious what it is doing to anyone who is familiar with
this sort of sensor.



>=20
> Isn't it that channel type is based on the "what measurement the channel
> is actually producing" ?
>=20
> Anyway, digging further I found that Matt had a slighlty similar situation
> in 'TI HDC100x temperature + humidity sensors' driver, where it was
> required to enable heater to drive condensation off the sensor. And Matt
> used:
>=20
>                 .type =3D IIO_CURRENT,
>                 .info_mask_separate =3D BIT(IIO_CHAN_INFO_RAW),
>                 .extend_name =3D "heater",
>                 .output =3D 1,
>                 .scan_index =3D -1,
>=20
> IIO_CURRENT ? And .output =3D 1, ? Please shed some insight on this.
> And why was extended_name necessary here and creating a new ABI. We
> already had an ABI to handle such situation:

In this case it is a rather more stupid device and all you control is
the current output that feeds the heater.

>=20
> Documentation/ABI/testing/sysfs-bus-iio
>=20
> What:           /sys/bus/iio/devices/iio:deviceX/heater_enable
> KernelVersion:  4.1.0
> Contact:        linux-iio@vger.kernel.org
> Description:
>                 '1' (enable) or '0' (disable) specifying the enable
>                 of heater function. Same reading values apply
>                 This ABI is especially applicable for humidity sensors
>                 to heatup the device and get rid of any condensation
>                 in some humidity environment
>=20
> Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x
>=20
> What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
> What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_a=
vailable
> KernelVersion:  4.3=20
> Contact:        linux-iio@vger.kernel.org
> Description:
>                 Controls the heater device within the humidity sensor to =
get=20
>                 rid of excess condensation.
>=20
>                 Valid control values are 0 =3D OFF, and 1 =3D ON.=20
>=20
> Was this necessary ?

That does seem like somewhat of a mess.  We shouldn't have ended up with bo=
th
ABIs, but now we are stuck with them.

> Just curious about these information. It will help me decide how should
> I proceed further.

The heater enable doesn't make sense here as you have a range of values
rather than a boolean.  Hence the second one would be valid if you were con=
trolling
the current.  As it is a target temperature, it'll need to be a temperature
channel with more docs added to explain what it is.

>=20
> 4. Algorith behind Compensation functions:
> ------------------------------------------
>=20
> Jonathan suggested[3] to reverse engineer the compensation function and
> document the equation/algorithm.
>=20
> But the compensation are really complex calculations, and I will try to
> decipher if possible.

This is more for interest of anyone coming along later than anything else ;)

>=20
> As a better solution, I contacted Bosch Sensortec again for the
> algorithm and let's hope they reply back soon. I don't have a direct
> contact to Bosch developers but to someone at their office. So, it takes
> a while to get constructive feedback.

That would be great if they'll provide the info!  Maybe we can even
persuade them to put it in an updated data sheet or an app note or similar!
>=20
>=20
> Thanks Jonathan, Daniel, Matt, Andy, David and all the reviewers. It was
> truly a great experience and would need your patience and help for some
> more time :)

You are welcome and hope you stay around the kernel in the future!

Jonathan
>=20
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/=
?h=3Dtesting&id=3D1b3bd8592780c87c5eddabbe98666b086bbaee36
> [2] https://marc.info/?l=3Dlinux-iio&m=3D152968608230844&w=3D2
> [3] https://marc.info/?l=3Dlinux-iio&m=3D153277443604044&w=3D2

Re: Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

On Mon, Jul 30, 2018 at 02:07:46PM +0100, Jonathan Cameron wrote:
> On Mon, 30 Jul 2018 17:42:41 +0530
> Himanshu Jha <himanshujha199640@gmail.com> wrote:
> 
> > Hi,
> > 
> > The initial minimal driver has been recently merged[1] and irrespective
> > of the ending week of Google Summer of Code'18, I would like to extend this
> > driver and work on it.
> > 
> > I have a few queries for the community:
> > 
> > 1. Buffered Trigger Support:
> > ----------------------------
> > 
> > Is it worth to add buffer support for this device ?
> > The device has 1Hz Forced mode which we need to enable everytime
> > we need a reading.
> > 
> > Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries for
> > different platforms, and the software has various modes:
> > 
> > 	* Ultra-low power mode.
> > 	* Ultra-low power mode.
> > 	* Continuous mode.
> > 
> > According to datasheet "1.2 Gas sensor specification"
> > 
> > Response time		Continuous mode		0.75s
> > 
> > Now, these details are worth noting and confusing at the same to me!
> > Since, we only have 1Hz mode, so would it be a problem when adding this
> > interface to get continuous measurements ?
> > What other factors/caveats should I look for before proceeding further ?
> 
> Technically there is no problem with adding buffered mode, but there may
> be no real usecases at these very low rates.

Alright!

> The main convenience is that you could read out the various channels in one
> pass (I think - haven't checked the datasheet).
> 
> > 
> > 2. Power Management:
> > -------------------
> > 
> > 3.1 Sensor modes
> > 
> > 	Forced mode:
> > 		* Single TPHG cycle is performed
> > 		* Sensor *automatically* returns to sleep mode afterwards
> > 		* Gas sensor heater only operates during gas measurement
> > 	Sleep mode:
> > 		* No measurements are performed
> > 		* Minimal power consumption
> > 
> > So, in my opinion this device is already power managed.
> > Comments ?
> 
> It seems like there is little purpose in sleep mode, are there power
> numbers to indicate what 'minimal' means here?

There are no such statistics described in the datasheet, neither is
after how much time does the sensor goes automatically to sleep!
Maybe in coming revision, not sure though.

> > 
> > 3. Adding more sysfs interface:
> > -------------------------------
> > 
> > Currently in the driver I have supplied default values to the sensor
> > at probe which are:
> > 
> >         data->heater_temp = 320; /* degree Celsius */
> >         data->heater_dur = 150;  /* milliseconds */
> > 
> > Now, these values are:
> > 
> > 1. Target heater temperature for the heater plate to be supplied for the
> >    sensor. This value can be supplied by the user and value should lie
> >    typically between 200 °C and 400 °C.
> > 2. Target heater duration time for which heater plate would be heated
> >    before initiating gas sensing measurements. Value lying between
> >    200-4032ms.
> > 
> > But there is a caveat!
> > If the sensor doesn't get the right combination of above two values, if
> > will likely abort since:
> > [ comment from the current code ]
> >         
> > 	/*
> >          * occurs if either the gas heating duration was insuffient
> >          * to reach the target heater temperature or the target
> >          * heater temperature was too high for the heater sink to
> >          * reach.
> >          */
> > 
> > So, what should be the appropriate channel types for these two
> > interfaces ?
> 
> Hmm. I guess this issue here is that the temperature rise time is
> dependent on the environment (moisture / temperature etc) so we can't
> do the obvious and just put in reasonable defaults (assuming the temperature
> is the only controlled channel). 

Yes, gas sensor in influenced by the temperature channel and yes, of
course, on the environment. I experienced this behavior while testing,
that if you solely take gas readings(with say some improper combination
of heater temp & duration) then it would a few iterations to fetch
readings. On the other hand, if done in T->P->H->G fashion then its more
likely failsafe. Ultimately it helps in reaching the target temperature
easily.

As a sidenote: in the code there is a macro for ambient temperature
	
	#define BME680_AMB_TEMP                         25

and should be changed according to the environment.

> I wonder if we can get 'close' enough and retry a few times if we get
> an abort?

Yes! Infact I thought of retrying, for say about 10 iterations(in my
case) but later the default values worked perfectly fine. Testing from well
Air Conditioned room to deadly 47 degC New Delhi heat ;)

> > I had the same question on my RFC patch and Matt Ranostay suggested[2]
> > 
> > 	"Just use IIO_TEMP and signal it is an output channel."
> > 
> > Now, I clearly doesn't understand the rationale behind the channel type?
> > And what does direction(input/output) signify ?
> 
> input is something you read, output is something that is forced.  So
> in this case you are literally setting the temperature of the plate.
> 
> It's not a perfect interface for this, but it is compliant with the ABI
> and reasonably obvious what it is doing to anyone who is familiar with
> this sort of sensor.

Ah, I also had attributes to supply oversampling ratio for temp,
press & humid channels from userspace. So, does that make it an output
channel ? Forcing ?

> > Anyway, digging further I found that Matt had a slighlty similar situation
> > in 'TI HDC100x temperature + humidity sensors' driver, where it was
> > required to enable heater to drive condensation off the sensor. And Matt
> > used:
> > 
> >                 .type = IIO_CURRENT,
> >                 .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> >                 .extend_name = "heater",
> >                 .output = 1,
> >                 .scan_index = -1,
> > 
> > IIO_CURRENT ? And .output = 1, ? Please shed some insight on this.
> > And why was extended_name necessary here and creating a new ABI. We
> > already had an ABI to handle such situation:
> 
> In this case it is a rather more stupid device and all you control is
> the current output that feeds the heater.
> 
> > 
> > Documentation/ABI/testing/sysfs-bus-iio
> > 
> > What:           /sys/bus/iio/devices/iio:deviceX/heater_enable
> > KernelVersion:  4.1.0
> > Contact:        linux-iio@vger.kernel.org
> > Description:
> >                 '1' (enable) or '0' (disable) specifying the enable
> >                 of heater function. Same reading values apply
> >                 This ABI is especially applicable for humidity sensors
> >                 to heatup the device and get rid of any condensation
> >                 in some humidity environment
> > 
> > Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x
> > 
> > What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
> > What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available
> > KernelVersion:  4.3 
> > Contact:        linux-iio@vger.kernel.org
> > Description:
> >                 Controls the heater device within the humidity sensor to get 
> >                 rid of excess condensation.
> > 
> >                 Valid control values are 0 = OFF, and 1 = ON. 
> > 
> > Was this necessary ?
> 
> That does seem like somewhat of a mess.  We shouldn't have ended up with both
> ABIs, but now we are stuck with them.

Fine.

> > Just curious about these information. It will help me decide how should
> > I proceed further.
> 
> The heater enable doesn't make sense here as you have a range of values
> rather than a boolean.  Hence the second one would be valid if you were controlling
> the current.  As it is a target temperature, it'll need to be a temperature
> channel with more docs added to explain what it is.

Hmm. For heater duration we are supplying time(ms)
And out_current_heater_raw is definitely not valid here.
Still unsure about the channel type and the corresponding
sysfs entry.

> > 4. Algorith behind Compensation functions:
> > ------------------------------------------
> > 
> > Jonathan suggested[3] to reverse engineer the compensation function and
> > document the equation/algorithm.
> > 
> > But the compensation are really complex calculations, and I will try to
> > decipher if possible.
> 
> This is more for interest of anyone coming along later than anything else ;)
> 
> > 
> > As a better solution, I contacted Bosch Sensortec again for the
> > algorithm and let's hope they reply back soon. I don't have a direct
> > contact to Bosch developers but to someone at their office. So, it takes
> > a while to get constructive feedback.
> 
> That would be great if they'll provide the info!  Maybe we can even
> persuade them to put it in an updated data sheet or an app note or similar!

I got a reply from them about the formula they use to calculate the IAQ
but not how compensation function is designed.

Will forward the email after their permission as the background
watermark text in the formula image says "Confidential!!"
Sometimes you need to be careful ;)

> > Thanks Jonathan, Daniel, Matt, Andy, David and all the reviewers. It was
> > truly a great experience and would need your patience and help for some
> > more time :)
> 
> You are welcome and hope you stay around the kernel in the future!

I am certainly around for a year until I graduate and not sure about
the future :)

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Buffert trigger and Power management support for BME680 ?

[Jonathan Cameron]

On Mon, 30 Jul 2018 23:23:41 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> On Mon, Jul 30, 2018 at 02:07:46PM +0100, Jonathan Cameron wrote:
> > On Mon, 30 Jul 2018 17:42:41 +0530
> > Himanshu Jha <himanshujha199640@gmail.com> wrote:
> >  =20
> > > Hi,
> > >=20
> > > The initial minimal driver has been recently merged[1] and irrespecti=
ve
> > > of the ending week of Google Summer of Code'18, I would like to exten=
d this
> > > driver and work on it.
> > >=20
> > > I have a few queries for the community:
> > >=20
> > > 1. Buffered Trigger Support:
> > > ----------------------------
> > >=20
> > > Is it worth to add buffer support for this device ?
> > > The device has 1Hz Forced mode which we need to enable everytime
> > > we need a reading.
> > >=20
> > > Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries=
 for
> > > different platforms, and the software has various modes:
> > >=20
> > > 	* Ultra-low power mode.
> > > 	* Ultra-low power mode.
> > > 	* Continuous mode.
> > >=20
> > > According to datasheet "1.2 Gas sensor specification"
> > >=20
> > > Response time		Continuous mode		0.75s
> > >=20
> > > Now, these details are worth noting and confusing at the same to me!
> > > Since, we only have 1Hz mode, so would it be a problem when adding th=
is
> > > interface to get continuous measurements ?
> > > What other factors/caveats should I look for before proceeding furthe=
r ? =20
> >=20
> > Technically there is no problem with adding buffered mode, but there may
> > be no real usecases at these very low rates. =20
>=20
> Alright!
>=20
> > The main convenience is that you could read out the various channels in=
 one
> > pass (I think - haven't checked the datasheet).
> >  =20
> > >=20
> > > 2. Power Management:
> > > -------------------
> > >=20
> > > 3.1 Sensor modes
> > >=20
> > > 	Forced mode:
> > > 		* Single TPHG cycle is performed
> > > 		* Sensor *automatically* returns to sleep mode afterwards
> > > 		* Gas sensor heater only operates during gas measurement
> > > 	Sleep mode:
> > > 		* No measurements are performed
> > > 		* Minimal power consumption
> > >=20
> > > So, in my opinion this device is already power managed.
> > > Comments ? =20
> >=20
> > It seems like there is little purpose in sleep mode, are there power
> > numbers to indicate what 'minimal' means here? =20
>=20
> There are no such statistics described in the datasheet, neither is
> after how much time does the sensor goes automatically to sleep!
> Maybe in coming revision, not sure though.
>=20
> > >=20
> > > 3. Adding more sysfs interface:
> > > -------------------------------
> > >=20
> > > Currently in the driver I have supplied default values to the sensor
> > > at probe which are:
> > >=20
> > >         data->heater_temp =3D 320; /* degree Celsius */
> > >         data->heater_dur =3D 150;  /* milliseconds */
> > >=20
> > > Now, these values are:
> > >=20
> > > 1. Target heater temperature for the heater plate to be supplied for =
the
> > >    sensor. This value can be supplied by the user and value should lie
> > >    typically between 200 =C2=B0C and 400 =C2=B0C.
> > > 2. Target heater duration time for which heater plate would be heated
> > >    before initiating gas sensing measurements. Value lying between
> > >    200-4032ms.
> > >=20
> > > But there is a caveat!
> > > If the sensor doesn't get the right combination of above two values, =
if
> > > will likely abort since:
> > > [ comment from the current code ]
> > >        =20
> > > 	/*
> > >          * occurs if either the gas heating duration was insuffient
> > >          * to reach the target heater temperature or the target
> > >          * heater temperature was too high for the heater sink to
> > >          * reach.
> > >          */
> > >=20
> > > So, what should be the appropriate channel types for these two
> > > interfaces ? =20
> >=20
> > Hmm. I guess this issue here is that the temperature rise time is
> > dependent on the environment (moisture / temperature etc) so we can't
> > do the obvious and just put in reasonable defaults (assuming the temper=
ature
> > is the only controlled channel).  =20
>=20
> Yes, gas sensor in influenced by the temperature channel and yes, of
> course, on the environment. I experienced this behavior while testing,
> that if you solely take gas readings(with say some improper combination
> of heater temp & duration) then it would a few iterations to fetch
> readings. On the other hand, if done in T->P->H->G fashion then its more
> likely failsafe. Ultimately it helps in reaching the target temperature
> easily.
>=20
> As a sidenote: in the code there is a macro for ambient temperature
> =09
> 	#define BME680_AMB_TEMP                         25
>=20
> and should be changed according to the environment.

That one should probably have a userspace control then I guess.

>=20
> > I wonder if we can get 'close' enough and retry a few times if we get
> > an abort? =20
>=20
> Yes! Infact I thought of retrying, for say about 10 iterations(in my
> case) but later the default values worked perfectly fine. Testing from we=
ll
> Air Conditioned room to deadly 47 degC New Delhi heat ;)
>=20
> > > I had the same question on my RFC patch and Matt Ranostay suggested[2]
> > >=20
> > > 	"Just use IIO_TEMP and signal it is an output channel."
> > >=20
> > > Now, I clearly doesn't understand the rationale behind the channel ty=
pe?
> > > And what does direction(input/output) signify ? =20
> >=20
> > input is something you read, output is something that is forced.  So
> > in this case you are literally setting the temperature of the plate.
> >=20
> > It's not a perfect interface for this, but it is compliant with the ABI
> > and reasonably obvious what it is doing to anyone who is familiar with
> > this sort of sensor. =20
>=20
> Ah, I also had attributes to supply oversampling ratio for temp,
> press & humid channels from userspace. So, does that make it an output
> channel ? Forcing ?

I'm not sure I see the connection to oversampling ratio etc. Those
are about measurement, this one is about outputting heat (hence=20
output).  The fact it is internal to the sensor, doesn't effect this.

>=20
> > > Anyway, digging further I found that Matt had a slighlty similar situ=
ation
> > > in 'TI HDC100x temperature + humidity sensors' driver, where it was
> > > required to enable heater to drive condensation off the sensor. And M=
att
> > > used:
> > >=20
> > >                 .type =3D IIO_CURRENT,
> > >                 .info_mask_separate =3D BIT(IIO_CHAN_INFO_RAW),
> > >                 .extend_name =3D "heater",
> > >                 .output =3D 1,
> > >                 .scan_index =3D -1,
> > >=20
> > > IIO_CURRENT ? And .output =3D 1, ? Please shed some insight on this.
> > > And why was extended_name necessary here and creating a new ABI. We
> > > already had an ABI to handle such situation: =20
> >=20
> > In this case it is a rather more stupid device and all you control is
> > the current output that feeds the heater.
> >  =20
> > >=20
> > > Documentation/ABI/testing/sysfs-bus-iio
> > >=20
> > > What:           /sys/bus/iio/devices/iio:deviceX/heater_enable
> > > KernelVersion:  4.1.0
> > > Contact:        linux-iio@vger.kernel.org
> > > Description:
> > >                 '1' (enable) or '0' (disable) specifying the enable
> > >                 of heater function. Same reading values apply
> > >                 This ABI is especially applicable for humidity sensors
> > >                 to heatup the device and get rid of any condensation
> > >                 in some humidity environment
> > >=20
> > > Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x
> > >=20
> > > What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_r=
aw
> > > What:           /sys/bus/iio/devices/iio:deviceX/out_current_heater_r=
aw_available
> > > KernelVersion:  4.3=20
> > > Contact:        linux-iio@vger.kernel.org
> > > Description:
> > >                 Controls the heater device within the humidity sensor=
 to get=20
> > >                 rid of excess condensation.
> > >=20
> > >                 Valid control values are 0 =3D OFF, and 1 =3D ON.=20
> > >=20
> > > Was this necessary ? =20
> >=20
> > That does seem like somewhat of a mess.  We shouldn't have ended up wit=
h both
> > ABIs, but now we are stuck with them. =20
>=20
> Fine.
>=20
> > > Just curious about these information. It will help me decide how shou=
ld
> > > I proceed further. =20
> >=20
> > The heater enable doesn't make sense here as you have a range of values
> > rather than a boolean.  Hence the second one would be valid if you were=
 controlling
> > the current.  As it is a target temperature, it'll need to be a tempera=
ture
> > channel with more docs added to explain what it is. =20
>=20
> Hmm. For heater duration we are supplying time(ms)
> And out_current_heater_raw is definitely not valid here.
> Still unsure about the channel type and the corresponding
> sysfs entry.

Indeed not for the time.  The target temperature is fair enough as a channe=
l.
Ideally I'd like to get rid of the time as there is no real way for userspa=
ce
to 'guess' it right.  Just set it big enough that it is always fine perhaps?

>=20
> > > 4. Algorith behind Compensation functions:
> > > ------------------------------------------
> > >=20
> > > Jonathan suggested[3] to reverse engineer the compensation function a=
nd
> > > document the equation/algorithm.
> > >=20
> > > But the compensation are really complex calculations, and I will try =
to
> > > decipher if possible. =20
> >=20
> > This is more for interest of anyone coming along later than anything el=
se ;)
> >  =20
> > >=20
> > > As a better solution, I contacted Bosch Sensortec again for the
> > > algorithm and let's hope they reply back soon. I don't have a direct
> > > contact to Bosch developers but to someone at their office. So, it ta=
kes
> > > a while to get constructive feedback. =20
> >=20
> > That would be great if they'll provide the info!  Maybe we can even
> > persuade them to put it in an updated data sheet or an app note or simi=
lar! =20
>=20
> I got a reply from them about the formula they use to calculate the IAQ
> but not how compensation function is designed.
>=20
> Will forward the email after their permission as the background
> watermark text in the formula image says "Confidential!!"
> Sometimes you need to be careful ;)

Sure.  Check that first!

>=20
> > > Thanks Jonathan, Daniel, Matt, Andy, David and all the reviewers. It =
was
> > > truly a great experience and would need your patience and help for so=
me
> > > more time :) =20
> >=20
> > You are welcome and hope you stay around the kernel in the future! =20
>=20
> I am certainly around for a year until I graduate and not sure about
> the future :)
>=20
Well best of luck both in this year and afterwards.

Jonathan

Re: Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

> > Ah, I also had attributes to supply oversampling ratio for temp,
> > press & humid channels from userspace. So, does that make it an output
> > channel ? Forcing ?
> 
> I'm not sure I see the connection to oversampling ratio etc. Those
> are about measurement, this one is about outputting heat (hence 
> output).  The fact it is internal to the sensor, doesn't effect this.

I get it!

> > Hmm. For heater duration we are supplying time(ms)
> > And out_current_heater_raw is definitely not valid here.
> > Still unsure about the channel type and the corresponding
> > sysfs entry.
> 
> Indeed not for the time.  The target temperature is fair enough as a channel.
> Ideally I'd like to get rid of the time as there is no real way for userspace
> to 'guess' it right.  Just set it big enough that it is always fine perhaps?

That's what "default values" are -- supplied at probe!
The defaults are suggested by Bosch, so that is indeed best combination
I guess.

> > Will forward the email after their permission as the background
> > watermark text in the formula image says "Confidential!!"
> > Sometimes you need to be careful ;)
> 
> Sure.  Check that first!

"Thank you for your question.

No, unfortunately you cannot share that information. Generally we only deliver BSEC library package.

Only NDA customer could be shared with such information."
	--- reply from Bosch

So, I cannot share the info and it wasn't what we need.
Instead it was about calculating IAQ index from the raw values that
we get from the sensor.

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Buffert trigger and Power management support for BME680 ?

[David Frey]

On 7/30/2018 6:07 AM, Jonathan Cameron wrote:
> On Mon, 30 Jul 2018 17:42:41 +0530
> Himanshu Jha <himanshujha199640@gmail.com> wrote:
> 
>> Hi,
>>
>> The initial minimal driver has been recently merged[1] and irrespective
>> of the ending week of Google Summer of Code'18, I would like to extend this
>> driver and work on it.
>>
>> I have a few queries for the community:
>>
>> 1. Buffered Trigger Support:
>> ----------------------------
>>
>> Is it worth to add buffer support for this device ?
>> The device has 1Hz Forced mode which we need to enable everytime
>> we need a reading.
>>
>> Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries for
>> different platforms, and the software has various modes:
>>
>> 	* Ultra-low power mode.
>> 	* Ultra-low power mode.
>> 	* Continuous mode.
>>
>> According to datasheet "1.2 Gas sensor specification"
>>
>> Response time		Continuous mode		0.75s
>>
>> Now, these details are worth noting and confusing at the same to me!
>> Since, we only have 1Hz mode, so would it be a problem when adding this
>> interface to get continuous measurements ?
>> What other factors/caveats should I look for before proceeding further ?
> 
> Technically there is no problem with adding buffered mode, but there may
> be no real usecases at these very low rates.
> 
> The main convenience is that you could read out the various channels in one
> pass (I think - haven't checked the datasheet).

I think that buffered mode is essential because it will allow TPHG to be 
done all at once.  If you measure TPHG with the current driver, you are 
doing 4 measurements.  This is bad because it takes longer, uses more 
power, the values all have slightly different timestamps.


>> 2. Power Management:
>> -------------------
>>
>> 3.1 Sensor modes
>>
>> 	Forced mode:
>> 		* Single TPHG cycle is performed
>> 		* Sensor *automatically* returns to sleep mode afterwards
>> 		* Gas sensor heater only operates during gas measurement
>> 	Sleep mode:
>> 		* No measurements are performed
>> 		* Minimal power consumption
>>
>> So, in my opinion this device is already power managed.
>> Comments ?
> 
> It seems like there is little purpose in sleep mode, are there power
> numbers to indicate what 'minimal' means here?

 From the datasheet on page 3:
   Current consumption
     2.1 μA at 1 Hz humidity and temperature
     3.1 μA at 1 Hz pressure and temperature
     3.7 μA at 1 Hz humidity, pressure and temperature
     0.09‒12 mA for p/h/T/gas depending on operation mode
     0.15 μA in sleep mode

My interpretation of this is that you will consume 2.1 μA on average if 
you are reading the humidity and temperature once per second.  The 
datasheet goes into some more detail in Table 2 on page 8 where it 
describes the average supply current of the gas sensor as follows:
   Ultra-low power mode 0.09 ma with response time of 92 s
   Low power mode 0.9 mA with a response time of 1.4 s
   Continuous mode 12 mA with a response time of 0.75 s

I don't think there are actually different modes at all.  I believe what 
they call modes are just different settings corresponding to enum values 
in the BSEC library.  Maybe I'm wrong though.  Please correct me if you 
see any evidence of explicit mode settings.  I'm also skeptical of the 
current consumption numbers.  It seems weird to me that continuous mode 
consumes > 10x the current of low power mode and only produces roughly 
twice as many readings.

It's nice to see this driver progressing.  Keep up the good work!

Re: Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

On Fri, Aug 03, 2018 at 09:14:27AM -0700, David Frey wrote:
> On 7/30/2018 6:07 AM, Jonathan Cameron wrote:
> > On Mon, 30 Jul 2018 17:42:41 +0530
> > Himanshu Jha <himanshujha199640@gmail.com> wrote:
> > 
> > > Hi,
> > > 
> > > The initial minimal driver has been recently merged[1] and irrespective
> > > of the ending week of Google Summer of Code'18, I would like to extend this
> > > driver and work on it.
> > > 
> > > I have a few queries for the community:
> > > 
> > > 1. Buffered Trigger Support:
> > > ----------------------------
> > > 
> > > Is it worth to add buffer support for this device ?
> > > The device has 1Hz Forced mode which we need to enable everytime
> > > we need a reading.
> > > 
> > > Bosch provides[1] BSEC: Bosch Software Environmental Cluster binaries for
> > > different platforms, and the software has various modes:
> > > 
> > > 	* Ultra-low power mode.
> > > 	* Ultra-low power mode.
> > > 	* Continuous mode.
> > > 
> > > According to datasheet "1.2 Gas sensor specification"
> > > 
> > > Response time		Continuous mode		0.75s
> > > 
> > > Now, these details are worth noting and confusing at the same to me!
> > > Since, we only have 1Hz mode, so would it be a problem when adding this
> > > interface to get continuous measurements ?
> > > What other factors/caveats should I look for before proceeding further ?
> > 
> > Technically there is no problem with adding buffered mode, but there may
> > be no real usecases at these very low rates.
> > 
> > The main convenience is that you could read out the various channels in one
> > pass (I think - haven't checked the datasheet).
> 
> I think that buffered mode is essential because it will allow TPHG to be
> done all at once.  If you measure TPHG with the current driver, you are
> doing 4 measurements.  This is bad because it takes longer, uses more power,
> the values all have slightly different timestamps.

Agreed! The buffer mode can be thought of as while(1) {} of what Bosch does
in their userspace driver. But we need remember that every time we need to
set FORCED mode to trigger measurement. And due to this discussion I was
temped to download BSEC and look upon the code. Seems like we have a lot
interesting things buried there unlike datasheet.

For instance:

At example/bsec_integration.c

<snip>
    /* When the measurement is completed and data is ready for reading, the sensor must be in BME680_SLEEP_MODE.
     * Read operation mode to check whether measurement is completely done and wait until the sensor is no more
     * in BME680_FORCED_MODE. */
    while (bme680_g.power_mode == BME680_FORCED_MODE)
    {
        /* sleep for 5 ms */
        sleep(5);
        bme680_status = bme680_get_sensor_mode(&bme680_g);
    }
</snip>

And many more interesting stuff...

I mean they also have:

<snip>

typedef	enum {
...   
   /**
     * @brief Sensor heat compensated humidity [%]
     *
     * Relative measured by BME680 which is compensated for the influence of sensor (heater) in %.
     *
     * It converts the ::BSEC_INPUT_HUMIDITY from temperature ::BSEC_INPUT_TEMPERATURE to temperature
     * ::BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_TEMPERATURE.
     *
     * @note IAQ solution: If ::BSEC_INPUT_HEATSOURCE is used for device specific temperature compensation, it will be
     * effective for ::BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_HUMIDITY too.
     */
    BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_HUMIDITY = 15,
...
} bsec_virtual_sensor_t;

</snip>

Their design for high precision readings is just flawless!

I need some time to get ideas so as to start with buffer support.

But what kind of buffer support should be used ?
sysfs trigger using scan_elements ?

There are no interrupt supported by the sensor! And I don't know
how hrtimer would work.

Another question arises, say for eg., we use sysfs trigger and buffer
capture comes in action:

* Would I enable FORCED mode everytime in the trigger interrupt handler ?
* Also check for config setting(such as oversampling) and set
  them accordingly in the interrupt handler ?

If no, then other suggestion ?
If yes, isn't that bad to do all that in "bottom half" ?

I thought of preenable, but it works only 'once' prior to enabling but
we need to set mode every time!

> > > 2. Power Management:
> > > -------------------
> > > 
> > > 3.1 Sensor modes
> > > 
> > > 	Forced mode:
> > > 		* Single TPHG cycle is performed
> > > 		* Sensor *automatically* returns to sleep mode afterwards
> > > 		* Gas sensor heater only operates during gas measurement
> > > 	Sleep mode:
> > > 		* No measurements are performed
> > > 		* Minimal power consumption
> > > 
> > > So, in my opinion this device is already power managed.
> > > Comments ?
> > 
> > It seems like there is little purpose in sleep mode, are there power
> > numbers to indicate what 'minimal' means here?
> 
> From the datasheet on page 3:
>   Current consumption
>     2.1 μA at 1 Hz humidity and temperature
>     3.1 μA at 1 Hz pressure and temperature
>     3.7 μA at 1 Hz humidity, pressure and temperature
>     0.09‒12 mA for p/h/T/gas depending on operation mode
>     0.15 μA in sleep mode
> 
> My interpretation of this is that you will consume 2.1 μA on average if you
> are reading the humidity and temperature once per second.  The datasheet
> goes into some more detail in Table 2 on page 8 where it describes the
> average supply current of the gas sensor as follows:
>   Ultra-low power mode 0.09 ma with response time of 92 s
>   Low power mode 0.9 mA with a response time of 1.4 s
>   Continuous mode 12 mA with a response time of 0.75 s
> 
> I don't think there are actually different modes at all.  I believe what
> they call modes are just different settings corresponding to enum values in
> the BSEC library.  Maybe I'm wrong though.  Please correct me if you see any
> evidence of explicit mode settings.  I'm also skeptical of the current
> consumption numbers.  It seems weird to me that continuous mode consumes >
> 10x the current of low power mode and only produces roughly twice as many
> readings.

Yes, corrcect! Please don't get confused between only two modes of sensor
and "modes of BSEC". BSEC is different story ...

BSEC = Userspace Bosch driver API + IAQ alogithms + very smart subroutines ;)

> It's nice to see this driver progressing.  Keep up the good work!

Thanks! Would need your help with its development.

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Buffert trigger and Power management support for BME680 ?

[Jonathan Cameron]

On Sat, 4 Aug 2018 20:06:20 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> On Fri, Aug 03, 2018 at 09:14:27AM -0700, David Frey wrote:
> > On 7/30/2018 6:07 AM, Jonathan Cameron wrote: =20
> > > On Mon, 30 Jul 2018 17:42:41 +0530
> > > Himanshu Jha <himanshujha199640@gmail.com> wrote:
> > >  =20
> > > > Hi,
> > > >=20
> > > > The initial minimal driver has been recently merged[1] and irrespec=
tive
> > > > of the ending week of Google Summer of Code'18, I would like to ext=
end this
> > > > driver and work on it.
> > > >=20
> > > > I have a few queries for the community:
> > > >=20
> > > > 1. Buffered Trigger Support:
> > > > ----------------------------
> > > >=20
> > > > Is it worth to add buffer support for this device ?
> > > > The device has 1Hz Forced mode which we need to enable everytime
> > > > we need a reading.
> > > >=20
> > > > Bosch provides[1] BSEC: Bosch Software Environmental Cluster binari=
es for
> > > > different platforms, and the software has various modes:
> > > >=20
> > > > 	* Ultra-low power mode.
> > > > 	* Ultra-low power mode.
> > > > 	* Continuous mode.
> > > >=20
> > > > According to datasheet "1.2 Gas sensor specification"
> > > >=20
> > > > Response time		Continuous mode		0.75s
> > > >=20
> > > > Now, these details are worth noting and confusing at the same to me!
> > > > Since, we only have 1Hz mode, so would it be a problem when adding =
this
> > > > interface to get continuous measurements ?
> > > > What other factors/caveats should I look for before proceeding furt=
her ? =20
> > >=20
> > > Technically there is no problem with adding buffered mode, but there =
may
> > > be no real usecases at these very low rates.
> > >=20
> > > The main convenience is that you could read out the various channels =
in one
> > > pass (I think - haven't checked the datasheet). =20
> >=20
> > I think that buffered mode is essential because it will allow TPHG to be
> > done all at once.  If you measure TPHG with the current driver, you are
> > doing 4 measurements.  This is bad because it takes longer, uses more p=
ower,
> > the values all have slightly different timestamps. =20
>=20
> Agreed! The buffer mode can be thought of as while(1) {} of what Bosch do=
es
> in their userspace driver. But we need remember that every time we need to
> set FORCED mode to trigger measurement. And due to this discussion I was
> temped to download BSEC and look upon the code. Seems like we have a lot
> interesting things buried there unlike datasheet.
>=20
> For instance:
>=20
> At example/bsec_integration.c
>=20
> <snip>
>     /* When the measurement is completed and data is ready for reading, t=
he sensor must be in BME680_SLEEP_MODE.
>      * Read operation mode to check whether measurement is completely don=
e and wait until the sensor is no more
>      * in BME680_FORCED_MODE. */
>     while (bme680_g.power_mode =3D=3D BME680_FORCED_MODE)
>     {
>         /* sleep for 5 ms */
>         sleep(5);
>         bme680_status =3D bme680_get_sensor_mode(&bme680_g);
>     }
> </snip>
>=20
> And many more interesting stuff...
>=20
> I mean they also have:
>=20
> <snip>
>=20
> typedef	enum {
> ...  =20
>    /**
>      * @brief Sensor heat compensated humidity [%]
>      *
>      * Relative measured by BME680 which is compensated for the influence=
 of sensor (heater) in %.
>      *
>      * It converts the ::BSEC_INPUT_HUMIDITY from temperature ::BSEC_INPU=
T_TEMPERATURE to temperature
>      * ::BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_TEMPERATURE.
>      *
>      * @note IAQ solution: If ::BSEC_INPUT_HEATSOURCE is used for device =
specific temperature compensation, it will be
>      * effective for ::BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_HUMIDITY too.
>      */
>     BSEC_OUTPUT_SENSOR_HEAT_COMPENSATED_HUMIDITY =3D 15,
> ...
> } bsec_virtual_sensor_t;
>=20
> </snip>
>=20
> Their design for high precision readings is just flawless!
>=20
> I need some time to get ideas so as to start with buffer support.
>=20
> But what kind of buffer support should be used ?
> sysfs trigger using scan_elements ?
>=20
> There are no interrupt supported by the sensor! And I don't know
> how hrtimer would work.

Is it possible to poll for new data?  I.e. is there an explicit
way of telling you are looking at a complete set of different data
from what you got on the previous reading?

It is unusual, but we do have a few other drivers where this is
necessary and some interesting dances to ensure they lock as closely
as possible with the actual sampling frequencies.

>=20
> Another question arises, say for eg., we use sysfs trigger and buffer
> capture comes in action:
>=20
> * Would I enable FORCED mode everytime in the trigger interrupt handler ?
> * Also check for config setting(such as oversampling) and set
>   them accordingly in the interrupt handler ?
>=20
> If no, then other suggestion ?
> If yes, isn't that bad to do all that in "bottom half" ?

The bottom half in this case is an interrupt thread so you can do what
ever you like in it.

>=20
> I thought of preenable, but it works only 'once' prior to enabling but
> we need to set mode every time!

Sounds like that might be necessary. I haven't read the datasheet
for a while and as you say it isn't always that informative!

>=20
> > > > 2. Power Management:
> > > > -------------------
> > > >=20
> > > > 3.1 Sensor modes
> > > >=20
> > > > 	Forced mode:
> > > > 		* Single TPHG cycle is performed
> > > > 		* Sensor *automatically* returns to sleep mode afterwards
> > > > 		* Gas sensor heater only operates during gas measurement
> > > > 	Sleep mode:
> > > > 		* No measurements are performed
> > > > 		* Minimal power consumption
> > > >=20
> > > > So, in my opinion this device is already power managed.
> > > > Comments ? =20
> > >=20
> > > It seems like there is little purpose in sleep mode, are there power
> > > numbers to indicate what 'minimal' means here? =20
> >=20
> > From the datasheet on page 3:
> >   Current consumption
> >     2.1 =CE=BCA at 1 Hz humidity and temperature
> >     3.1 =CE=BCA at 1 Hz pressure and temperature
> >     3.7 =CE=BCA at 1 Hz humidity, pressure and temperature
> >     0.09=E2=80=9212 mA for p/h/T/gas depending on operation mode
> >     0.15 =CE=BCA in sleep mode
> >=20
> > My interpretation of this is that you will consume 2.1 =CE=BCA on avera=
ge if you
> > are reading the humidity and temperature once per second.  The datasheet
> > goes into some more detail in Table 2 on page 8 where it describes the
> > average supply current of the gas sensor as follows:
> >   Ultra-low power mode 0.09 ma with response time of 92 s
> >   Low power mode 0.9 mA with a response time of 1.4 s
> >   Continuous mode 12 mA with a response time of 0.75 s
> >=20
> > I don't think there are actually different modes at all.  I believe what
> > they call modes are just different settings corresponding to enum value=
s in
> > the BSEC library.  Maybe I'm wrong though.  Please correct me if you se=
e any
> > evidence of explicit mode settings.  I'm also skeptical of the current
> > consumption numbers.  It seems weird to me that continuous mode consume=
s >
> > 10x the current of low power mode and only produces roughly twice as ma=
ny
> > readings. =20
>=20
> Yes, corrcect! Please don't get confused between only two modes of sensor
> and "modes of BSEC". BSEC is different story ...
>=20
> BSEC =3D Userspace Bosch driver API + IAQ alogithms + very smart subrouti=
nes ;)
>=20
> > It's nice to see this driver progressing.  Keep up the good work! =20
>=20
> Thanks! Would need your help with its development.
>=20

Indeed good to see this continue to move forwards.

Jonathan

Re: Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

> > Their design for high precision readings is just flawless!
> > 
> > I need some time to get ideas so as to start with buffer support.
> > 
> > But what kind of buffer support should be used ?
> > sysfs trigger using scan_elements ?
> > 
> > There are no interrupt supported by the sensor! And I don't know
> > how hrtimer would work.
> 
> Is it possible to poll for new data?  I.e. is there an explicit
> way of telling you are looking at a complete set of different data
> from what you got on the previous reading?

Yes, we have such facility:

5.3.5.1 New data status

The measured data are stored into the output data registers at the
end of each TPHG conversion phase along with status
flags and index of measurement.

register	addr	bit pos		description
meas_status_0	0x1D	new_data_0<7>	New data flag

And why do you ask ?

> It is unusual, but we do have a few other drivers where this is
> necessary and some interesting dances to ensure they lock as closely
> as possible with the actual sampling frequencies.

The various problems for buffer support that I can see are:

o The press, temp have 20(8+8+4) bits resolution but humidity has 16 bits.
  And then gas is 10 bits resolution(8 MSB + 2 LSB).

o Non-linear addressing:				decimal
	BME680_REG_TEMP_MSB                     0x22	34
	BME680_REG_PRESS_MSB                    0x1F	31
	BM6880_REG_HUMIDITY_MSB                 0x25	37
	BME680_REG_GAS_MSB                      0x2A	42
 
 Otherwise we could do large bulk read and push to buffer.

o Every time setting FORCED MODE to trigger measurement but then looking
  at the following from BSEC makes me wonder:

     /* When the measurement is completed and data is ready for reading, the sensor must be in BME680_SLEEP_MODE.
      * Read operation mode to check whether measurement is completely done and wait until the sensor is no more
      * in BME680_FORCED_MODE. */
	while (bme680_g.power_mode == BME680_FORCED_MODE)
	{
		/* sleep for 5 ms */
		sleep(5);
		bme680_status = bme680_get_sensor_mode(&bme680_g);
	}

 Clearly, you wouldn't want this in interrupt handler, so we will
 overwrite mode irrespective of current mode and avoid those checks.

o And lastly compensation functions, we wouldn't pass raw values and
  instead processed instead. Isn't ?

So, now I see all these reading, setting config, checking bits,
processing and finally pushing in an interrupt handler. Is this
what shall be done ?

I'm asking too many questions because I don't want to waste my time
doing wrong and getting a NACK in the end. Also, I have another huge
project currently to focus by Linux Foundation.

But I'm happy to review and test patches anytime.

> > Another question arises, say for eg., we use sysfs trigger and buffer
> > capture comes in action:
> > 
> > * Would I enable FORCED mode everytime in the trigger interrupt handler ?
> > * Also check for config setting(such as oversampling) and set
> >   them accordingly in the interrupt handler ?
> > 
> > If no, then other suggestion ?
> > If yes, isn't that bad to do all that in "bottom half" ?
> 
> The bottom half in this case is an interrupt thread so you can do what
> ever you like in it.

Hmm. OK
I have a different vision for top/bottom half.
 
> > I thought of preenable, but it works only 'once' prior to enabling but
> > we need to set mode every time!
> 
> Sounds like that might be necessary. I haven't read the datasheet
> for a while and as you say it isn't always that informative!

Yes, it is for the current revision.

> > > It's nice to see this driver progressing.  Keep up the good work!  
> > 
> > Thanks! Would need your help with its development.
> > 
> 
> Indeed good to see this continue to move forwards.

Well, as soon I saw BSEC, I realised I've done nothing and people would
prefer BSEC.

But on the other hand, I was contacted by one Croatian developer who
is backporting my driver to the their kernel since they are stuck
with 4.14 and the product is already in assembly stage.

David also has a similar issue.

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: Buffert trigger and Power management support for BME680 ?

[Jonathan Cameron]

On Sun, 19 Aug 2018 00:01:50 +0530
Himanshu Jha <himanshujha199640@gmail.com> wrote:

> > > Their design for high precision readings is just flawless!
> > > 
> > > I need some time to get ideas so as to start with buffer support.
> > > 
> > > But what kind of buffer support should be used ?
> > > sysfs trigger using scan_elements ?
> > > 
> > > There are no interrupt supported by the sensor! And I don't know
> > > how hrtimer would work.  
> > 
> > Is it possible to poll for new data?  I.e. is there an explicit
> > way of telling you are looking at a complete set of different data
> > from what you got on the previous reading?  
> 
> Yes, we have such facility:
> 
> 5.3.5.1 New data status
> 
> The measured data are stored into the output data registers at the
> end of each TPHG conversion phase along with status
> flags and index of measurement.
> 
> register	addr	bit pos		description
> meas_status_0	0x1D	new_data_0<7>	New data flag
> 
> And why do you ask ?

Because it lets you use a timer / thread in the drive to emulate
a trigger interrupt (be it in a fairly nasty fashion).
> 
> > It is unusual, but we do have a few other drivers where this is
> > necessary and some interesting dances to ensure they lock as closely
> > as possible with the actual sampling frequencies.  
> 
> The various problems for buffer support that I can see are:
> 
> o The press, temp have 20(8+8+4) bits resolution but humidity has 16 bits.
>   And then gas is 10 bits resolution(8 MSB + 2 LSB).
> 
> o Non-linear addressing:				decimal
> 	BME680_REG_TEMP_MSB                     0x22	34
> 	BME680_REG_PRESS_MSB                    0x1F	31
> 	BM6880_REG_HUMIDITY_MSB                 0x25	37
> 	BME680_REG_GAS_MSB                      0x2A	42
>  
>  Otherwise we could do large bulk read and push to buffer.

Yes, you'll need to shuffle the data around to get all aligned.

> 
> o Every time setting FORCED MODE to trigger measurement but then looking
>   at the following from BSEC makes me wonder:
> 
>      /* When the measurement is completed and data is ready for reading, the sensor must be in BME680_SLEEP_MODE.
>       * Read operation mode to check whether measurement is completely done and wait until the sensor is no more
>       * in BME680_FORCED_MODE. */
> 	while (bme680_g.power_mode == BME680_FORCED_MODE)
> 	{
> 		/* sleep for 5 ms */
> 		sleep(5);
> 		bme680_status = bme680_get_sensor_mode(&bme680_g);
> 	}
> 
>  Clearly, you wouldn't want this in interrupt handler, so we will
>  overwrite mode irrespective of current mode and avoid those checks.
You could have this in a thread.  Don't worry about anything in an interrupt
thread taking ages as it doesn't block anything from preempting the thread.

> 
> o And lastly compensation functions, we wouldn't pass raw values and
>   instead processed instead. Isn't ?

Now this is always awkward on devices with complex non linear functions
from raw to actual units.

I'm not sure it would be any use to output raw data in this case
so we would have to look at whether we can generate a packing without
loosing any precision of the final data.  It would probably have to be
'sort of raw' to give us the multipliers to do fixed point values.

We are looking at allowing a floating point output, but getting to that
in driver is going to be more than a little fiddly.  The intent is that
it is only really for cases where the device itself is outputting floating
point and we just pass it along...
> 
> So, now I see all these reading, setting config, checking bits,
> processing and finally pushing in an interrupt handler. Is this
> what shall be done ?
> 
> I'm asking too many questions because I don't want to waste my time
> doing wrong and getting a NACK in the end. Also, I have another huge
> project currently to focus by Linux Foundation.

The question is whether synchronized readings are needed across the channels.
If they are there is no other way of presenting them so we would need buffered
results.  If only nearly synchronized is fine then no point in bothering.

> 
> But I'm happy to review and test patches anytime.
> 
> > > Another question arises, say for eg., we use sysfs trigger and buffer
> > > capture comes in action:
> > > 
> > > * Would I enable FORCED mode everytime in the trigger interrupt handler ?
> > > * Also check for config setting(such as oversampling) and set
> > >   them accordingly in the interrupt handler ?
> > > 
> > > If no, then other suggestion ?
> > > If yes, isn't that bad to do all that in "bottom half" ?  
> > 
> > The bottom half in this case is an interrupt thread so you can do what
> > ever you like in it.  
> 
> Hmm. OK
> I have a different vision for top/bottom half.

For this sort of slow device (and quite a lot of quick ones) the traditional
top half / bottom half is long gone in favour of a light top half then waking
up a preemptible thread to do the stuff that used to be in the bottom half.
This means things like sleeping are fine.

>  
> > > I thought of preenable, but it works only 'once' prior to enabling but
> > > we need to set mode every time!  
> > 
> > Sounds like that might be necessary. I haven't read the datasheet
> > for a while and as you say it isn't always that informative!  
> 
> Yes, it is for the current revision.
> 
> > > > It's nice to see this driver progressing.  Keep up the good work!    
> > > 
> > > Thanks! Would need your help with its development.
> > >   
> > 
> > Indeed good to see this continue to move forwards.  
> 
> Well, as soon I saw BSEC, I realised I've done nothing and people would
> prefer BSEC.
> 
> But on the other hand, I was contacted by one Croatian developer who
> is backporting my driver to the their kernel since they are stuck
> with 4.14 and the product is already in assembly stage.
> 
> David also has a similar issue.
> 

Yes these devices are really fiddly.  What you have gets people started
but if they want to do all the bells and whistles they are going to end
up having to use something much more sophisticated to post process
the data.

Anyhow, good to know there are users of a sort (even if they tweak it
to get the data into something that can be hammered into the userspace
libraries.

Jonathan

Re: Buffert trigger and Power management support for BME680 ?

[Himanshu Jha]

On Sun, Aug 19, 2018 at 08:28:16PM +0100, Jonathan Cameron wrote:
> On Sun, 19 Aug 2018 00:01:50 +0530
> Himanshu Jha <himanshujha199640@gmail.com> wrote:
> 
> > > > Their design for high precision readings is just flawless!
> > > > 
> > > > I need some time to get ideas so as to start with buffer support.
> > > > 
> > > > But what kind of buffer support should be used ?
> > > > sysfs trigger using scan_elements ?
> > > > 
> > > > There are no interrupt supported by the sensor! And I don't know
> > > > how hrtimer would work.  
> > > 
> > > Is it possible to poll for new data?  I.e. is there an explicit
> > > way of telling you are looking at a complete set of different data
> > > from what you got on the previous reading?  
> > 
> > Yes, we have such facility:
> > 
> > 5.3.5.1 New data status
> > 
> > The measured data are stored into the output data registers at the
> > end of each TPHG conversion phase along with status
> > flags and index of measurement.
> > 
> > register	addr	bit pos		description
> > meas_status_0	0x1D	new_data_0<7>	New data flag
> > 
> > And why do you ask ?
> 
> Because it lets you use a timer / thread in the drive to emulate
> a trigger interrupt (be it in a fairly nasty fashion).

OK.
Actually Matt gave me reference to his PulsedLight LIDAR sensor
driver as a refernece for buffer support and the same suggestion
was provided by Daniel during GSoC.

So, now I will try and test because

	"Talk is cheap. Show me the code."

> > o Every time setting FORCED MODE to trigger measurement but then looking
> >   at the following from BSEC makes me wonder:
> > 
> >      /* When the measurement is completed and data is ready for reading, the sensor must be in BME680_SLEEP_MODE.
> >       * Read operation mode to check whether measurement is completely done and wait until the sensor is no more
> >       * in BME680_FORCED_MODE. */
> > 	while (bme680_g.power_mode == BME680_FORCED_MODE)
> > 	{
> > 		/* sleep for 5 ms */
> > 		sleep(5);
> > 		bme680_status = bme680_get_sensor_mode(&bme680_g);
> > 	}
> > 
> >  Clearly, you wouldn't want this in interrupt handler, so we will
> >  overwrite mode irrespective of current mode and avoid those checks.
> You could have this in a thread.  Don't worry about anything in an interrupt
> thread taking ages as it doesn't block anything from preempting the thread.

Thanks for the clarification.

> > o And lastly compensation functions, we wouldn't pass raw values and
> >   instead processed instead. Isn't ?
> 
> Now this is always awkward on devices with complex non linear functions
> from raw to actual units.
> 
> I'm not sure it would be any use to output raw data in this case
> so we would have to look at whether we can generate a packing without
> loosing any precision of the final data.  It would probably have to be
> 'sort of raw' to give us the multipliers to do fixed point values.

Ah yes, we can do 'sort of raw' since each channel outputs an integer
and we divide them with their respective resolutions.

So, this division can be done in userspace.

For eg: 43215 is pushed to buffer and later in userspace we divide
it by 1000(.0001 % resolution of humidity).

Also note that this 43215 is the result of "compensation function" and
raw read obtained is useless.

> We are looking at allowing a floating point output, but getting to that
> in driver is going to be more than a little fiddly.  The intent is that
> it is only really for cases where the device itself is outputting floating
> point and we just pass it along...
> > 
> > So, now I see all these reading, setting config, checking bits,
> > processing and finally pushing in an interrupt handler. Is this
> > what shall be done ?
> > 
> > I'm asking too many questions because I don't want to waste my time
> > doing wrong and getting a NACK in the end. Also, I have another huge
> > project currently to focus by Linux Foundation.
> 
> The question is whether synchronized readings are needed across the channels.
> If they are there is no other way of presenting them so we would need buffered
> results.  If only nearly synchronized is fine then no point in bothering.

Buffered support has the only advantage that we get all TPHG in one-go
without triggering measurement for each channel every time.

> > 
> > But I'm happy to review and test patches anytime.
> > 
> > > > Another question arises, say for eg., we use sysfs trigger and buffer
> > > > capture comes in action:
> > > > 
> > > > * Would I enable FORCED mode everytime in the trigger interrupt handler ?
> > > > * Also check for config setting(such as oversampling) and set
> > > >   them accordingly in the interrupt handler ?
> > > > 
> > > > If no, then other suggestion ?
> > > > If yes, isn't that bad to do all that in "bottom half" ?  
> > > 
> > > The bottom half in this case is an interrupt thread so you can do what
> > > ever you like in it.  
> > 
> > Hmm. OK
> > I have a different vision for top/bottom half.
> 
> For this sort of slow device (and quite a lot of quick ones) the traditional
> top half / bottom half is long gone in favour of a light top half then waking
> up a preemptible thread to do the stuff that used to be in the bottom half.
> This means things like sleeping are fine.

Ok.

Thanks
-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology