New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending time too low with respect to the SDS011 timing requirements #426
Comments
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 |
How can I disable the shutdown of the SDS011 from the web interface? |
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". |
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. |
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. |
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? |
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. |
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. |
To the averages used bey reference sensors and legislation: |
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). |
…#426) Just never stop the sensor if the interval is too short. This is better than what it did so far, always stop it and never start it (leading to no measurements)
Fixed now in Beta branch. |
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? |
If SDS011 is used and the sending time interval is lower than 20 seconds, it is not possible to get SDS011 data.
The text was updated successfully, but these errors were encountered: