Sending time too low with respect to the SDS011 timing requirements

[giobus75]

If SDS011 is used and the sending time interval is lower than 20 seconds, it is not possible to get SDS011 data.

[ricki-z]

This is a wrong assumption. You can read a value every second after a warmup time. So we only need to disable the shutdown of the SDS011 for measurement intervals that low

[giobus75]

How can I disable the shutdown of the SDS011 from the web interface?

[ricki-z]

It's not possible to disable this on the web interface. Such a low measurement interval would produce a very high load on our servers. So your sensor may be blocked for "spamming". What exactly is your goal? May be you shoul dfork the source code and disable the shutdown functions for your version. Otherwise you may wait for the next release version where we will disable the shutdown for timespans lower than 20 seconds.

[giobus75]

I am a bit confused. If it is not possible to disable the shutdown of the SDS011 from the web interface, it may be better to limit the range of values from the sending time field. In my opinion, the system would be more robust. My PR had that purpose.

[ricki-z]

Even in this case we need to change the firmware and the firmware images. But if we do this then we can just implement the disabled shutdown if the interval is lower than 20 seconds. And again, the development is done in the beta branch. All beta versions need to be tested thoroughly as we have more than 10.000 sensors that use this firmware. This needs some time.

[ropeters68]

Instead of reducing the cycle time it might be wise to use more samples per measurment (e.g. 120 values for 1 measurement) which gives less data traffic and far less loss on warm-up time (min. 20 seconds per cycle). As most reference sensors use hourly values and legislation uses daily averages what is the gain of using short cycles?

[ropeters68]

Additionally I recently saw a test comparing the volume of air passing through the sensor (SDS011), there are quite some differences between the SDS011 sensors (5): 1,50 -1,90 l/min, this will impact the accuracy too.

[giobus75]

My concern is not about using short sample periods but to avoid that a user puts a value less than 20 seconds on the web interface disabling, in fact, the SDS011. I think that the web interface should refuse values that make the system not totally working. In general, I agree with @ropeters68 that using more samples per measurement is a good tradeoff.

[ricki-z]

To the averages used bey reference sensors and legislation: We try to find sources of PM. Hiw would you do this with a daily average. There you can't that there are high values i.e. in the winter between 18 and 20 o' clock when most people heat up their flats. Or that it is really the traffic because with a higher resolution you can see the higher values during rush hours. For this the resolution needs to be much higher than daily or hourly. You mostly don't need the absolute values but the trends of PM. Together with other data (weather, traffic counts, list of local events,...) you can then try to find the sources of pollution. You can look for some works at: https://btw.informatik.uni-rostock.de/index.php/de/programm/data-science-challenge

[ropeters68]

Thank you for the link, very interesting stuff! Regarding the measurement cycle I don’t mean we should go for daily or hourly averages. I am in favour of higher resolution measurements but the current cycle is not that good (as PM is not a homogeneous gas, averaging 3 values (30-60 ml of air) per cycle seems little). As you know in the current cycle the actual measurements are done in 120 seconds in an hour, with one measurement per second you have 120 values, from which 40% is thrown away. So looking for PM sources with effectively 72 measurements (in 24 averages) per hour can’t be that accurate (we have 2 sensors colocated sensors that tend to miss low peaks compared to the BAM 1020 (at a traffic rich road)). Additionally very inefficient use is made of the sensor, only 20% of the up-time is used for measurements. Why not make the cycle time, for example, 5 minutes: 20 seconds warm-up, 120 seconds to measure, 160 seconds waiting. This would make the sensor up-time 2,8 times higher but your values are based on 20 times as much measurements only increasing the inactive time with 35 seconds per cycle (and honestly due to corrosion of the materials it’s not likely that all sensor parts would survive more than 2 years).

[dirkmueller]

Fixed now in Beta branch.

[tuxick]

Watching output of my SDS011, i noticed first reading(s) tend to be higher than last ones. Is WARMUPTIME_SDS_MS = 15000 a compromise? I could even imagine correcting data based on warmuptime. Maybe print a trend analysis in debug output to find out?