v118, Calibration data resets after power loss. Do i have to run calibrate sketch in open air every time the power is lost. is there an easier solution?

[UsaidAtif]

I used the manualZeroCalibration() and passed the previous calibration value i got from automatic calibration sketch after That sensor values constantly decreases and gets to 0.

[RobTillaart]

Thanks for the issue, will come back to it later today.

[RobTillaart]

Disclaimer: I have only 117 versions which differ from 118. 117's do not support manual calibration, so I cannot verify the scenario below.

The datasheet: states:

7.3 Zero calibration (REGISTER=0x01) The sensor has been calibrated for the zero point, but if the user needs to calibrate the zero point, the calibration data will not be saved and will be lost after power off. The sensor is placed in the fresh air for 5 minutes after being powered on for 5 minutes, and the following calibration commands can be sent to complete the zero calibration.

So the sensor will not keep your calibration (or maybe if power off is short enough it might keep it don't know).

---

I would try the following scenario:

1. Allocate 2 bytes of EEPROM for the calibration data..
   • Fill it initially with all zero's to indicate NOT CONFIGURED.
   • NB zero value for an 118 indicates automatic calibration IIRC.
2. Do a manual calibration.
3. Fetch the calibration value from the sensor and store the found value in EEPROM.
   • The assumption is that the calibration value will differ from 0x0000.
4. In the setup() function of your main sketch fetch the data from EEPROM.
   • if value == 0x0000 => calibration is needed (give a message or so)
   • if value != 0x0000 => write the value to the sensor

Instead of EEPROM another persistent storage can be used. FRAM or an SD card or from internet, whatever fits your project.

[RobTillaart]

@UsaidAtif Made any progress solving the issue? It seems not a library issue but a device property and the library cannot fix this.

Last year there was an issue about calibration - See #13 - maybe it contains some eye openers

A final idea is to call bool getZeroCalibrationData(ZeroCalibrationData &data) that could allow you to detect if the calibration data had changed.

[UsaidAtif]

@UsaidAtif Made any progress solving the issue? It seems not a library issue but a device property and the library cannot fix this.

Last year there was an issue about calibration - See #13 - maybe it contains some eye openers

A final idea is to call bool getZeroCalibrationData(ZeroCalibrationData &data) that could allow you to detect if the calibration data had changed.

Yes, you are right it's not a library issue, v118 is kind of downgraded from v117. I tried few methods but no positive results. For now I'm using the sensor without calibration because i didn't had the time to experiment on it. I will try one more time in coming week and will update you on it.

One more thing, i was running the sensor with default calibration but every time the power was lost the sensor took some time to get stable readings (around 15-20 min) usually it gets stable around 75-100 ppb depending upon the environment. Is it normal?

[RobTillaart]

Is it normal?

Think so, many sensors are sensitive e.g. for moisture and need time to adjust. These need to "heat" up to remove the excess moisture before they can do their job properly. Seen this at least in a lot of temperature and humidity sensors including well known DHT11 and DHT22.

CO2 is often measured with IR and water vapor also likes IR if I recall my physics correctly. Think that depending on the actual humidity it might take a little longer or shorter. To investigate this you could graph the humidity e.g. with an SHT85 which is quite robust (not cheap).

[RobTillaart]

As the issue is no library issue, the issue is closed. Feel free to reopen (same subject) or create a new issue (other subject) when needed,