SPS30 PM10 no difference to PM2.5

[mdietinger]

Have a new station using SPS30. On the measurments I get PM1&PM2.5&PM4&PM10 readings. Issue is that the PM2.5 and PM10 readings are most of the time the same or only differ by 0,1µg/m³. Only PM1 seems to be lower by 1µg/m³. When the sensor was brought into operation the 1st #time, different values have been shown for short periode of time, but after short time the values seem to be the same. After some maintanance activities PM2.5 was 13,2 & PM10 was 14.0, but within some measurements they have been synchron again. PM10 value looks realistically, but PM2.5 doesn't. Station ID is:6698748

[tom-r]

I can confirm this behaviour with my own SPS30, so it's not your sensor. I see only differences in the PM1 reading, all other converge more and more the longer the sensor operates (generally speaking PM2.5 ... PM10 are more or less equal all the time on mine, and PM1 shows slightly lower values). Due to the finding that the values initially differ and then converge more and more, I "played" already a bit with resetting the sensor after each reading (and giving it a appropriate start-up time before the next reading), but it didn't make any difference (see also question #667) … I found a closed issue on the "official" SPS30 GitHub repo, where people were asking about how to operate the sensor (continuously running or interrupting after each cycle. Answer : run it continuously as we do). There was test data linked to this issue, showing similar sensor results as reported here. I already thought about dirt on the lense, keeping a constant PM2.5...PM10 readings. But all 4 PM-readings really react on air quality, so it can't really be dirt ... To be honest I'm not sure how to interpret these values as well and what that means. Maybe we should ask the question there ...

[mdietinger]

Well not sure anybody started to work on the issue, or this just a coincident what happened Yesterday to my sensor and another one in Stuttgart area.(Didn't find other ones) Around 8:30 my sensor started to show differences in PM values. I checked for other SPS30 sensors and found one in Stuttgart area which started to show expected behaviour at 00:00 the same day. This morning both the sensor in Stuttgart and mine slowly came back to the old behaviour. SW wise I am still on the old SW, but saw that OTA messages have been performed hours before the behavior changed. So not sure what is going on.

My sensor

Sensor in Stuttgart area

[hockenator]

Hallo, ich habe das gleiche Problem mit meinem SPS30. PM2.5 bis PM10 zeigen die gleichen Werte. Ein parallel laufender SDS011 zeigt das nicht! Frühere Tests mit dem SPS30 via UART und Terminalprogramm haben das Problem nicht gezeigt. Ich bekomme jetzt noch eine weiteren SPS30 zum test und verfifiziere das Problem via Kreuztausch und erneut Terminalprogramm. Ich persönlich vermute einen Bug in der airrohr-Firmware beim Auslesen des SPS30, wäre aber selber nicht in der Lage, diesen zu beheben. Hier der Screenshot vom Sensor SPS30:

und hier vom SDS011:

[Franz4596]

ich habe mein SPS30 z.Zt. nur testweise i.B., aber kurz Werte mit Räucherstäbchen getestet:

Die Werte sind zwar proportional zu Staubbelastung, aber PM-1-2.5-4-10 haben verdächtig ähnliche Werte!

[hockenator]

Ok, das ist ein wichtiger Hinweis und bestätigt meine Vermutung, dass wir es hier mit einem Bug in der Firmware zu tun haben, die ersten beiden Kanäle werden korrekt übertragen, dann vielleicht Bufferüberlauf und die Werte bleiben konstant. Das ist bei allen Staubkonzentrationen so. Rajko meint, ich solle mal eine Betaversion der FW probieren, mache ich gleich und teste.

Zur Sicherheit müsste man den SPS30 mal an einem RasPi oder so betreiben und den versuch wiederholen. Sind dort die Werte gut verteilt, wäre meine Hypothese bestätigt.

VG, Christoph

Von: franz notifications@github.com Gesendet: Donnerstag, 2. April 2020 03:01 An: opendata-stuttgart/sensors-software sensors-software@noreply.github.com Cc: hockenator hockenator@gmail.com; Comment comment@noreply.github.com Betreff: Re: [opendata-stuttgart/sensors-software] SPS30 PM10 no difference to PM2.5 (#673)

ich habe mein SPS30 z.Zt. nur testweise i.B., aber kurz Werte mit Räucherstäbchen getestet: https://user-images.githubusercontent.com/62063765/78200064-c7d42000-748d-11ea-80a6-cc339c46a4e7.png

Die Werte sind zwar proportional zu Staubbelastung, aber PM-1-2.5-4-10 haben verdächtig ähnliche Werte!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opendata-stuttgart/sensors-software/issues/673#issuecomment-607562670 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHSF3BNKWIURLWBXURPF6LTRKPPVXANCNFSM4KWNLF4Q . https://github.com/notifications/beacon/AHSF3BK3KVCZPVSE3WNTK3TRKPPVXA5CNFSM4KWNLF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEQ3KXLQ.gif

[hockenator]

PS zu Franz4596: Wenn du mit Räucherstäbchen dran warst, sind die PM4 und PM10 Werte vieeel zu niedrig. Allerdings werden die aus NC4 und NC10 abgeleitet, denn eigentlich ist der SPS30 wohl ein Partikel"zähler", der die gezählte Anzahlkonzentration via Dichteannahme in eine Massenkonzentration umrechnet. Bei natürlichen Aerosolen ist es praktisch NICHT möglich. dass oberhalb NC2.5 die Werte konstant bleiben! Da der Bug an mehreren Geräten zu sehen ist, glaube ich immer mehr an einen Bug beim Auslesen der Sensordaten.

[tom-r]

Hi, ich habe inzwischen schon die verwendeten sps30 Treiber durch die Original-Sensirion Routinen ersetzt (sps30_i2c.cpp + sps30_i2c.h) und das mit der beta / ESP8266 getestet. Bei mir sieht das exakt so aus, wie bei Euch : Die Kurve auf dem Grafik-Display sind eigentlich 2 übereinanderliegende PM2.5 und PM10 Kurven ... In den allerseltendsten Fällen sind da mal 2 Kurven zu sehen, und wenn, dann immer parallel und immer sehr nahe beieinander. Kein Vergleich zu dem SDS011, bei dem es PM10-Spikes nach oben gibt, während PM2.5 keine zusätzlichen Ausschläge hat. Also wenn, dann ist es ein I2C Problem (Störungen), oder es hat schon der I2C Sensirion Treiber ein Problem. Ich hab sogar Pullup Widerstande in die Kabel gelötet, das hat nichts gebracht. Was bei mir schon charakteristisch ist, daß nach einem Restart die ersten Messwerte auseinanderliegen, sich dann aber innerhalb weniger Messungen (bei mir im 5 Sek Rhythmus) immer weiter annähern. Wahrscheinlich ist das der sich aufbauende Luftstrom im Sensor. Ich hab auch schon den Sensor zerlegt um zu prüfen ob da Schmutz drinhängt wodurch evtl. größere Partikel per Software 'weggefiltert' werden...

Ich hab einen ESP32 hier, ich kann mal versuchen, den auf SPS30-UART umzustellen und dann statt des ESP8266 Boards in meinem Indoor-Sensor zu betreiben ... Der ESP32 hat Hardware-Serial und sollte die fixe Baudrate von 115200 des SPS30 schaffen ... Gruß, Thomas

[hockenator]

Na super, noch ein Leidensgenosse 😉

Gleiches Problem also!

Ich habe heute ein Original Sensirion Evalkit mit Sensirion Software bekommen. Das lasse ich mal etwas an meinem Notebook laufen.

Entweder das gleiche Problem, dann muss Sensirion ran…

Wenn nicht, wandert der Sensor (fabrikneu!) in meinen airrohr zum ESP8266 und dann schaun mer mal….

[hockenator]

Hi, habe jetzt 2 SPS30 auf meinem Fensterbrett parallel laufen (indoor), einer im airrohr (mit der neuesten beta-FW), der andere via UART direkt auf der Sensirionsoftware, hier der Zustand nach ca. 90min Dauerbetrieb:

Also das gleiche Verhalten bzw. das gleiche Problem! Scheint also doch nicht die FW vom airrohr zu sein... Bliebe noch das interne Datenhandling im Sensor, werden da vielleicht Mittelwerte gebildet? Nach dem Einschalten der Sensoren sah es bei beiden nach vernünftigen Verteilungen aus, die dann mit der Zeit sich ausglichen.... ich checke das morgen nochmal.

[pjgueno]

I can confirm the above stuff with my own sensor. There is indeed no variable repetition in the beta code so it seems to be the sensor itself.

[tom-r]

Ich hab die beta jetzt mal umprogrammiert auf UART /Hardwareserial und mit einem ESP32 getestet. Dabei hab ich die Original embedded-sps Treiber von Sensirion verwendet von hier. Das Ergebnis zeigt keinen Unterschied, PM2.5,PM4 und PM10 zeigen nach einer kurzen Hochlaufphase immer die gleichen Werte an. --> für mich ist das ein Firmware-Bug. Konsequenz: Wir sollten den Sensor von der Vorschlagsliste runternehmen oder zumindest mit einem entsprechenden Kommentar versehen, daß PM4 und PM10 nicht korrekt angezeigt werden...

[RikDrabs]

Is it really this sensor that is showing unusual or wrong data, or is there an entirely different problem?

I have in my possession an interesting Chinese module, which you can buy at https://www.banggood.com/PM2_5-Detector-Module-Air-Quality-Dust-Sensor-Tester-Detector-with-2_8-Inch-LCD-Display-for-Monitoring-Home-Office-Car-Tools-p-1588436.html?rmmds=myorder&cur_warehouse=CN. The module is equipped with a PMS5003 sensor. Yes, it is not an SPS30, but it has a comparable resolution to the SPS30: it measures particles of 0.3, 0.5, 1.0, 2.5, 5.0 and 10µm. By comparison the SDS011 (the standard Luftdaten sensor), is very coarse, since it only measures 2.5µm particles. The 10µm particle count is "calculated" off the one and only real 2.5µm measurement.

The interesting thing about the module at Banggood is that it not only incorporates the sensor, but also a display, which is capable of not only showing the PM1.0, PM2.5, and PM10 values, but also the count of the particles in each size class. This is the way sensors work: they count the particles of one or more different sizes, and then calculate with how many µg/m³ that corresponds in each of the outputted PM's. The calculation is done with a microprocessor in the sensor itself, which also supports the output protocol (serial line or other) that transfers the measurement to the outside world.

When testing this Chinese module, one thing is very clear: most of the counted particles are of 0.3, 0.5 and 1.0µm size. For moderate pollution the counts of 2.5, 5.0 and 10µm particles even stay at ZERO, in contrast to the 0.3µm particle count, which is in the same circumstances between 750 and 1000. The computing of the PM2.5 and PM10 values, which are each 6µg/m³ and equal, must be seen in the light of this particle count. After all, PM10 is the sum of all particles 10µm AND smaller, and PM2.5 is the sum of all particles 2.5µm AND smaller. The difference between PM10 and PM2.5 values is dependant only on the counts of the particles of size 5.0 and 10µm, of which the count is ZERO, so the difference is ZERO too.

That the SPS30 sensor displays the same behaviour of equal PM2.5 and PM10 as the PMS5003, might be proof that they're both more correct than the SDS011.

If you're still in doubt, then read the following: http://www.opengeiger.de/Feinstaub/CalibDocu.pdf about the SDS011 sensor.

[tom-r]

Hi, found this yesterday evening ... And in detail why all those small laser scattering sensors like PMS5003, SPS30, etc mostly show poor PM10 results ...

It's a simple matter of logic: I don't believe that I have to use the vacuum cleaner every second day in my house, 'cause the dust bunnies are flying around and the SPS30 report's more or less no bigger particles than PM2.5 at all ... this simpy can't be true...

Anyway, we promote the SDS011 in the campaign and it shows let's say 'reasonable' PM10 values (at least something closer to reality than the SPS30 does), and we shouldn't simply use the SPS30 and as I learned with the articles above also the PMSes as drop in replacement or we'd mess up the reported PM10 data ... Or we do not report PM10 at all from these sensors ...

That's actually why I share my standard SDS011 setup to the luftdaten.info page, and use the SPS30 for indoor only ...

I wasn't aware of this PM4/PM10 issue when I bought the SPS30. And I wouldn't have bought it, if there had been a hint on the luftdaten.info page ...

BR, Thomas

[hockenator]

Hello tom-r and RikDrabs, ich habe gestern wieder einige Untersuchungen mit dem SPS30 durchgeführt. SPS30 Tests.pdf Möglicherweise habt ihr beide Recht, weil wir mit dem SDS011 und SPS30 wohl "Äpfel und Birnen vergleichen". Beide Systeme sind zunächst Partikelzähler und generieren aus einem Streulichtsignal einen aerodynamischen Äquivalenzdurchmesser eine Partikels. Daraus ermittelt man die Anzahlkonzentration (counts/cm³). Daraus kann wieder einfach das Volumen der Partikel und über eine Dichteannahme (welche?) die Masse berechnet werden, das wird dann von den realen cm³-basierten Werten weiter auf m³ hochgerechnet, so dass dann eine Massenkonzentration µg/m³ entsteht. Also schon mal viele Hochrechnungen. Da haben wir aber 2 Probleme:

1. Durchmesser und Volumen/Masse sind kubisch proportional, die Verdopplung des Durchmessers führt zur 8-fachen Masse des Partikels, oder anders: ich benötige 8 Partikel 1µm um die Masse eines 2µm-Partikels zu erreichen! Deswegen haben viele schwebende Feinstaubpartikel (etwa <1µ) kaum einen Masseeinfluss, wenn auch große Partikel da sind.
2. Und da scheint mir die Lösung des Problems zu sein: der SPS30 misst wirklich real ab 0,3µm, auch die anderen Klassen. Aber bei der Messung erfasst er die "schwebenden" Partikel 0,3µm ... 1µm viel besser als die größeren, die leichter absinken. Somit erfasst der SPS30 bei PM1 eine Grundmassenkonzentration wegen der hohen Zahl von Feinstaubpartikeln <1µm. Darüber kaum mehr Partikel, daher auch kaum Massezunahmen (siehe mein Foliensatz). Da PM2.5 und PM10 kummulativ dargestellt werden und PM2.5 eine Teilmenge von PM10 ist, scheint es nur logisch, dass sich PM2.5 und PM10 am SPS30 kaum unterscheiden!

Für mich scheint jetzt klar, dass die Firmware von Luftdaten korrekt ist. Wahrscheinlich müssen wir fragen, ob der SPS30 oder der SDS011 die bessere Wahl für Feinstaubmessungen ist. Scheinbar führt das Banggood-System ja in die selbe Richtung wie der SPS30, weil sie eben etwa um Faktor 10 empfindlicher messen und damit andere Daten in die Berechnungsgrundlage einbringen, während der SDS011 "nur" bei 2,5µm misst. Natürlich setze ich voraus, dass der SPS30 die Partikel im Bereich 1µ - 10µm ebenso gut messen kann. Das wird man aber nur auf einem Aerosolprüfstand richtig sehen können. Also: Sowohl SPS30 als auch SDS011 scheinen auf Basis ihrer technischen Eigenschaften korrekt zu messen. Aber welches System wird dem Ziel der Feinstaubmessung im Sinne von Luftdaten.info besser gerecht? Spannende Frage....

[RikDrabs]

@hockenator: Indeed, that's the question. Which sensor is the best for the Luftdaten.info project? Since the datebase is full of measurements with the SDS011 sensor since 2015, i'm afraid that for comparison reasons with the old data it is best to stay with the SDS011, although the more recent sensors like the SPS30 and the PMS5003/PMS7003 give more accurate and fine detail. It is also better not to mix the measurements of the SDS011 with the more recent sensors on the same map, as this can lead to wrong conclusions. Maybe in the future, when the SDS011 needs replacement after its calculated lifetime of 6,8 years, then a new standard sensor can be adopted over the entire network?

[tom-r]

Or : throw PM10 over board and show only PM2.5 and smaller with those new sensors, like SPS30,PMSx003, etc. I think we do not have a chance to apply a generic correction factor .. For me, one of the lessions learned is, that PM10 is not comparable btw. SDS011 and SPS30/PMSx003/... So if using one of these sensors for the luftdaten.info project then simply exclude PM4/PM10 from the data upload ... At least this is not messing up the existing data. BR, Thomas

[ricki-z]

Many official stations in Germany only measure PM10. So without that value you haven't any comparable value. For the case of any technical problem (i.e. wrong power supply -> values too high) you haven't any hint.

One of the comments mentioned recommendations: We never recommended any other PM sensor than the SDS011 (or is there any other PM sensor mentioned in our instructions). All other sensors supported by our firmware were included for testing or on request of other air quality projects that wanted to use our firmware. Thats the reason why 99% of all sensors are SDS011.

[hockenator]

@RikDrabs: I completely agree with you in #1 newer sensors SPS30/PMSx003 are more sensitive than SDS011 but #2 data mixture with SDS011 at luftdaten map doesn't make sense and makes confusion for all.

@ tom-r: That seems to me to be the best compromise in this situation. Since I have both systems, I would also run them in parallel in order to be able to provide long-term comparison data. To do this, the PM4 and PM10 of the SPS30 would have to continue. Or I push the to OpenSensorMap only. Any other suggestions?

[ricki-z]

And: None of the supported PM sensors can measure down to 0.3µm. Not with the optical system used by all of them. All are working with red laser light (~700nm = 0.7µm). And no, optical effects are limiting the particle size that could be detected to only a little bit below this (and not to half of wavelength as the marketing departments are writing...). Next point: calulating the mass per volume: Yes, all of these sensors are particle counters. And all of them try to detect this count for different sizes. After that there is no volume calculation per particle. The manufacturers use "average dust" with a known mass per particle count per size bin.

[hockenator]

ricki-z: Do you know this "average dust" factor? i would try to calculate my SPS30 counting data ahead to the presented mass concentration.

Regarding your other comment: That is probably correct that only SDS011 is mentioned in the permanent project, especially since this improved one can be procured as e.g. the SPS30. But: it is in the device configuration of the FW and since I had access to a SPS30, I was just curious :-).

I think we should look for a solution that does not disturb and confuse the 99% of SDS011 network, but allows solutions with SPS30 / PMSx003 to be included. Maybe as part of an evaluation mode? I think that in the long term, technical development or the legislature will go in this direction anyway. In this respect, maybe a piece of the future of 'luftdaten' can already be seen here?

[tom-r]

@hockenator : As a starter for your own investigations : not sure if you know this repository? There's a reference to SPS30.odt in the repository. Please have a look at it, that guy did already some investigations, comparing PM2.5 and PM10 between SPS30/SDS011. And yes, he was facing the same PM10 issues, as we all do ... ;-)

BR, Thomas

[friedpa]

Low cost devices like the SPS30 or the SPS011 are only for hobby applications, far away from scientific proofed methods and accuracy Please read the Paper: Laboratory evaluation of particle size-selectivity of optical low-cost particulate matter sensors Laboratory_evaluation_of_particle_size-selectivity.pdf

Example: Sensirion SPS30 Response function of the SPS30 is shown in Figure 4c (PDF Attached). The valid detection range of the first bin (0.3 – 1.0 μm) is approximately < 0.9 μm. The second, third, and fourth bin (supposedly corresponding to 1.0 – 2.5, 2.5 – 4.0, and 4.0 – 10μm) are nearly identical having valid detection ranges of approximately 0.7 – 1.3 μm. The identical detection ranges indicates that these bins may have been factory calibrated using the same test aerosol. The SPS30 is a relatively new sensor (introduced to the markets in late 2018), and Web of Science nor Scopus literature research showed any existing studies as of September 2019. However, South Coast Air Quality Management District (SCAQMD) has conducted a preliminary field test where three SPS30 units were compared to three different federal equivalent method (FEM) monitors (SCAQMD, 2019). The results of this test showed that the SPS30 sensors had very low cross-unit variability (~1, 1.3, and 2.4 % for PM1, PM2.5, and PM10, respectively) and, more importantly, the accuracies for the measurement of PM1, PM2.5 and PM10 decreased from R2 ~ 0.91 to 0.83 and further down to 0.12, respectively. These observations are in high agreement with the results of this study, and furthermore, illustrate how a sensor with limited operational range may exhibit a near regulatory grade accuracy if the measured size fraction is in align with the valid detection range of the sensor (< 0.9 μm and PM1). On the other hand, the severity of data misinterpretation is apparent when the sensor measurement is extended to cover particle sizes which it cannot observe.

[ricki-z]

@hockenator : Here you can find a list of norm dusts: https://www.ksl-staubtechnik.de/de/pruefentesten/normstaeube/ And as you can see there are different norms. So the values of a sensor may depend on the dust used for development. The factors and "optimization" algorithms used by the manufacturers are intellectual property of them. So it may hard to find the exact way of how to get the mass concentration from particle count.

At the moment we show all PM sensor types on our map. But the exact type of every sensor is part of our data stream. So it's possible to build a filter to only show SDS011 (map source is available here on github, if someone want's to implement this).

For future sensors we will do the same as for the PMSx003 or the SPS30. We will include them in our firmware and hopefully some users are willing to try them for a longer time. Only this way we can find problems like in this issue.

[RikDrabs]

Looks like any review I can read concludes to the same: SPS30 & PMSx003 sensors inherently can't measure particles with sizes above 2 to 2.5 µm, and so their PM10 measurements may be unreliable. And that may be due to their construction & firmware to measure finer particles up to their datasheet limit of 0.3µm. But this datasheet limit is questionable: the red laserlight used to perform the measurement has a wavelength of 700 nm or 0.7µm. I understand therefore that a PM0.3 value is not given: the PM measurement values start at PM1.0, both on the SPS30 and the PMSx003.

So what do we have: SDS011: PM2.5 is OK; PM10 is necessary for comparison with official meters, and is good enough. SPS30/PMSx003: PM1.0 is OK; PM2.5 is acceptable; PM10 is questionable, maybe wrong.

A good solution would be a combination of both. The SDS011 to make the PM10 measurement; AND the SPS30/PMSx003 after calibration with both PM2.5 values (SDS011<->SPS30), for the PM2.5 and PM1.0 values. This way, we have the best of both worlds, and measurements for PM10, PM2.5, and PM1.0.

Can the SDS011 and the SPS30; or the SDS011 and the PMSx003 physically be connected AT THE SAME TIME? (ESP8266 pins, protocols, etc)

[hockenator]

friedpa: Thank you for your explanation, great!

RikDrabs: Good idea! From my understanding SDS011 uses serial interface at D1/D2, the SPS30 uses I2C at D3/D4. So it could run....

ricki-z: What o you think, is it possible to connect both sensors at the same ESP8266 to run it simultaneously?

[tom-r]

Yes you could run them in parallel [Edit: , the SDS011 is connected with Softwareserial, and the SPS30] in I2C mode. But you cannot run the SPS30 on UART (serial) with the ESP8266 ! The ESP8266 only supports SoftwareSerial and this is too slow for the fix 115200 baud of the SPS30 ! You'd need to switch to ESP32 then.

But it does not make sense : the SDS011 is also better at PM2.5 (compared to PM10), same as SPS30. Just read the link above from RikDrabs (http://www.opengeiger.de/Feinstaub/CalibDocu.pdf ) and also sps30.odt from the link I posted yesterday in paulvha's repo . According to his investigation, SPS30 and SDS011 are pretty equal on PM2.5 ... If combining 2 sensors, then we'd need a good PM10 sensor as couple for the SPS30.

And despite that, it doubles the cost of a airrohr sensor box, which is probably not what we want ...

BR, Thomas Edit : clearified connection options on top

[friedpa]

Ladies and Gents, considering the results of the scientific study: https://doi.org/10.5194/amt-2019-422 Laboratory_evaluation_of_particle_size-selectivity.pdf it would make sense, if, as I can read above that 90% of the sensors in the luftdaten sensor network are SDS011, that the PM10 values are removed (or clearly marked as not accurate) as the sensor is not capable to read this value accurately. If you take a look at the result of the possible readable particel size: and: the particle detection and therefore the measurements results, as said above, must be seen as: " ....Similarly to the PMS5003, the SDS011 is not suitable for the measurement of coarse mode particles, and the measurements of PM10 can be grossly inaccurate...." and: "However, due to the clearer difference between the two detection ranges, the SDS011 has potential to measure PM2.5 more accurately than the PMS5003 .... Previous studies have shown that the SDS011 can be reasonably accurate in the measurements of PM2.5..." Maybe more investigation (other studies) is necessary, or we could contact the Main-Author: Joel Kuula (joel.kuula@fmi.fi) to further discuss his recommendation to: "... Moreover, an artificial correction factor approximating changes in the measured size distribution may be possible to calculate from the ratios of bin 1 and bin 2 signal strengths......"

I see this project as an absolute positiv contribution in the fact that we have to watch very closely polluted air and find the originator(s) of said pollution.

[stewecar]

only my 2 cents about that.. these are this weekly PM10 readings (PMS7003 sensor but in parallel with a SDS011 with similar values..) and this is the graph from the Enviromental Regional Tuscany Agency (ARPAT) in their website related to a very near station to my home: (if you wanna see the values just go to the page's website by 'touching' the day's column) http://www.arpat.toscana.it/temi-ambientali/aria/qualita-aria/rete_monitoraggio/scheda_stazione/FI-MOSSE/indicatori_giornalieri As you can see, for example, the day 1st on april i got values from 5 to 23 micrograms for an average value of about 14 micrograms (approx and not maths calculated) while the professional station says 11.. the day 2nd on april i got about 16 average and the professional one quite the same.. Not different situation about the 3rd on april.. My station about 15 and the professional one again 15.. The day 4th there are a lot of spikes and strange values on mine..but is about a range of 20 micrograms at least..the professional one is at 17.. The day 6th is the more relavant situation, maybe..when professional ARPAT station detects 24 micrograms and mine offers values between 18 and 32 but with a considerable growth during the day..with an average of about (not calculated but as i can see..) 25 micrograms. Maybe this is only a lucky effect..anyway only to contribute to this discussion..this is not a 'study' or a peer reviewed paper :). stefano

[systembolaget]

PM 10 is not measured by this sensor but calculated from PM 2.5, which is measured. The utility value of this sensor is high, compared to a $20,000 beta attenuation monitor, for example, but it is not good for everything.

[M10CUBE]

Hi all, The info provided here is extremely useful. I am relative new to sensor.community and I am seeking for the correct data to setup in firmware for using SDS011 sensor. I have 6 sensors non the platform and all showing at least 20% - 30% lower values for PM2.5 and PM10 (comparing with other sensors in the area and the official ones (university and governmental) I have the default settings here as is on the firmware (ESP32 CPU):

constexpr const unsigned long SAMPLETIME_MS = 30000; // time between two measurements of the PPD42NS constexpr const unsigned long SAMPLETIME_SDS_MS = 1000; // time between two measurements of the SDS011, PMSx003, Honeywell PM sensor constexpr const unsigned long WARMUPTIME_SDS_MS = 15000; // time needed to "warm up" the sensor before we can take the first measurement constexpr const unsigned long READINGTIME_SDS_MS = 5000; // how long we read data from the PM sensors constexpr const unsigned long SAMPLETIME_NPM_MS = 1000; constexpr const unsigned long WARMUPTIME_NPM_MS = 15000; constexpr const unsigned long READINGTIME_NPM_MS = 15000; // how long we read data from the PM sensors

My sensors: https://maps.sensor.community/#16/39.3606/22.9694  https://maps.sensor.community/#16/39.3636/22.9498 https://maps.sensor.community/#16/39.3708/22.9654 https://maps.sensor.community/#16/39.3463/23.0015 https://maps.sensor.community/#16/39.3694/22.9557 https://maps.sensor.community/#16/39.3751/22.8845

Greatly appreciate to direct me in another post as well to gather similar info Thank you very much