For quite some time the cgallange of high air-humidity or even condensation is known with SDS011 and high fluctuation in reading PM. Every now and then rumers say with SDS030 this problem has been overcome. Because of law of physics and law of chemistry, I dought the problem has been overcome. What I guess is a calculation to compensate error-reading. This is naturally with cost. Lets name the facts: In an air-sample-stream of high humidity (>75%) the number of moisture droplets increase rapidely. Where pure gas moisture is not visible, condensed moisture deflect, reflect light. The relation of moisture (ammount of H2O) and temperature determine the dew-point, when the air-body is not capable anymore holding H2O as gas and it becomes liquid as droplets. Theoretically this is the point, when relative humidity is 100%. In reality, this physical process starts at about 70% Rel-Humidity in a non-linear function. Disturbance is caused by air-polution. Where mineral particles in the size of PM2.5 are very special, particles composed of chemically reactive substances, like sulfious or even more attractive for H2O (NOx), they form clusters. Such clusters not only result in a misreading in number of particles, the error-reading in particle size is obvious. Heating up an sample-air-stream reduces the ammount of liquite H2O, but it doesn’t reduce the liquite H2O of clusters. The energy applied requires to be much higher, once at all. Applied energy to the air-sample-stream is absorbed by the surfaces in contact with the slip-stream, that is the casing of the sensor as well as the (laser)measuring chamber. Once the surfaces cool the air-sample below the dew-point, condensed H2O forms. This, and many other aspects more, is why heating the sample is a semi-optimal way. A more promissing way is the absorbtion of moisture from the sample before reaching the testing chamber. This could be done in a combination of chemo-physical process. Material which has a high demand for H2O to ballance molecular grids, like some thermo-dynamically prepared CA[SO4], A theoretical maximum of 2[H2O] ballances the CA[SO4]. Means, for each g of CA[SO4] 2 g of H2O ballances. In reality it is about 1g H2O. Talking about meta-data for the dehydration, at least this two different methods requires to be identified. Once a drying-chamber is operated, a revolving set of chambers extend the working-phase of the sensor and requires some actor/servo-operation through the firmware. This is why I mentiond last wednesday the need to decide on sufficient flags and some processing capacity to operate autonomous the dehydration.
We use HECA since 2018. In this time more than 1000 boards were produced. Hundreds of this sensors sends data to Sensor.Community. Without metadata. Maybe it’s a good time to introduce guidelines instead of arguing which method is better?
We have a problem: when humidity above 70% (or so) then SDS011 (and other PM sensors) report constantly high values regardless of actual PM quantity in the air.
There is currently only one working way to mitigate this problem: use air preheating.
heating the sample is a semi-optimal way.
Yes, I agree that it might not be the most precise way of reducing air humidity. But what else can we offer right now?
Sensor.community is an open source project with open HW design and thus cannot easily block data from PM sensors with custom built dehumidifiers.
As it was told by @irukard currently there are more then 1000 boards reporting PM data with installed dehumidifier! And it is extremely hard to distinguish them from other PM sensors without heaters.
But do we really need to fight with dehumidifiers? Maybe it would be better to give users an opportunity to honestly mark their devices as “with custom heater”?
We have plain SDS011 sensor → Type A
We have SDS011 with preheater which is constant ON → Type B
We have SDS011 with preheater which is ON when rel. Humidity >70% → Type C
Normal (clean air) condition wit rel. humidity less then 70%. What values could every type show?
A: values as expected B: same result graphic, but all values will be less by some percentage (that is my guess, but it is in accordance to the experiment we made in Moscow - see graphic below) C: same result as A
Clean air and rel. humidity above 70 %
A: results are alarmingly high (sensor became “blind”) B: higher then normal, but not alarming C: higher then normal, but not alarming
Dusty air (for example fire brokeout nearby) and rel. humidity above 70 %
A: same high alarming results as in (2)
B: high alarming values
C: high alarming values
Conclusion: sensor with heater above 70 percent will give a possibility to distinguish dusty air from clean one.
Type B will lover results when humidity is less 70 percent.
Indeed. All I need to way of providing information that HECA is installed and working. Please note that from the beginning we send HECA information in JSON. It looks like that:
I don’t agree it’s extremely hard to distinguish such sensor.
I got better idea. We (Nettigo) will send you two assembled NAM 0.3.3 units. You will place them side by side, and disable heater in one of them (by unplugging one cable). You will have additional temperature and humidity readings from SHT30 in HECA module.
This way both chambers will have identical dead volume - which in case of NAM 0.3 is about 19.1cm³ (roughly calculated by assuming heater volume as: body 21x5x31mm + 2 leads x 1,5² x π x 29mm). Response time for change in dust concentration should be the same.
Also all SDS011 units in test should be 2020 Q4 or newer (new fan with 3 cables). According to first observations those sensors are slightly different calibrated than older ones. Also they consume ~20mA more current. I will try to match two very similar units by running tests in my lab.
I may also equip those units with SHT31 sensors alongside BME280. I also have a couple experimental sensors with BMP388+SHT31 and BMP390L+SHT35, but I’m afraid BMP388 and BMP390L are not yet supported by firmware. Compared to BME280 they cost a small fortune but they are incredible precise. I use BMP390L (pressure), SHT35 (relative humidity+temperature) and PT1000 (temperature) as reference point.
If your experiment requires Stevenson Cage - just let me know. I have means of building semi professional cage which is quite cheap.
That is plausible as during absorption of water PM particles diluted in water droplets might also be absorbed. That will decrease PM quantity.
Still to my mind it is better then current situation when PM sensors become blind over 70% humidity.
These chemical tablets might be used to make an experiment with lovering humidity level.
The obvious disadvantage of this methind is the need to constantly replace chemical tablets.
Yes. I did such tests many times. Both synthetic and outdoor. But not on the latest NAM 0.3.3 with SDS011 2020Q4 (or newer). And I would like to delegate some work to person not biased as I am (as project creator). Maybe there is something that I’m not seeing in my solution.
I the end of month we will try to deploy NAM 0.3.3 with newest SDS011 and HECA in close proximity of reference station.
In my opinion if you have precise relative humidity and temperature measurement the dust data are actually quite useful. Up to 90% RH you are able to compensate measurements in software with decent approximation. Above 90% RH it probably still possible but not with BME280 or DHT22. Those sensors sucks in 90%+ RH. I do like SHT31 and SHT35 in DIS-F variant with PTFE membrane or with dedicated SP2 cap.
I am stepping into this discussion because since 2017 I have designed PM sensors with the SDS011 for local environmental associations, and humidity was one of the first and biggest issues to deal with.
From my experience, too aggressive preheating or dehumidification will alter PM readings too much and will make it difficult to calculate a true PM value.
The best approach, in my opinion, is a moderate preheating followed by software compensation. The compensation curve is not trivial and it took me many simulations and a lot of trial and error to find a reliable one.
Eventually the result was good. I could tell because I had two sensors installed in close proximity of two official monitoring stations.
Actually, one was installed ON TOP of an official station since the local environmental agency kindly allowed me to do so for a couple of months:
By comparing the daily official measurements with the daily average of my sensor I could compute the “R squared” coefficient, which is an indication of how well the two datasets correlate.
So my point here is that there are many ideas about how to compensate for humidity, and I am not saying that my method is necessarily the best. But any proposed method should be supported by comparisons with official data over a reasonably long time, at least a couple of months. And contributors should be advised to choose among one of the already tested methods.
I see that @irukard is going to perform a test near a reference station, so I will be interested in comparing my results to their HECA system.
By the way, I did not know Sensor.Community before, and it is a really nice project. Now that I know it, I am considering the possibility of connecting my sensors to this network (I will check the protocol), in addition to sending data to my current database. So I think it is important to have some guidelines about the additional information to transmit, in order to identify a specific sensor+preheater/dehumidifier configuration, as @Denis and @irukard already pointed out.
We use PTC heating element which is able to reach 50~55°C. So it’s not really aggressive heating. HECA drives this element in correlation of RH. It’s powered on when RH>63%. Our goal is to keep RH below 70%.
@irukard
Let us know when you have the results of your tests near the reference station, it is an interesting experiment.
But perhaps you should repeat it in winter, because in spring air pollution usually decreases (at least here in Italy, is it not the same in Poland?)
Humidity influence is smooth, not threshold and at 69% is high as 71%. I show my comarison and there are 50%+ excess at 70%. We can’t neglect not 50% nor 25% humidity.
Why do you want use system with unpredictable switching on and off creating some thresholds on data?
I think PTC doesn’t useful too, because provide nonlinear heating and unpredictably influence on pm-data too.
Constant resistor of 50-65 Ohm heating air on approximately constant value and more simple in analysis of data and construction of heater.
I agree with @Mogwaika, in my opinion a constant low power resistor is better than an on-off switch, because it avoids discontinuities.
In my sensor I use a low power preheater, together with software compensation, and the comparison with a reference station is good.
However @irukard is going to run a test near a reference station, so we can compare both methods.
