+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
