IAQ Binary reading

[ernesst]

Hi, Thanks for your work, i can make work the sensor with https://github.com/alexstocker/sensorlogger

i'm currently getting binary reading on the IAQ value, as shown below :

In the living room it's giving 0.00, as soon I expose it to alcohol it jumps to 500... They is not much change in the resistance reading.

time IAQ, IAQ accuracy, raw temp, raw humidity, temp, humidity, pressure, resistance, status 2018-08-25T20:29:06Z 0.00 2 29.50 75.81 28.39 79.02 1011.51 56295 0 2018-08-25T20:29:12Z 0.00 2 29.52 76.43 28.41 80.23 1011.49 56220 0 2018-08-25T20:29:15Z 500.00 2 29.67 78.62 28.56 82.24 1011.53 53365 0 2018-08-25T20:29:18Z 500.00 2 29.64 79.20 28.53 83.30 1011.49 53162 0 2018-08-25T20:30:03Z 500.00 2 29.96 72.36 28.85 77.84 1011.53 54827 0 2018-08-25T20:30:06Z 500.00 2 29.92 71.16 28.81 76.54 1011.53 55478 0 2018-08-25T20:30:09Z 0.00 2 29.86 70.40 28.75 75.79 1011.51 55884 0 2018-08-25T20:30:12Z 0.00 2 29.82 70.00 28.71 75.35 1011.49 56637 0 2018-08-25T20:30:15Z 0.00 2 29.88 70.41 28.77 75.42 1011.53 55187 0 2018-08-25T20:30:18Z 0.00 2 29.79 71.41 28.68 76.73 1011.51 56258 0 2018-08-25T20:30:21Z 0.00 2 29.86 70.76 28.75 75.67 1011.49 53263 0 2018-08-25T20:30:24Z 500.00 2 30.31 76.77 29.20 80.37 1011.51 46800 0 2018-08-25T20:30:27Z 500.00 2 30.46 82.34 29.35 85.94 1011.57 47220 0

Any idea how to calibrate it to get linear feedback ?

[alexh-name]

Hi.

This project only implements the functions needed to start and loop the measurements by the sensor and the BSEC library and to read and output them. The results of the measurements should not be affected by anything in this project. You might be better off asking your question at Bosch's repository: https://github.com/BoschSensortec/BME680_driver

However if I had to take a guess: Your IAQ Accuracy never goes above 2, so it hasn't fully calibrated yet. Also exposing the sensor to alcohol directly justifies a value of 500, as it is very sensitive. You might want to start with a fresh state (delete or move bsec_iaq.state) and test with less aggressive methods. Let it run for some time first, then just opening a bottle of propanol or lighting a candle in the same room or opening a window should show a clear change.

[ernesst]

Great, thanks for the answer. I forgot about the existance of the .state file. Now it seems giving back relevant measurement. I shouldn't have play with alcohol ... It mostlikely saturate the sensor and break the calibration.

[alexh-name]

Hi,

after running my own sensor with BSEC 1.4.7.1 for a while, I'm noticing the same behavior. I guess there was a weird change between 1.4.7.1 and 1.4.6.0. Will have to look more into it.

[ernesst]

For me went back to "normal" Sensor located in a opened kitchen. I just didn't approach a marker next to it

[ernesst]

Yes, after a week the sensor dropped to zero reading and had a steep slope to 500. After two restarts with a .state file suppression, it seems that i'm reading back something logic.

[alexh-name]

Disabled state file reading for now: 971f2e43ca8701ce805e668e3de18bf478553a45

[ernesst]

@alexh-name

I've figure out that leaving the .state file generate what i've shown above (did you confirm ?). It seems that the BOSCH algorithm does not re-calibrate by it self. I presume the overshoot to 500 or 0 is due to the resistance change over the time.

for my use, i've figure out that removing the file once per week during a low activity (5 am - prior everybody wake up) seems to give relevant result, see below.

[alexh-name]

I observed similar behavior but did not try yet to correlate with the raw resistance. I had it running with state file reading disabled for 2 months now and it seems to give readings that look like before the bug somewhat. Strangely however, 250 seems to be the roof for the readings then. I didn't have the time to find out if that also changes the overall scale, but from what I measure day to day, readings in the spectrum for a usual desk-work environment (which I would assume is 25-150) seem normal.

I would suggest using version 1.4.6.0 for now, but the download doesn't seem to be available anymore and the license won't allow me to distribute it myself.

[funnybrum]

Same here with version 1.4.7.1 . Two sensors that are next to each other, but one running a firmware that is several months old and based on 1.4.6.0 is showing no issues. The one with 1.4.7.1 works fine for about 2 days and shows almost identical AQ values to the old onw. But after 2 days it starts showing strange AQ values (like 0 or 500).

Since I'm not the only one I guess I'll also be going back to 1.4.6.0 for now.

And a note - my setup is with ESP8266.

I've opened a bug (hopefully on the right place) for that - https://github.com/BoschSensortec/BSEC-Arduino-library/issues/38 .

[geekything]

I see the same issue after a couple of days. I'm running a Raspberry Pi Zero with the Adafruit BME680 breakout.

I've tried to contact Bosch through their contact form, but no response. I would encourage you all to also fill out the contact form on the Bosch Sensors website -- maybe someone will listen if there's enough noise.

I also chimed in on the open Issue on the BME680 driver repo.

I wish I could get 1.4.6.0 :(

[geekything]

I would also like to note that resistance readings between the "zero" and valid (once restarted with the state file removed) appear to be virtually identical. Therefore, I assume it's a bug in the calibration routines that establish a floor and ceiling for IAQ results.

[geekything]

I heard back from Bosch. I've pointed their engineer at this Issue so that he can understand a bit better what we're seeing.

[ernesst]

To mitigate this issue, saturating value and not recalibrating, i've a condition in my python script that remove the state file and force a reboot. Not the best... once every week when i know that there is no activity in the room for a long time 5am, i force a calibration by removing state file + restart.

[geekything]

I've been chatting with Bosch and running an experiment to try and reproduce the issue. Of course, now I can't reproduce it.

BUT...Bosch did explain the calibration process to me and it's possible that observing that resolves the issue.

In short:

• When you get an IAQ accuracy reading of 1 after letting it settle (from 0), expose the sensor to 30 minutes of normal air
• Then expose the air to 30 minutes of high VOCs
• You should see the IAQ accuracy reading turn to 2 whilst doing the above and eventually turn to 3

You may notice periods of zero or high readings during this process. For example, I was getting a reading of zero for air quality whilst having very high resistance.

[funnybrum]

I'm following the calibration process as specified in the docs. The first BSEC library state is being saved only if the accuracy is 3. After that the state is being saved on regular intervals (4 hours). This approach was working perfectly fine with 1.4.6.0 and is ending up with incorrect AQ values (from 0 to 500) with 1.4.7.1 .

[funnybrum]

I've been chatting with Bosch and running an experiment to try and reproduce the issue. Of course, now I can't reproduce it.

Can you please forward them to https://github.com/BoschSensortec/BSEC-Arduino-library/issues/38 ? All saved states that are leading to that issue are provided there and this should be sufficient to debug the problem.

I've tested it several times - the issue manifests only if the setState(...) is invoked. Once invoked it takes a day or two to get to the point where the AQ values are 0 or 500. Issue can be reproduced in 2 or 3 days and it consistently pops up if the setState() is invoked.

Without invoking the setState() - the sensor is running fine and no issues were observed in 10+ days.

I've currently reverted to BSEC 1.4.6.0 just because of that and the setState() works like a charm there - no issues at all.

[pwr33]

I get the same problem, it seems to do with the state file being read after a restart.

The sensor will run OK for weeks, but as soon as I do a restart and it reads the state file it foes into a flip-flop mode where IAQ just goes between 0 and 500

If I delete the state file and restart, the sensor will work OK for as long as until the next restart and read of state file.

seems quite likely an oversight by bosch, i.e. made changes to format of state file but not posting what that change is in the documentation

edit: I double checked that it is compiled using the 'Normal_version' library as it says the lite version does not do the state save, but normal version does not do it right anyway.

I also concur that it used to work OK and appeared in this latest revision.

[alexh-name]

FYI: just started testing whether there is any difference with 1.4.7.2.

[alexh-name]

So after a week of running 1.4.7.2 with loading a state file this is what I learned: (1) Reading a state file initially works like a charm (I restarted several times without problems). (2) Reading a state file that resulted from running an unknown amount of elongated time (at most 8 days on this test) seems to result in a state file that when read brings about nonsensical IAQ readings. (3) The reading seems to be nonsensical in a different type of way: I get an IAQ of 0.00 in an environment that is typically a 25 to 50. If brought to contact with Isopropanol that typically results in readings of 250 to 500 it now barely gives me readings of 0.05 to 8.50. The readings aren't "binary" anymore, but comically low.

So sadly I'll leave reading the state file disabled by default for now.

[pwr33]

also when compiled for old pi/zero (armv6) when the state file does not exist it gives a fatal error, did a trace of the program and it is crashing on a puts instruction, I do not use puts in my program, so seems it may be failing somewhere in the precompiled library? I notice the bosch driver github page does not allow posting of issues....

[pwr33]

It occurred to me perhaps the latest bsec driver makes certain assumptions about the range of gas ohms values a sensor provides, I have 7 sensors including some chinese ones and they can vary a great deal in the range of ohms seen in the same place (+/- 3ft), the one that is oddest is one of the new shape pimoroni ones which has very low readings and yet at some points in time, in the low range, say the 100/200 thousands, it corresponds to reading of a chinese bme680, but at others (good air quality) the Chinese is reading 7 million and the pimoroni one is reading 400,000 (the pimoroni odd one seems very limited in its range)

the iaq values are also very out of step, running from a clean start/erase of the state file.

[bsimmo]

That will be what the BSEC calibration procedure tries to remove. Resistance is just a measure, you take points on it to calibrate to background and max. 30 mins at background, then expose to Volatiles for 30 mins to get a max reading and off you go after that.
If you do that for all of them at once at the same time and then see how the IAQ drifts. Don't forget to set your temperature offsets so they all read correctly in the BSEC driver. (not in code afterwards)

Anyway I popped in here to say a new release 1.4.7.3 has a State file bug fix

Issues have moved to their Community Forum Page, link to from guthub

[alexh-name]

Anyway I popped in here to say a new release 1.4.7.3 has a State file bug fix

Thanks! Will update for the new version later today.

[alexh-name]

Looks like no change was required. Let's see if the bug is gone.

[alexh-name]

PS: Seems like the format of the state file was changed. You need to clear the file before running with the new version.

[bsimmo]

I just compiled and took all three new files over. It hasn't crashed so we'll see.

On Thu, 11 Apr 2019, 7:35 pm Alex H., notifications@github.com wrote:

PS: Seems like the format of the state file was changed. You need to clear the file before running with the new version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexh-name/bsec_bme680_linux/issues/13#issuecomment-482245366, or mute the thread https://github.com/notifications/unsubscribe-auth/ALALtxmMAp7D8BcC8iRp58BqslkH8mtLks5vf4BZgaJpZM4W5wLR .

[alexh-name]

Problem seems to be resolved. I re-enabled state file loading: d8e961a71310b15063ff6e500186953a2e71635c .