WeatherDuino Forum

Full Version: Humidity compensation
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
While studying the code I saw that you implemented a standard humidity compensation for all sensors supported:
Code:
// RH Compensation
  // Raw PM readings will be mathematically compensated according the Sioutas tests
  // using the following equation: Ccomp = Cmeas / ((1+(RH/100)7) x 3.7
  // The accuracy of the RH interference correction using the above equation has been experimentally tested measuring continuously
  // the outdoor PM2.5 concentrations over a wintertime period for 7 days using two  OPC’s: the model e-sampler and the model
  // Aerocet 531 (same instruments used for the gravimetric calibrations) operating in parallel.
  // Source: https://repositorium.sdum.uminho.pt/bitstream/1822/10163/1/21.I_CIPTT_P_Ruprecht%5B1%5D.pdf  
  //RHcomp_factor = (1.0 + pow((Humidity / 100.0), 7) * 3.7);
That is interesting and you might add that to the overview.
If other sensors don't use that or use different compensations that you are aware of, could you indicate that ?
Hi,

I don't think it's all that important to mention that aspect. As much as I think I know, all commercial Air Quality sensors implement humidity compensation, that's the main reason why they all have T/H sensors included. The purpose isn't provide accurate T/H readings, but instead measure the air humidity as close to the dust sensor air intake as possible. Brands don't reveal their algorithm, the AQM-III uses the one which source of study is clearly identified on the code.
One user here in Portugal is running the AQM III (with a PMS7003), side by side with an AirLink and a Purple Air since several months, and the results of the 1H, 3H, 12H and 24H averages are consistent between them, which leads us to believe that the humidity compensation method that we use is valid.

The Sensirion SPS30 readings seems to be less sensible to humidity changes than the PMS7003 or the SD011, that's why on the current firmware, the humidity compensation isn't applied for the SPS30.

I think you have an original AirLink, try putting both running outside side by side, and let them work for some days. On the AQM III preferably use a PMS7003, as it is from the same brand and similar to the ones used by the Davis Airlink.

Rgs.
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]I don't think it's all that important to mention that aspect. As much as I think I know, all commercial Air Quality sensors implement humidity compensation, that's the main reason why they all have T/H sensors included.
You mean the AirLink and PurpleAir etc... I don't know that, they don't publish that, I think they should and would.
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]The purpose isn't provide accurate T/H readings, but instead measure the air humidity as close to the dust sensor air intake as possible. Brands don't reveal their algorithm, the AQM-III uses the one which source of study is clearly identified on the code.
Yes.
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]One user here in Portugal is running the AQM III (with a PMS7003), side by side with an AirLink and a Purple Air since several months, and the results of the 1H, 3H, 12H and 24H averages are consistent between them, which leads us to believe that the humidity compensation method that we use is valid.
OK... good
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]The Sensirion SPS30 readings seems to be less sensible to humidity changes than the PMS7003 or the SD011, that's why on the current firmware, the humidity compensation isn't applied for the SPS30.
Now that is something I dislike a bit, an inconsistency. As this T/H correction is apparently a non-documented feature, everywhere it becomes very difficult to say something about it and measure the correctness of the output. Comparison becomes difficult. A lot has been written about this T/H correction but no specification mentions it. I find that difficult. Fortunately with the AQM there is the code, I may start trying some things.
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]I think you have an original AirLink, try putting both running outside side by side, and let them work for some days. On the AQM III preferably use a PMS7003, as it is from the same brand and similar to the ones used by the Davis Airlink.
No I don't have a real airlink, it is my own emulator with an PMS1003. I may start using a PMS7003 and compare that with my other sensors. I am currently starting a test examining exactly that: T/H compensation (where I live humidity can be a whole year 70% and up).

Anyway... interesting feature that compensation. I think it should be mentioned just as it should with an AirLink.

Regards, Hans
Ah... and in addition I can add that the article states the correction loses validity above 70% humidity Sad
Correction is the holy grail of PM measurement I guess.
In my humble opinion the true holy grail on the fast growing market of consumer dust sensors, is the algorithm used to compute the PM10.0 (or any others above 2.5). While not a secret, most people believe that the PM10.0 particles are truly measured, however the truth is they are computed (the wave length of the laser used on consumer dust sensors simple isn't able to give accurate reading for particles above 2.5).
As most as I know, Sensirion is the only manufacturer that clearly says on the specs of the SPS30 that PM10 (as also PM4) are calculated.

Quote:PM4 and PM10 output values are calculated based on distribution profile of all measured particles.

... which are the ones below 2.5μm.

Many tests done in laboratorial environment demonstrated that while almost of the common dust sensors are relatively accurate on what refers to PM2.5 particles, the same doesn't necessarily happens to PM10.0

A very common error is comparing PM10.0 readings from sensors of different brands, without having a lab sensor reference (which usually we don't have). You will never know which one is providing the more accurate readings.

For those more curious on this matter, search on Google, there are many info available.
(27-09-2021, 23:06)Werk_AG Wrote: [ -> ]The Sensirion SPS30 readings seems to be less sensible to humidity changes than the PMS7003 or the SD011, that's why on the current firmware, the humidity compensation isn't applied for the SPS30.

I think you have an original AirLink, try putting both running outside side by side, and let them work for some days.

I'll be interested to see comparisons when I have my 2nd AQM connected.
The first, has an SPS30, and is just running on my desk at the moment, about to have the SCD30 added.
It will become my Primary indoor sensor.

The second will also have an SPS30, but use an MH-Z90 & will be an additional outdoor sensor, and initially I will site it beside my AirLink.

Do also have two SDS011 units sitting idle, along with a handful for ESP32's.
May see how easy it is to patch them together & get running.

Phil.
(28-09-2021, 09:45)HansR Wrote: [ -> ]... very difficult to say something about it and measure the correctness of the output. Comparison becomes difficult.

Perhaps it's not a direct comment on your thought which I think I have understood.

I believe the main purpose of any Air Quality device is provide an AQ Index (whatever the standard), which usually is a rolling average over a time period. Thus, what eventually makes sense, when comparing different AQ devices, is comparing the resulting AQ Index for the same time period, and not the instant output of each one (hardly two of them will have the same output at a given moment). Just a thought. Smile
(28-09-2021, 23:07)Phil23 Wrote: [ -> ]...
The second will also have an SPS30, but use an MH-Z90 & will be an additional outdoor sensor, and initially I will site it beside my AirLink.

That will be very interesting... Like
(28-09-2021, 23:16)Werk_AG Wrote: [ -> ]Perhaps it's not a direct comment on your thought which I think I have understood.

I believe the main purpose of any Air Quality device is provide an AQ Index (whatever the standard), which usually is a rolling average over a time period. Thus, what eventually makes sense, when comparing different AQ devices, is comparing the resulting AQ Index for the same time period, and not the instant output of each one (hardly two of them will have the same output at a given moment). Just a thought. Smile

Yes, you may be right but AQI is derived from the actual concentrations and therefore - if devices are compared - devices should give - roughly at least - the same concentrations.
We need not discuss it here in depth, it is now clear to me what you are doing in the code, that's important.
If I have any other remarks in this I will PM you.

Regards,
Hans