FineOffset WH0290: PM10 is apparently not really PM10

[gdt]

The WH0290 decoder produces two 14-bit fields, PM2.5 and PM10. So far, it seems like it is always true that

• PM10 = PM2.5 + 1 (PM2.5 is 0 to 14)
• PM10 = PM2.5 + 2 (28 to ?)
• PM10 = PM2.5 + 3 (>=110?)

This doesn't make sense from a physical viewpoint of the definitions of PM10 and PM2.5, and the device is advertised only as a PM2.5 monitor. However, EcoWitt says that it has a "Honeywell HPM Series Particle Sensor" and that is documented to do both PM2.5 and PM10.

Obviously more understanding is needed, and this issue is just to note that the situation is unclear.

[peterchs]

I did some digging on these honeywell HPM series particle sensors, and their datasheet does state the following (my emphasis):

2 PM1.0 in μg/m3, PM4.0 in μg/m3, and PM10 in μg/m3 are calculated from PM 2.5 readings.

Source: https://sensing.honeywell.com/honeywell-sensing-particulate-hpm-series-datasheet-32322550.pdf

So the PM2.5 is a proper read reading and PM10 is as we suspected simply derived/calculated from the PM2.5 value.

[gdt]

That's useful info. That shows that the PM10 output from the module is bogus, and it's still unclear to me where that second 14 bits comes from. But It's not pretty clear that it cannot be useful. The datasheet lacks a reference to a scientific paper that shows there is merit to the concept of estimating PM10 from PM2.5 :-(

[peterchs]

The other bits will just be passed back from the sensor.

[merbanan]

I added a comment in the code about this. Improvements are welcome. Closing issue for now.

[gdt]

I don't think we should be outputting data that we know is wrong. Would you be amenable to a PR that relabels PM10 to some sort of "unknown" label?

[peterchs]

Not sure 'unknown' would be appropriate, its known - as confirmed above to be a PM10 value calculated/derived from the PM2.5 value.

The PM10 value is what the honeywell sensor outputs, rtl433 is not calculating it. There must be some science behind honeywell's decision to derive it like it does. Its not necessarily wrong all the time. It may not be of value to us, but to someone a PM2.5 calculated PM10 value may be better than no PM10 value at all.

IMO leave as-is or say change the PM10 label to "PM10 (calculated)".

[zuckschwerdt]

A short note on these findings is now in the doc comment and we are planing to someday show those notes to users with some command. There is also https://triq.org/explorer/ -- but the fineoffset_WH0290_callback is hidden in the fineoffset_WH25_callback and the "comment extractor" can't pick that up currently. Needs work ;)

[gdt]

Trying to quickly look at the literature, the best I could come up with says that while there is correlation, it depends on a lot of things including regional dust type and seasons https://aqicn.org/experiments/south-korea-pm25-air-quality/ https://www.tandfonline.com/doi/abs/10.1080/10473289.2005.10464627

Also, how do we know that the recovered bits are from the honeywell module? Did someone take a WH0290 apart and extract them from the pins?

[zuckschwerdt]

I haven't been following closely. Does the PM10 value from the bits equal the reading from a head unit? Otherwise, could the two bit values be different time ranges /smoothings of just PM2.5? I've seen that in some A/D chips, not in radio protocols so far, though.

[merbanan]

Changing the name would break the api. I can only assume that the decoded values match the output on the receiver unit. If those values really correlate with some physical property is not really the job for rtl_433 to decide. It should just translate the rf signal as best as it can.

[gdt]

The value currently labeled PM10 by rtl_433 does not appear in any display that I know of. The device is documented to do PM2.5 only and as far as I understand the display shows just the PM2.5 value. (I have only a transmitter.)

If the value in the field matched something in a display, I wouldn't have brought this up.

[merbanan]

Well send a PR and I'll merge it then.

[merbanan]

For the record you where correct regarding no PM10 support.

[peterchs]

Not sure where the original understanding came from that the bits represented PM10, but to confirm I have just opened mine up and monitored the sensor tx/rx pins while it was being read using an FTDI adapter. Decoding the bytes using the datasheet, both the PM2.5 and PM10 values sniffed over serial tally with that received/decoded by rtl_433.

e.g. 42 4d 00 1c 00 00 00 08 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51
versus rtl_433/lab/devices/Fineoffset-WH0290/120/pm2_5_ug_m3 8 rtl_433/lab/devices/Fineoffset-WH0290/120/pm10_0_ug_m3 9

See page 5 of datasheet to decode the sensor serial output, but low values as above stand out anyway https://sensing.honeywell.com/honeywell-sensing-particulate-hpm-series-datasheet-32322550.pdf

On a related note I see there is new air quality sensor model which takes a similar form as this one. An indoor only, non solar, Ecowitt WH95 model which adds a number of new metrics, including probably a true PM10 as its uses a different sensor.. "Measures indoor PM2.5, PM10, CO2 concentration, Temperature and Humidity" https://www.ecowitt.com/shop/goodsDetail/97

[zuckschwerdt]

So it truly is the raw data from the sensor module, and it's labled "PM10" in the specs. But the module is faking that data (in maybe not a well suited way). Really a though choice if we should then suppress or alter the output?

[peterchs]

Yes. As I say maybe there is some scientific evidence that led Honeywell to decide to derive the PM10 from the PM2.5. Honeywell are in the business of manufacturing air quality sensors so they ought to know better than us? Of course if there's evidence that that calculation is totally wrong then it would make sense to suppress, but we do not have that. I'd say leave it as-is and up to whoever is using rtl_433 to interpret it as they see fit.

[gdt]

@peteakalad That's great you actually measured this. In my mind that changes things pretty massively, moving us from an unsubtantiated albeit plausible and now known to be correct guess to solid information.

I heard back from Ecowitt. The upshot is that the 2nd field is the PM10 reading from the sensor (matches @peteakalad measurement) and that it isn't accurate so therefore their products don't display it.

I'll spiff up the comments to explain this and submit a PR which should be uncontroversial.

There's a harder question still. I get the point that rtl_433 should just decode things and label them as the manufacturer labels them even if the sensor/etc. isn't high quality. But I also think we should avoid having the names mislead users into thinking there are extra measurements that aren't really there.

Here, we have a honeywell sensor inside which has and output labeled PM10 which isn't actually PM10, and that's IMHO a marketing decision rather than one based on solid science, and certainly not defined or footnoted in the data sheet. And Ecowitt is using that module to build a sensor, and they have declined to label that field PM10 because it doesn't actually contain PM10 data. So here I lean to respecting Ecowitt's labeling, and if it were just me, I'd just relabel PM10 to fake_PM10.

I can also totally see the point that we've spent way too long on this, so my approach is to put the new knowledge in the comments and be done with it.

[peterchs]

It’s speculative from both of us really whether the PM10 calculation is marketing or scientific led. But I do note the absence of any accuracy statement around the calculated PM10 on the datasheet which is suspect and may suggest it was marketing driven.

Agree re misleading labels. fake_PM10 works for me if it doesn’t break anything.

[zuckschwerdt]

Any renaming will potentially break stuff ;) But that's a good thing in this case, users might have the wrong assumption what that data is anyway. I think "fake" is too strong, maybe "est_pm10_0_ug_m3" or "pm10_0_est_ug_m3". If someone needs to ask what "est." means than that's no good though. Alternatives perhaps "approx", or "calc"?

[peterchs]

My vote is calc, “calc_pm10_0_ug_m3”

[merbanan]

That sounds good to me.

[gdt]

Rewrite of comments in https://github.com/merbanan/rtl_433/pull/1678

I don't like calc because it implies that PM10 can be calculated from PM2.5, and that's not true. This sensor is assuming levels of PM2.5-10 and to me their assumptions do not make sense. When my sensor sees elevated PM2.5 it's because of the neighbors burning wood in the fireplace (as detected by my NIST-traceable Mark V human nose), and I'd therefore expect a lot of PM2.5-10. It's totally up to @merbanan of course, but I vote for "alleged_pm10" which doesn't imply that it's valid, and doesn't say it's wrong - just saying that somebody else claimed it and declining to endorse it. I should have thought of it earlier.

[merbanan]

estimated_pm10_0_ug_m3?

[gdt]

That sounds fuzzy enough that I am not uncomfortable with it.

Let me know if you want a PR, vs you doing it.

[merbanan]

PR!!!

[peterchs]

Sounds good.

For anyone interested now or in future some insight into the honeywell HPMA115S0-XXX (in my case specifically a HPMA115S0-TIR) sensors calculations of PM10 taken from db where I've stored both PM2.5 & PM10 readings for some time:

PM2.5	PM10
0-24	PM2.5+1
25-106	PM2.5+2
109-185	PM2.5+3
190-220	PM2.5+4

Gaps between boundaries are as I havent received those values ever so rather than guess omitted them. Havent ever received higher than 220ug/m3 PM2.5.