interpret the PM values

[teokino]

I have difficulty interpreting the data obtained by PMS5003.

Looking at these values it would seem that the data of PM1, PM2.5 and PM10 to be considered are x_pm1_std, x_pm25_std and x_pm10_std.

    x_pm01_atm --> PM1.0 (CF=1) μg/m³ = 6
    x_pm2_5_atm --> PM2.5 (CF=1) μg/m³ = 8
    x_pm10_atm --> PM10 (CF=1) μg/m³= 8

    x_pm1_std =  --> PM1 (STD) μg/m³= 6
    x_pm25_std =  --> PM2.5 (STD) μg/m³ = 8
    x_pm10_std = --> PM10 (STD) μg/m³= 8

    x_count_03um = packet[6]  -->  Particles >  0.3  μm count = 1296
    x_count_05um= packet[7]  --> Particles >  0.5  μm count = 359
    x_count_1um= packet[8]  --> Particles >  1  μm count = 30
    x_count_2_5um= packet[9]  --> Particles >  2.5 μm count = 1
    x_count_5um= packet[10]  --> Particles >  5.0  μm count = 1
    x_count_10um= packet[11]  -->Particles >  10  μm count = 0

I want to compare these values with those of PM1, PM2.5 and PM10 collected using Alphasense's OPC-N2 and py-opc developed by @dhhagan https://github.com/dhhagan/py-opc

In that case you can get both the histogram and the punctual values, as below:

alpha.pm()
{'PM2.5': 1.7809854745864868, 'PM10': 1.8168011903762817, 'PM1': 1.4750860929489136}

And even the histogram obtained by OPC-N2 is:

alpha.histogram()
{'Temperature': None, 'PM2.5': 0.1172892227768898, 'Bin 8': 0.0022492796358061116, 'Bin5 MToF': 9.333333333333334, 'Bin 7': 0.0, 'Bin 6': 0.004498559271612223, 'Bin 15': 0.0, 'Bin 3': 0.011246398179030559, 'Bin7 MToF': 0.0, 'Bin 1': 0.022492796358061118, 'Pressure': None, 'Bin1 MToF': 7.0, 'Bin 4': 0.0, 'Bin 13': 0.0, 'Bin 12': 0.0, 'Bin3 MToF': 7.0, 'PM1': 0.08618641644716263, 'Bin 9': 0.0, 'Bin 14': 0.0, 'Bin 2': 0.008997118543224446, 'PM10': 0.17635871469974518, 'SFR': 4.624794960021973, 'Checksum': 101, 'Bin 10': 0.0, 'Bin 5': 0.006747838907418335, 'Sampling Period': 96.13113403320312, 'Bin 11': 0.0, 'Bin 0': 0.1709452523212645}

As can be seen the values of PMS5003 are in the order of 6, 8, 8 while those of OPC-N2 of 1.78, 1.81, 1.47. I checked that it was not a unit problem, but it is not.

I would therefore like to know why they are so different, beyond the quality of the sensor.

Thank you

[kzyapkov]

I am no expert, but my guess would be it's just the quality of the sensors. These are pretty low values, it is very likely that the sensors are not sensitive enough at the low end of their dynamic range. There are massive amounts of data at https://airsofia.info/ from similar sensors and there are almost no measurements below 5 ug/m^3.

Maybe try with higher PM concentrations and see how both sensors react.

[dhhagan]

Hey @teokino there are a few reasons for this: 1) the histogram reading for the OPC-N2 using my library outputs by default in units of # of particles/cc as opposed to number of particles in the bin. You can get number of particles/bin by changing the argument number_concentration=False.

i.e.

alpha.histogram(number_concentration=False)

If you think about what is going on under the hood, each of the sensors has an LED/laser that is scattering light of of each particle. The scattered light is then picked up by the photodetector as a pulse resulting in some pulse height X. The instrument then decides which bin to assign the pulse height to, and typically it is assumed that the pulse height is related to just the particle size. Once the instrument has a histogram of pulse heights/bins, it calculates a PM value from this histogram. Most of the low-cost counters that have multiple bins (OPC-N2, PMS5003, etc) use an algorithm like

In addition, these devices aren't measuring the same thing. The Alphasense OPC-N2 measures particles between 380 nm - 17,500 nm (according to their datasheet) and the PMS5003 is a bit different. You may find results are similar, but you should also be aware of these differences in how they work and what they measure. Let me know if you have any other questions.

[teokino]

Thanks @dhhagan for your effective response. I had read the documentation you had published but I did not understand that the number_concentration flag set to false led to having #particles per bin instead of particles/cc.

I tried to think about it but without success. In your opinion @dhhagan , the punctual values of PM1, PM2.5 and PM10 acquired with pms5003 are these:

x_pm1_std =  --> PM1 (STD) = 6
x_pm25_std =  --> PM2.5 (STD) = 8
x_pm10_std = --> PM10 (STD) = 8

In order to compare them with those collected using py-op and OPC-N2, in py-op I have to set number_concentration to False. I would think that the command alpha.pm() read only the data of PM as #particles per bin.

In your opinion, what configuration of pms5003 and OPC-N2 should I use to have even roughly comparable data?

[dhhagan]

No problem, @teokino . The results for .pm() should be the same as the PM values you see in .histogram() regardless of whether you are reading the number concentration or not - it only affects the bin values and not the resulting PM values. You should be fine comparing the results from either of these calls to the data you are seeing from the PMS5003. The reason that you are seeing integers as opposed to floats from the PMS5003 has to do with the resolution they output - not actually what it's seeing. When working with low-cost sensors, you will see lots of odd things like this. I would recommend just taking multiple measurements and then averaging over a longer time period. Depending on how you construct your experiment, you will probably want to do this anyway to avoid any tiny offsets in the clock or different sampling time/flowrate.

[teokino]

Unfortunately my problem concerning the comparison of data is not due to the question of integer or floats values.

The thing that leaves me surprised is the fact that making 2 samples in the same environment and at the same time is that the values coming from OPC-N2 are in the order of one and decimal, while in the other they are 6-8 times higher. For example, if I consider only PM2.5, I have that:

pms5003 ---> x_pm25_std = --> PM2.5 (STD) = 8

OPC-N2 ---> 'PM2.5': 1.78

I do not understand then if in pms5003 I read wrong data or if they have to be adjusted with some constant. in fact it is strange that they are always 6 or 8 times larger.