When setIAQBaseline is called,getIAQBaseline is wrong.

[adafruit]

When setIAQBaseline is called,getIAQBaseline is wrong.

[GregSawin]

Yea, there's only that 1 command to get the baseline. There were a few times I remember the sensor would malfunction and start returning junk data, which is similar to what happens when you give it an invalid baseline. In those cases I disabled the setIAQBaseline call, and let it generate a new baseline over the next 12hrs. I never had an issue starting with no baseline, only when I'd end up sending a bad baseline to start with. The baseline does drift over time, typically decreasing by 1 or 2 every hour but a few times a day it increases by 2-20, at least mine do. By the way, the 2 sensors I have use dramatically different baselines, one is almost double the other sensor.

You only really need to call the get baseline right before you restart your device, which I do; but I also read it every hour to handle the cases where the device loses power or resets unexpectedly. I also log the value so when it goes haywire and gives bad data I can manually resume to the most recent valid baseline and not have to wait 12hrs. And by valid I mean you get normal/expected readings. This issue is rare though, maybe once a year, and I haven't seen it in awhile so maybe it was my fault.

These sensors aren't very accurate and are only really useful for relative measurements. For example I ended up getting a real CO2 sensor and both it and the SGP30 show a slowly increasing CO2 over the past few hours but the actual value is 520ish while the SGP30 is showing over 800. And that's my good SGP30 sensor. My other SGP30 sensor isn't working much anymore and it's not obvious unless you compare or test it. It's values are way off and it sometimes moves in the opposite direction to the good SGP30. So I replaced them with https://www.adafruit.com/product/4867 and https://www.adafruit.com/product/4829

[GregSawin]

You have the order wrong. If you don't have the baseline (100 isn't correct), then don't set it. It needs to run 12hrs if I remember correctly before it can give you an accurate baseline. The baseline will be changing, it's not a one-time thing; and will save you from that 12hr recalibration step. Back when I used this sensor I'd save a new baseline to my EEPROM every hour and then upon restart I'd use the set call on setup like you have done. If you don't have a way to save/persist the baseline across device restarts then don't use the setIAQBaseline and just be aware it takes 12hrs to return accurate results after start up.
Also the baseline is different from that actual values, if not saving baseline then there's no point ever calling getIAQBaseline.

[caternuson]

Yep, agree with above.

There's a "SGP30 Driver Integration" guide that has more detail. For some reason no longer finding it on Sensirion's website. But it has this diagram which shows the general usage of get/set baseline:

[baloyou]

You have the order wrong. If you don't have the baseline (100 isn't correct), then don't set it. It needs to run 12hrs if I remember correctly before it can give you an accurate baseline. The baseline will be changing, it's not a one-time thing; and will save you from that 12hr recalibration step. Back when I used this sensor I'd save a new baseline to my EEPROM every hour and then upon restart I'd use the set call on setup like you have done. If you don't have a way to save/persist the baseline across device restarts then don't use the setIAQBaseline and just be aware it takes 12hrs to return accurate results after start up.
Also the baseline is different from that actual values, if not saving baseline then there's no point ever calling getIAQBaseline.

Thank you for your patient answers.

About this sentence:

when I used this sensor I'd save a new baseline to my EEPROM every hour and then upon restart I'd use the set call on setup like you have done.

How do you get a dynamic baseline? Also via sgp.getIAQBaseline()?

I took the baseline value via the sgp.getIAQBaseline() method and saved it in EEPROM. Read EEPROM on restart and call sgp.setIAQBaseline() to write to it.

But after that, I can't get the new baseline value, sgp.getIAQBaseline() returns the same value as in EEPROM.

After 24 hours of operation, the values of voc and co2 deviated.

I don't know where the problem is.

[baloyou]

Yep, agree with above.

There's a "SGP30 Driver Integration" guide that has more detail. For some reason no longer finding it on Sensirion's website. But it has this diagram which shows the general usage of get/set baseline:

Thanks, I watched this too.

If the baseline value is set by sgp.setIAQBaseline() method during the restart, do I still need to call the get method every hour to get the new baseline value?

If not, my VOC and CO2 data are skewed after a while (24 hours).

If needed, the value returned by the get method is always the same as when it was set.

So I'm a little weird and don't know what went wrong.

[baloyou]

Yea, there's only that 1 command to get the baseline. There were a few times I remember the sensor would malfunction and start returning junk data, which is similar to what happens when you give it an invalid baseline. In those cases I disabled the setIAQBaseline call, and let it generate a new baseline over the next 12hrs. I never had an issue starting with no baseline, only when I'd end up sending a bad baseline to start with. The baseline does drift over time, typically decreasing by 1 or 2 every hour but a few times a day it increases by 2-20, at least mine do. By the way, the 2 sensors I have use dramatically different baselines, one is almost double the other sensor.

You only really need to call the get baseline right before you restart your device, which I do; but I also read it every hour to handle the cases where the device loses power or resets unexpectedly. I also log the value so when it goes haywire and gives bad data I can manually resume to the most recent valid baseline and not have to wait 12hrs. And by valid I mean you get normal/expected readings. This issue is rare though, maybe once a year, and I haven't seen it in awhile so maybe it was my fault.

These sensors aren't very accurate and are only really useful for relative measurements. For example I ended up getting a real CO2 sensor and both it and the SGP30 show a slowly increasing CO2 over the past few hours but the actual value is 520ish while the SGP30 is showing over 800. And that's my good SGP30 sensor. My other SGP30 sensor isn't working much anymore and it's not obvious unless you compare or test it. It's values are way off and it sometimes moves in the opposite direction to the good SGP30. So I replaced them with https://www.adafruit.com/product/4867 and https://www.adafruit.com/product/4829

Thank you very much, now I understand.