@victor @oscgonfer @pral2a1
Today I started out working on integrating the I2C 8 Channel Mux UNit.
I soon discovered, during the code analysis stage; that this is going to be a complex task and it will not be done overnight.
-
So, I thought to start on something easier; so I can become familiar with the code layout and learn a few things. I decided to work on integrating the SCD41 sensor; which is intended as a replacement for the SCD30 CO2 sensor. This is needed in some use-case scenarios (like mine) when SCD30 will not fit inside the SCS V3 enclosure. SCD41 is tiny, and mine is mounted in one of the enclosure ports designed for Gas Sensors. @oscgonfer made provision for it in my instance of the SCS V3 system because we thought about it right from the start.
-
This journey starts with cloning of the code for SCD30; because (I reason) the two sensors are functionally similar and come from the same manufacturer; likely to work in a similar way. However they do have slightly different operational commands.
-
In particular I have come across three cases where I need to seek the advice from the system designers:
- Time Interval between readings:
The code for SCD30 has functionality to set the time interval between readings. This is an important measure used to limit power consumption in the SCS system (and SCK too). The existing code allows any time interval to be set, and this is supported by SCD30.
The SCD41 on the other hand does not have this feature. The ‘normal’ startPeriodicMeasurement command sets the device to make a new reading every 5 seconds. Each Reading can be read directly from the device only once, because the buffer is emptied when a reading is taken.
There is a ‘startLowPowerPeriodicMeasurement’ command; which conducts measurements every 30 seconds. The documentation indicates this feature is used to reduce power consumption and self-heating of the device. I assume this is to be avoided because it may make readings inaccurate.
So, there are two choices for automated periodic measurements: 5 second intervals or 30 second intervals.
There is a further choice: Instead of regular Periodic Measurements determined by the device; you can instead request spot measurements.
There is a further issue: either startPeriodicMeasurement or startLowPowerPeriodicMeasurement can only be run when periodic measurements are stopped. When the stopPeriodicMeasurement command is sent;
" the sensor will only respond to other commands after waiting 500 ms after issuing the stop_periodic_measurement command."
- In fact the supporting library for this has a ‘delay(500)’ command within the stopPeriodicMeasurement function; thus stopping the entire SCS for that (thankfully short) period of time (if this is not set to some other value). You can turn this off; but then it is possible to send the device a command and get no response. Not very friendly.
- So I will of course navigate my way around these issues as best I can; but you should be aware there are they exist. It seems likely I will set up the integration code to utilise the spot/Single shot measurement mode rather than automated periodic measurements. In that way the device can be made to operate in a manner that is sympathetic to the existing SCS system.
- Pressure Compensation
The device also has the feature where Altitude OR Pressure compensation can be incorporated into the measurements.
The SCD4x features on-chip signal compensation to counteract pressure and temperature effects. Feeding the SCD4x with the pressure or altitude enables highest accuracy of the CO2 output signal across a large pressure range. Setting the temperature offset improves the accuracy of the relative humidity and temperature output signal. Note that the temperature offset does not impact the accuracy of the CO2 output.
- I think temperature offset for this device should be zero because it is mounted exposed to air outside the case a couple of cm away from the Dallas Temperature probe. I suppose it’s possible to compare the SCD41 temperature reading with the Dallas Reading; assume the latter is more accurate and calculate an appropriate offset to load into the SCD41. This could then inform the RH reading.
Pressure Compensation:
- I consider momentarily whether it is worth the trouble to:
(a) detect if GPS is enabled && altitude measurement is available
(b) loading latest Altitude into the altitude compensation register. - and/or
(c) detect if air pressure reading is available (always yes for SCS & SCK)
(d) load Pressure compensation. - NOTE: Pressure compensation overrides Altitude compensation in the SCD41. This decision is easy. Because we always have pressure readings in the SCK/SCS, the current pressure can be loaded into the SCD41 ongoing. We ignore Altitude.
- Self-Recalibration:
The SCD41 device can perform automatic self recalibration and specified conditions.:
To realise high initial and long-term accuracy, the SCD4x includes two field calibration features. Forced recalibration (FRC) enables restoring highest accuracy with the assistance of a CO2 reference value immediately. Typically, FRC is applied to compensate for drifts originating from the sensor assembly process or other extensive stresses. Automatic self-calibration (ASC) ensures highest long-term stability of the SCD4x without the need of manual action steps from the user. The automatic self calibration algorithm assumes that the sensor is exposed to the atmospheric CO2 concentration of 400 ppm at least once per week`.
- Now, I do not think the above assumption (bold type) is entirely valid. I think (sadly) it has been a while since global baseline atmospheric CO2 concentration was that low. I think it’s around 420 ppm now. Thanks to all of us for that. I am still considering how to handle this feature. It you wish to provide me any guidance please feel free to get back in touch. I note that the existing firmware performs an automatic reset in the small hours of each day. Perhaps this is the time such automatic recalibration could be done. Your thoughts ?
- One possibility is to provide a UI command where the user enters a CO2 PPM value at the console to be used to recalibrate the sensor. Such value would be obtained from data published by the UN Climate Change body or NASA or somebody.
- Even better; perhaps FABLABSBCN could send to devices via MQTT back channel such CO2 Global data from time to time whenever it gets published. I think the SCD30 must incur the same issue, and I think I have seen it discussed by some other SCK users. Is this even feasible ?>
Anyway; as said above, I would like some guidance and feedback from you guys on this topic, I am working on it after I type this. I will of course make some default decisions in order to keep moving, but they can be changed. In the case of this sensor, I think it will become part of the mainstream for SCS/SCK due to the size consideration coupled with its specified accuracy being better than SCD30.
Cheers,
Bryn
