Suddenly, the PM2.5 measurements of my outdoor monitor jump from 0 to some value and then back to 0 within 1-3 time steps while previously they were changing gradually across time as would be expected. See figure below for details.
I haven’t seen this behaviour before and I would not know what could be the reason for the outdoor PM2.5 concentration to change so strongly so rapidly. Hence, I wonder whether these measurements are correct or could indicate a hardware malfunction.
Likely correct. There are some compensation algorithms in place by default and that calculation can result in going from 0 up to 3 directly as it crosses thresholds for the algorithm based on levels and humidity.
It looks strange. Can you PM me your serial number and I have a look.
I think these patterns are a result of the implementation of the official US EPA correction algorithm for wildfires when operating in very low concentration and certain humidity concentration ranges.
See especially the section about negative values at the end of the blog post. I believe these could lead to the “jumps”.
@Siriel_AirGradient please add your comment as well.
The EPA correction algorithm uses relative humidity to correct PM2.5. Based on the raw PM2.5 reading and humidity, negative corrected values can be obtained. We implemented the algorithm in such a way, that all negative values are replaced by the reading “0 ug/m3” instead. Additionally, we decided to keep the corrected PM2.5 value at 0 ug/m3 if the raw value is 0 ug/m3 (the algorithm as stated by EPA does not do that).
In consequence, patterns as listed below exist when the raw reading changes between two different low values (in this case 0.1 and 0 ug/m3). Note that this is more relevant for low humidity environments.
This might explain the cases reported in this thread. Feel free to post your humidity readings and then I can do some calculations
I have been getting this in Australia mostly in the last two days and our humidity is over 50% most of the time as we are not in a low humidity area.
It seems to be happening around 2.x values it will go to zero and back up to 2.x or just stay on zero for a while. I thought I had a faulty connection or error but this is the only sensor and I rebooted. System in operation since Aug 2024. We have no wildfires where I am and rarely do.
Is the EPA correction algorithm even relevant in Australia? This seems new and hasn’t been noiceable up until a week ago and we are not in the 0.1 range, outdoors is usually above 2.0 ug/m3 so the explanation doesn’t seem to match what I understand from your descrition above and the graphs shown. As I read it for those values my humidity would have to be very dry at below 30% and our mininum humidity when this happens is over 50%.
Yesterday it dropped to zero for 6 hours solid with some other random zero reading either side. I thought we could overlay graphs but I only seem to be able to select one graph at time for different monitors of the same measurement so compare inside same measurment to outside but not overlay multiple measurements in Analytics.
My previous plots refer to raw relative humidity as reported by the Plantower sensors without any correction applied (that’s the humidity the EPA correction uses). We do not know why, but we observed that these sensors underestimate relative humidity. Below an example from an AirGradient OpenAir monitor colocated with a reference in Sydney (Australia). AirGradient data is shown in blue, while the reference is red (hourly averages in 2024).
Does the pattern persist if you switch off the EPA correction? Alternatively, you can export the raw data via the export option in the dashboard and make a plot in excel to look at the pattern (the exported data is raw). This should quickly answer whether the jumping is caused by actual measurements or the correction algorithm.
“Is the EPA correction algorithm even relevant in Australia?”
We observed that the Plantower monitors overestimate PM2.5 at concentrations above 10-20 ug/m3. This finding applies to all investigated locations so far with and without wildfires (America, Europe, Asia, Africa, Oceania). We have no explanation, but we believe it is based on how Plantower calibrates their monitors. The EPA algorithm does a good job at bringing down the high raw readings, while maintaining the low readings, so we recommend using it also in Australia.
Ive noticed that whenever someone smokes in that Room where the airgradient is located, the PM2.5 and PM10 counter show unknown state in homeassistant and also the PM2.5 on the device itself shows “-” for some time.
Is it a normal behaviour that in case the PM values go up very fast two (2.5 & 10) of the four PM values show unknown until values are not rising so fast any more?!
The sensor drops out at extremely high pollution levels (much more than you typically see in even very polluted areas).
It seems you create more than 1000 ug/m3 by smoking when the sensor drops out. This is as per spec the upper limit of the sensor. So the behavior is to be expected.
Yes correct, it then jumps over 1000. Thanks, so i know its normal behaviour.
I turned off the correction and all the zero levels went back to what is expected.
Thanks for all the detail. The summary of what your saying as I read it is the sensor isn’t perfect as we know and your algorithm while not perfect helps remove problematic measurements but in the process creates zero values rather than negative ones.
Not sure if there is some smoothing or other process to stop the graph plotting zero and apearing to malfunction but I expect I can’t be the only person that thinks the behaviour looks like a faulty sensor and many won’t understand this math or even look.
I guess if you have an excess sensor order level this will be why and that waste of time and money would be good to avoid.
I wonder if you can have some sensor diagnosics run that looks at the data history and the adjusted values and advises the customer that this is normal and then presents the reason for people wanting to know why.
At some point all the sensors are likely to fail before the rest so a guide when to replace would be a good feature if its possible.
Many thanks @Siriel_AirGradient for the explanation.
I checked the data again and humidity was between 27% and 40% from 11:30AM until the end of the period and between 40-60% between 1AM and 11AM.
Thanks for sharing the RH ranges! I do not know whether your RH and PM2.5 numbers are raw or corrected, but I tried several combinations and I cannot explain why we observe this pattern in your case. Does it disappear when you switch off the correction?
Many thanks @Siriel_AirGradient . The posted figure was based on corrected data. Some raw PM2.5 and humidity data is attached below. Could sent more but there doesn’t seem to be a possibility to upload files here.
Best, Carsten.
Local Date/Time,PM2.5 (μg/m³),Humidity (%)
2025-01-26 16:00:00,0,40
2025-01-26 15:55:00,0,40
2025-01-26 15:50:00,0.1,39
2025-01-26 15:45:00,0.1,39
2025-01-26 15:40:00,0,37
2025-01-26 15:35:00,0,36
2025-01-26 15:30:00,0.1,35
2025-01-26 15:25:00,0.6,35
2025-01-26 15:20:00,0.6,35
2025-01-26 15:15:00,0.5,34
2025-01-26 15:10:00,0.4,34
2025-01-26 15:05:00,0.1,33
2025-01-26 15:00:00,0.5,32
2025-01-26 14:55:00,0.7,31
2025-01-26 14:50:00,0.6,29
2025-01-26 14:45:00,0.4,28
2025-01-26 14:40:00,0,27
2025-01-26 14:35:00,0,26
2025-01-26 14:30:00,0,26
2025-01-26 14:25:00,0.3,26
2025-01-26 14:20:00,0.2,26
2025-01-26 14:15:00,0.2,25
2025-01-26 14:10:00,0.4,26
2025-01-26 14:05:00,0,26
2025-01-26 14:00:00,0,27
2025-01-26 13:55:00,0,27
2025-01-26 13:50:00,0.3,27
2025-01-26 13:45:00,1.4,27
2025-01-26 13:40:00,0,28
2025-01-26 13:35:00,0,27
2025-01-26 13:30:00,0,27
2025-01-26 13:25:00,0,27
2025-01-26 13:20:00,0.4,27
2025-01-26 13:15:00,0.1,27
2025-01-26 13:10:00,0,27
2025-01-26 13:05:00,0.2,28
2025-01-26 13:00:00,0.1,27
2025-01-26 12:55:00,0.2,28
2025-01-26 12:50:00,0,29
2025-01-26 12:45:00,0.3,30
2025-01-26 12:40:00,0.3,32
2025-01-26 12:35:00,0.2,31
2025-01-26 12:30:00,0,32
2025-01-26 12:25:00,0,34
2025-01-26 12:20:00,0.2,35
2025-01-26 12:15:00,0.8,36
2025-01-26 12:10:00,3.5,36
2025-01-26 12:05:00,0.2,36
2025-01-26 12:00:00,0,37
2025-01-26 05:00:00,0,47
2025-01-26 04:55:00,0,47
2025-01-26 04:50:00,0,47
2025-01-26 04:45:00,0,47
2025-01-26 04:40:00,0,47
2025-01-26 04:35:00,0,48
2025-01-26 04:30:00,0,48
2025-01-26 04:25:00,0,48
2025-01-26 04:20:00,0,49
2025-01-26 04:15:00,0,50
2025-01-26 04:10:00,0.3,50
2025-01-26 04:05:00,0,51
2025-01-26 04:00:00,0,51
2025-01-26 03:55:00,0,51
2025-01-26 03:50:00,0,51
2025-01-26 03:45:00,0,51
2025-01-26 03:40:00,0.2,51
2025-01-26 03:35:00,0,52
2025-01-26 03:30:00,0.2,52
2025-01-26 03:25:00,0,52
2025-01-26 03:20:00,0.1,53
2025-01-26 03:15:00,0.1,53
2025-01-26 03:10:00,0,53
2025-01-26 03:05:00,0,53
2025-01-26 03:00:00,0,53
2025-01-26 02:55:00,0,54
2025-01-26 02:50:00,0,54
2025-01-26 02:45:00,0.1,55
2025-01-26 02:40:00,0,55
2025-01-26 02:35:00,0.2,55
2025-01-26 02:30:00,0,56
2025-01-26 02:25:00,0,57
2025-01-26 02:20:00,0,57
2025-01-26 02:15:00,0,58
2025-01-26 02:10:00,0,59
2025-01-26 02:05:00,0,58
2025-01-26 02:00:00,0,59
Thank you @Carsten for providing the details!
Let’s look at the data from 2025-01-26 15:55:00 with raw PM2.5 of 0 ug/m3 and raw RH of 40 %. According to the EPA algorithm, this would result in a corrected PM2.5 reading of 2.3 ug/m3. However, we do not know whether the raw reading of 0 was at the detection limit of the sensor or below. The true value could genuinely be below 0.5 ug/m3, which is not accounted for by the EPA algorithm. That’s why whe decided to not apply correction to raw readings of 0 ug/m3. In consequence, your raw reading of 0 ug/m3 shows up as a ‘corrected’ value of 0 ug/m3.
5 minutes later, the raw PM2.5 reading was at 0.1 ug/m3 at raw RH of 39 %. Now, we are certain that the PM sensor has actually counted something, so we do apply the correction, which gives us a corrected value of 2.4 ug/m3. As a result, we see this jump from 0 to 2.4 ug/m3, while it jumps back to 0 a couple minutes later.
We understand this leads to a weird pattern that raises doubt on the accuracy of the sensor. The pattern would look smoother (and subjectively ‘better’) if we applied the algorithm also on raw PM2.5 readings of 0 ug/m3 (as done by the EPA). However, we believe this practice introduces a bias as it may lead to corrected PM2.5 values of up to 6 ug/m3 even if the true value is indeed 0 ug/m3.
Your zigzag pattern is the result of a raw reading jumping around the detection limit of the sensor in combination with relatively low humidity.
@Agent86 Thank you for the feedback! I completely agree. We are working on ways to identify faulty sensors and alert the user. This is challenging as PM2.5 is dynamic and can change very quickly (unlike temperature for example). This makes it hard for us to identify unrealistic readings with high certainty, while keeping the number of false positives low. Although we made progress on this end, I do not expect a feature to be ready in near future.
Many thanks for the detailed explanation!
Best, Carsten
For those in this thread following along,
I am not an AQ expert or a scientist, I am an IT professional. I’m also not affiliated with AirGradient, I am just some guy on the internet.
I think a part of the problem here is how we are sampling data across various implementations.
As discussed here:
The AirGradient will report very differant numbers within very short periods of time. I expect this behavior to be inherent to the sensor itself. Some compensation for this can be applied for graphing and display purposes, as discussed here:
Also, as stated in the above discussion, I would argue that such smoothing should only be applied for display purposes. Seperate from my PR above, I also think the AirGradient App should also reflect better logic. Take a few samples 3 seconds apart and average them before storing a value in the cloud . The local API server should always be the source of truth for data at a quantum in time, and it should not be smoothed.
Applying correction algorithms like the EPA one is appropriate, but altering the data for smoothing purposes will negatively affect integrations that have a very high sample rate.
Since the Air Gradient Cloud App has a sample rate of 5 minutes, smoothing can, and should be applied. But again, this smoothing should be done in the cloud by collecting more samples, not in the device IMO. For each 5 minute interval, collect 3 samples 3 seconds apart and average them. This would, in my opinion, result in the best data for this application.
If we assume the local API as a single source of truth, much of the uncertainty can be eliminated.
@Carsten do you have a Linux or MacOS machine available in your environment?
Running this script will sample PM2.5 from the API every 3 seconds for 5 minutes. You’ll have to replace the IP with your IP or the mdns name of your sensor.
for i in {1..300}; do echo "$(date '+%Y-%m-%d %H:%M:%S') pm02Compensated: $(curl -s http://10.69.10.92/measures/current | jq -r '.pm02Compensated')"; sleep 3; done
I’d be interested in what this looks like versus the graphs you are seeing.