reading calculation appears to be wrong

[Habbie]

https://github.com/Hypfer/esp8266-vindriktning-particle-sensor/blob/master/src/serialCommunication.ino#L2 says

serialRxBuf[3] * 256 ^ 3 + serialRxBuf[4] * 256 ^ 2 + serialRxBuf[5] * 256 ^ 1 + serialRxBuf[6];

which I believe is equivalent to

serialRxBuf[3] * 256 ^ (3 + serialRxBuf[4]) * 256 ^ (2 + serialRxBuf[5]) * 256 ^ (1 + serialRxBuf[6]);

The code is most certainly not multiplying [3] by '256 to the power of 3', etc.

I think the right code would be

serialRxBuf[5] * 256 + serialRxBuf[6];

based on page 7 of http://www.jdscompany.co.kr/download.asp?gubun=07&filename=PM1006_LED_PARTICLE_SENSOR_MODULE_SPECIFICATIONS.pdf

[Hypfer]

Ah yes I was somewhat suspecting that that could be wrong but did work anyways as during normal operation only the last byte actually contains data.

Adding [3] and [4] to the sum as well was taken from the datasheet of the PM2107 as I did only find a different datasheet for the PM1006K which used a different poll command than the one for the PM1006. By googling for "11 02 0b 01 e1", the PM2107 turned up.

Measurements would be absurdly high to exceed those two bytes though so it makes sense that they've dropped(?) that

[Habbie]

Yep - the wrong code effectively adds 2 to the measurement I think, which is not an error that stands out! I did also find the PM1006K - at least that explains why the string is so long for just 2 bytes of data :-)

[Habbie]

Commit looks good, thanks for the quick response!

[Hypfer]

I can't help but wonder what the other data fields might contain 🤔

I did plot DF9-DF12 for a while and got basically the same curve as the PM2.5 reading albeit offset by around 20 μg/m³ so I'd suspect that that's some kind of raw uncalibrated value or similar.

DF5-DF8 are mostly constant during my observations

[Habbie]

Yes, me too! I did not plot them but I do have this small collection of dumps

16 11 0b 00 00 00 17 00 00 06 9f 00 00 00 16 01 00 00 00 fb 

16 11 0b 00 00 00 19 00 00 06 a4 00 00 00 18 01 00 00 00 f2 

16 11 0b 00 00 00 18 00 00 06 a3 00 00 00 17 01 00 00 00 f5 

(I used these to implement checksumming, not for anything else).

The offset in these 3 readings is 1, not 20.

I also note that the PM1006K, which does have PM10 and PM1.0, still has a shorter string!

[Habbie]

Going even more off topic, you inspired me to do https://github.com/esphome/esphome/pull/2038, with credit to you in the comment there, and in the docs content at https://github.com/esphome/esphome-docs/pull/1315

[Hypfer]

This might also be interesting for @GSzabados #1

[GSzabados]

Thanks @Hypfer, and @Habbie that is awesome work. I haven't started to use EspHome yet, but that will make things far more easier.

[Hypfer]

If only ESPHome wasn't using yaml and this weird web thing :(

[GSzabados]

If only ESPHome wasn't using yaml and this weird web thing :(

Sure thing, but with a HA installation it makes things kinda plug and play.

[blakadder]

https://en.gassensor.com.cn/Product_files/Specifications/LED%20Particle%20Sensor%20PM1006K%20Specification.pdf

[Habbie]

The sensor in the IKEA VINDRIKTNING is the PM1006, not the PM1006K.