As part of my Sensing the World entry, I purchased an Environment Click https://www.mikroe.com/environment-click
The heart of the Click board is a Bosch BME680 environmental sensor, which can measure temperature, relative humidity, pressure and VOC content.
I wanted to share my experience using this Click Board with the Azure Sphere Starter Kit in the hope that others find it useful. Alternatively, perhaps it is some form of therapy....(read on for more information)
There is one previous example of this board being used on an Azure Sphere, https://www.hackster.io/gatoninja236/azure-sphere-weather-station-d5a2bc
The approach used there was to to read/write directly to the registers.
However Bosch provides a driver written in C to get this sensor going, and I wanted to use that. Partly this was for speed and ease of use, and partly because I also wanted to integrate the BSEC library [https://www.bosch-sensortec.com/bst/products/all_products/BSEC ] which builds on the BME680 driver and provides some additional outputs including an indoor air quality (IAQ) index.
I was initially planning to use SPI to talk to the BME680, but since the board is configured for I2C out of the box, I opted instead to use I2C.
I started with the I2C example project from the Azure Sphere Samples site [https://github.com/Azure/azure-sphere-samples].
I then added the BME680 driver [https://github.com/BoschSensortec/BME680_driver] to the project and filled in the stub user functions for I2C read/write.
Finally I followed the instructions on the BME680 GitHub page to call the driver API.
My initial experience integrating the Azure Sphere I2C example and the BME680 driver was very positive. The Azure I2C API was logical and the BME680 driver provided a high level interface to the sensor, without me needing to consult the details of the various BME680 registers in the datasheet. This was going to straight-forward.
Or so I thought.
After making the above changes, I built and ran my project to make sure the basic I2C example was working. However the values I was getting from bme680_get_sensor_data() were garbage.
And so began a tedious session of debugging, whilst I tried to determine why my simple example wasn't working. I knew that the Azure Sphere I2C libraries and hardware *must* be working, as I had previously worked through some of the tutorials using the onboard I2C sensors. Most likely the BME680 was also functioning, meaning the issue was likely my code.
Was there an endian issue? No, I ruled that possibility out.
Was I mis-reading the datasheet somewhere? I couldn't see where.
My BME680 init routine seemed to be returning all the right values, but the sensor data was definitely wrong.
Another weird behaviour I noticed, was that sometimes (but not always!) the data read from the BME680 was to be offset by one byte.
Finally after multiple days of thinking, prodding, and testing I cracked the code: there is an underlying issue with the I2C read functions in Azure Sphere 19.07.
If you read more than 8 bytes at a time, then all subsequent reads will return your requested data from offset 1 of your buffer, and the byte at offset 0 is random or rubbish.
I modified my read function to read no more than 8 bytes at a time and suddenly my temperature/humidity values started making sense.
Success at last. Hopefully this issue is resolved in later Azure Sphere updates.
The next task is to try to integrate the BSEC library to get better compensated readings...
Top Comments