You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EC No 13/2007 annex 1 mentions that the minimum data capture for particulate matter should be 90%, excluding servicing of instrumentation. It does not give a standard for data availability.
Sensor.community and NAM firmware defaults to measurement intervals of 145 seconds.
Thus in one (1) year (excluding leap year = 366 days) there should be 365 times 86400 ÷ 145 = 217.489 measurements recorded. Below 90% (<.895 ≅ 194,653 measurements) this percentage should be displayed in yearly view as "Capture: ".
It's a pity that "Sensor uptime" is displayed but not pushed upstream with each measurement. One could argue that when the sensor is not up, that time can be seen as "service interval". For the time being, this missing downtime might be worked around with the user being able to configure a "instrumentation servicing time" value per device (to be substracted from the number of seconds per year).
To make the value even better, exclude zero (0) measurements as invalid, as well as measurements where the PM2.5 value is identical to the PM10 value. Another questionable thing related to data quality are outliers, as well as measurement values that are identical to the previous reported value (In my opinion not likely to happen). I mean PM2.5-#1 == PM2.5-#2 && PM10-#1 == PM10-#2. Only PM2.5 to be the same as the previous measurement (PM2.5-#1 == PM2.5-#2) does happen.
The text was updated successfully, but these errors were encountered:
EC No 13/2007 annex 1 mentions that the minimum data capture for particulate matter should be 90%, excluding servicing of instrumentation. It does not give a standard for data availability.
Sensor.community and NAM firmware defaults to measurement intervals of 145 seconds.
Thus in one (1) year (excluding leap year = 366 days) there should be 365 times 86400 ÷ 145 = 217.489 measurements recorded. Below 90% (<.895 ≅ 194,653 measurements) this percentage should be displayed in yearly view as "Capture: ".
It's a pity that "Sensor uptime" is displayed but not pushed upstream with each measurement. One could argue that when the sensor is not up, that time can be seen as "service interval". For the time being, this missing downtime might be worked around with the user being able to configure a "instrumentation servicing time" value per device (to be substracted from the number of seconds per year).
To make the value even better, exclude zero (0) measurements as invalid, as well as measurements where the PM2.5 value is identical to the PM10 value. Another questionable thing related to data quality are outliers, as well as measurement values that are identical to the previous reported value (In my opinion not likely to happen). I mean PM2.5-#1 == PM2.5-#2 && PM10-#1 == PM10-#2. Only PM2.5 to be the same as the previous measurement (PM2.5-#1 == PM2.5-#2) does happen.
The text was updated successfully, but these errors were encountered: