TVOC baseline management

nicola.pomaro · December 11, 2019, 2:30pm

Hi, I am trying to obtain reliable TVOC measurements, and the critical point here is to have a good baseline inside sensor.

I learned that baseline is updated each time sensor detects a higher resistance, i.e. cleaner air. Moreover, baseline is deleted if power is removed.

So, it would make sense to store the last baseline in non volatile memory, so that, in case of power down, it can be restored avoiding to wait the long process of baseline stabilization.

On the other hand, removing power could be a simple way to reset baseline when the sensor must be moved to another place.

From my tests, it seems that SCK does not manage at all the TVOC baseline, so, in practice, any power shortage would erase it and require a full stabilization period. Is anybody able to confirm this?

This baseline aspect is a clear limit of this sensor. Here now, in winter and in urban area, it is almost impossible to have air clean enough to obtain calibrated measurements.

pral2a · December 11, 2019, 4:38pm

Hi @nicola.pomaro

I will let @victor and @oscgonfer who designed the sensor implementation to answer your question.

You can check the current implementation here:

github.com

fablabbcn/smartcitizen-kit-21/blob/master/sam/src/SckUrban.cpp#L1032-L1137


bool Sck_CCS811::start()
{
	if (alreadyStarted) return true;


	if (ccs.begin() != CCS811Core::SENSOR_SUCCESS) return false;


	if (ccs.setDriveMode(driveMode) != CCS811Core::SENSOR_SUCCESS) return false;


	startTime = rtc->getEpoch();
	alreadyStarted = true;
	return true;
}
bool Sck_CCS811::stop()
{
	// If the sensor is not there we don't need to stop it
	if (!I2Cdetect(&Wire, address)) return true;


	if (ccs.setDriveMode(0) != CCS811Core::SENSOR_SUCCESS) return false;
	alreadyStarted = false;
	startTime = 0;

This file has been truncated. show original

BTW, are you running the latest firmware version?

nicola.pomaro · December 11, 2019, 5:10pm

I updated the firmware when the kit arrived, some weeks ago, to SAM 0.9.6. It should be the latest version.

oscgonfer · December 11, 2019, 8:52pm

Hi @nicola.pomaro!

Thanks for your comments! The baseline of the sensor is saved and restored every time the kit goes off in an ad-hoc power off event. This means that if you turn off or reset the kit by pressing the on/off button the baseline will be saved in EEPROM and restored on power on. Also, the kit reset’s itself every day at 00am (UTC) as a safety routine in case something weird happens. Before that, we store the baseline and restore it afterwards.

When the device is powered up we have 5’ in which there aren’t any valid measurements (a bit more than what is stated in the datasheet). In principle, the ambient conditions should be the same if the reset is short (max 5-6’) and in that situation the readings should be continuous (no gap between them), but sometimes we have seen this effect and we are not fully sure why this happens. Nevertheless, in conversations with the sensor manufacturer, this approach seems to be the way to go when dealing with the baseline resistance.

Finally, some things we have pending to do on our side, but which are not a priority now, are to have a way to monitor the actual sensor resistance reading and see how it behaves with respect to the final calculated value, since sometimes we see some weird behaviour when exposed in outdoor conditions or changes in the environment. Also, one more important feature is to be able to reset the baseline with a command on the sck shell, in case for example you want to change the device’s location, but right now it is not implemented (and cannot be reset with a factory reset, since it’s stored in EEPROM). (maybe someone could suggest a PR?? )

Anyway, I hope this helps! Let us know your comments!

nicola.pomaro · December 11, 2019, 11:01pm

Hello @oscgonfer! Many thanks for your detailed answer!
Very useful information in your answer. This automatic reset at 00am explains some things I noticed. And also the fact that a controlled on/off cycle does not reset the baseline.

So, if I switch off the kit and then remove the battery, the latest baseline remains stored and restored when power returns.

But what about an abrupt power shut down, like removing the USB cable at kit ON, with battery not connected? Or, with kit ON, removing the battery? In that case, which baseline is restored?

I understand from sensor datasheet that it takes as baseline the best (higher) resistance detected in a 24 hour interval. It is not clear if this process is repeated every 24 hours, discarding the previous value, or if baseline is updated only if a higher resistance is detected, so that the stored baseline is the “best ever” in the sensor life. Not clear, also, how the long term sensor drift is taken into account, as this would require to renew the baseline even if no better resistance was detected. In any case, in a polluted environment the sensor could never achieve the clean air baseline, and the measured levels would be always underestimated.

If one could be able to take the sensor to a clean environment, it could record a good baseline, and this could be maintained, provided that the sensor is properly switched off in clean air and on when back in standard position, or kept on all the time. This could be a way to calibrate the sensor.

Probably, a sort of “calibration procedure”, where the user is able to tell to the system “take this baseline as reference and save it” could be considered. In this case, after an on/off cycle, the restored baseline could be not the latest one but the reference one.

oscgonfer · December 12, 2019, 12:02pm

Hi @nicola.pomaro!

Really nice comments. I will try to answer all your questions step by step.

So, if I switch off the kit and then remove the battery, the latest baseline remains stored and restored when power returns.

Correct, that is the default behaviour.

But what about an abrupt power shut down, like removing the USB cable at kit ON, with battery not connected? Or, with kit ON, removing the battery? In that case, which baseline is restored?

In that case, the latest baseline that was saved, which was before the latest power off event (max 24h).

I understand from sensor datasheet that it takes as baseline the best (higher) resistance detected in a 24 hour interval. It is not clear if this process is repeated every 24 hours, discarding the previous value, or if baseline is updated only if a higher resistance is detected, so that the stored baseline is the “best ever” in the sensor life. Not clear, also, how the long term sensor drift is taken into account, as this would require to renew the baseline even if no better resistance was detected. In any case, in a polluted environment the sensor could never achieve the clean air baseline, and the measured levels would be always underestimated.

These are very good point, and the answers to that are in this application note by ams. The baseline will be calculated not only based on the resistance but also some internal corrections (according to the AN it is related with T, H, but we do not have any control over this). If the result of this is equivalent to a “cleaner” air, the baseline is updated, otherwise it’s kept. If you write the baseline by yourself, then it’s overwritten, ofc.

If one could be able to take the sensor to a clean environment, it could record a good baseline, and this could be maintained, provided that the sensor is properly switched off in clean air and on when back in standard position, or kept on all the time. This could be a way to calibrate the sensor.
Probably, a sort of “calibration procedure”, where the user is able to tell to the system “take this baseline as reference and save it” could be considered. In this case, after an on/off cycle, the restored baseline could be not the latest one but the reference one.

That would be the best. Actually, that is why the reset baseline command is in our to-do list as well. In the same AN as above, this is stated:

The baseline is safe to be read at any timeafter the conditioning period is complete, however it is recommended to read and save the baseline if the user knows the sensor has encountered clean air at any point after the conditioning period. If this is not known it is best practice to read the baseline directly before powering down the system.

Just for the record, pretty much all our knowledge about this sensor, although probably not all what we are talking is here too.

Finally: right now, the default configuration is able to cover the base user scenario, and this more advance setting is planned for more advanced understanding of the sensor. Since you have a quite advanced proposal, even if we already agree with it, why don’t you open up an issue in the firmware repository and we keep track of the implementation there?

Thanks again

nicola.pomaro · December 12, 2019, 1:24pm

Hello, I will do.

Just to complete reasoning, I am attaching my SCK TVOC graph of today, with temperature.

There are some interesting features:

The automatic reset happened at 4.00am, corresponding to 3.00am UTC.
there are some strange “steps” during the night, but room conditions were stable apart temperature.
At 12.00pm room was ventilated and this is the cleaner situation, so it should be useful for baseline improvement, but it is also a situation with strong variations of temperature and humidity, so it is probably not optimal.

It is an example of the difficulty, in realistic situations, to achieve a reliable baseline.