Re: IIO BME680 driver

[Himanshu Jha <himanshujha199640@gmail.com>]

+Cc linux-iio & David Frey

Hi Tuukka,

On Fri, Dec 14, 2018 at 09:49:06AM +0200, Tuukka Pasanen wrote:
> Hello,
> 
> I've been testing BME680 i2c IIO driver and it works as expected (actually
> I'm very happy with it). Before that I was using BME680 lib from Pimoroni
> and only thing I'm missing is that there is user defined prefix to fix
> incorrect values that are hard coded in ROM (Can be found here):
> 
> https://github.com/pimoroni/bme680-python/blob/e827e5d622fd70df2aee6a68ebac626cf539ee55/library/bme680/__init__.py#L89

Hmm. Why would anyone want to play with those calibration constants
programmed into the NVM of the sensor.

And I wonder how the following came up ?
https://github.com/pimoroni/bme680-python/blob/e827e5d622fd70df2aee6a68ebac626cf539ee55/library/bme680/__init__.py#L331

These algorithms are provided by Bosch and probably should be used as-is
unless you got some information from them. But I don't see any such
reference in the datasheet nor in their API.

Or it might be some heuristics. Not sure about it!

> This one adjust temperature every time one reads it. For example my room
> temperature is something like 21C (I live in north) and BME680 reports 28C
> so humidity and pressure are incorrect (not much but notable).

Now since you're using IIO driver, I see the problem here:
https://github.com/torvalds/linux/blob/master/drivers/iio/chemical/bme680.h#L52

	#define BME680_AMB_TEMP				25

Yes, it is hardcoded here and you should change it to according to your
room temperature(20-21 degC).


I really like the approach of *not* harcoding the ambient temperature
and instead using the temperature sensor readout as a substitute to the
ambient temp as evident in the python api above.

But the problem lies in the organisation of IIO driver of isolating
different channels. What I simply mean is, what if I only run
gas part without any temperature sensing part ? How would you get the
ambient temperature in the case ? In such a case, we need throw a dummy
temp read in the relevant readout functions and store them in the
private struct. But then following this approach is wastage of power
and increases latency in the readings.

David had earlier pointed out if we are already wasting resources by
doing the same thing each time for each of the readings which can be
accomplished in a single readout i.e., triggering forced mode does a
single TPHG cycle and after we can read all the data. But currently we
set it each time for each of temp, press, humid and gas reading.

And only advantage I see with the current implementation is you can read
a single channel value if you want without disturbing other channels
which you can't in that python implementation.

There are two things that I shall be soon working on as soon as my
current work with Zephyr ends:

1. add profile duration function
2. check for new available data before fetching
 ... and more if anything comes up.

Anyway, Bosch ported BME680 to The Zephyr Project and I reviewed+tested
the driver on nRF52840 development board. Works great!
Though the maintainers didn't merge the PR due to lack of
those compensation algorithms in the datasheet *chuckle*

At least Jonathan(IIO maintainer) merged with a note in the commit log ;)

Bosch claimed that new datasheet shall be soon be available with all the
missing info, and then anyone wouldn't need to reverse engineer their API
or BSEC to get the desired info :P


Thank you for using the IIO driver and I'm glad that there are users out
there testing it. Please let me know if there are any more issues :)

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