I did some more research on the subject. It seems that the PPD42 simply is the way to go. The GPY2Y1010 doesn’t seem very useful for this application. It’s does not necessarily always give wrong readings, but it’s considered unpredictable since the results are between reasonably good to almost random.
I also saw tests where the same was said about the PPD42. This is probably caused by the fact that it has two signal pins while an often used wiring only uses one of them. For setups using both channels very cool results were achieved.
What is particularly cool is that these also contain scientific references, dragging away the subject from pure ‘hey you guys with resistors and soldering irons, you’re just playing around and we don’t believe your results’. For this reason I would also not recommend the copied DSM501A. Even if it would perform similar it might raise questions you prefer to avoid.
Waag society also used this for their new experiment. The first smart citizens project primarily taught them how you shouldn’t do this and based on this experience they made a new attempt. It’s based on WiFi but they consider porting it to LoRa (anyone knows more about this?) http://waag.org/en/blog/making-sense-making-sensor. Also check the github link for more detailed docs. It also contains temperature/humidity and nitrogen sensors.
For that nitrogen sensor they used a more expensive sensor. I couldn’t find actual prices, but think about 50-100 euro because of calibration costs. Reasons I found so far to measure nitrogen is that it’s an easy proxy for dust. Interpreting this nitrogen sensor is also the reason you need the temperature/humidity because changes effect its effectiveness. But given that the nitrogen measurement makes it much more expensive than this cheap dust sensor I think when you’re on a budget it makes sense to drop both nitrogen and temp/humidity.
They base their concept on the dustduino.
… and this is what I’m currently porting to LoRa
I’ll add a lab post in the near future. An indoor version seems to work pretty nice.
Summary from all links mentioned above:
calibration is a subject that has not been addressed yet. But if you calibrate them yourself using a few identical sensors and compare them to each other your get reasonable results
do not try to make a low power device except if your find a way for ‘free’ air flow. If you don’t, expect somewhere in the range of 100-150mA power consumption
take the average of 1 hour readings as starting point. Everything shorter is too unreliable. With 1 hour it reaches acceptable accuracy.
I can’t recall where I read it, but while browsing I saw multiple reports that a relatively high number of sensors (perhaps 10% or so) of the individual sensors is simply unreliable. So order at least 3 to be able to compare them.
true, but the ppd42 seems useless to me
’ The Shinyei PPD42NS was one of the first sensors we evaluated’ and they have the equipment to calibrate… we don’t
According to your September 13th post it costs 1800 yuan which is 250 euro. The PPD42 is 10 euro or so.
Regarding the first part of your post: please have a look at the links in my post from this morning. I consider myself not qualified to make the choice. But given the results in those links by people who look better qualified to this the results seem acceptable to me. As long as you don’t expect real time result, and that’s exactly in line with that aircasting link. Just imagine an average in the graph they use to show the PPD42’s noise.
The ‘thing’ with AirBeam is, that they developped special firmware, in cooporation with the factory.
So you’ll never get the same results if you use the open source code…
I can source sensors from this company: https://www.nano-sense.com/en/P4000/p4000-fine-particles-probe.html
Performance on paper is comparable to the cheap Chinese sensors, but these sensors are actually tested and usable for professional purposes. Prices are below €200.
My tests with the PPD42 so far were just playing around with only one channel attached and measurements per minute. It looked reasonable yet it did show noise. Now I’ve attached the second channel and changed measurements to 5 minute average. And then I went cooking…
The first sensor of the maaspoort meet! project stayed in my living room/kitchen for a while. I can confirm that the effect is horrible at least considering the particle count. Opening my oven after I forgot to turn it off with a baguette half an hour in it was worse than new year’s eve…
not jet. I’ve still problems creating a schematic lacking components.
I’ll publish it on github when completed.
till then https://thingspeak.com/channels/227951
Since last weekend there is a solar/akku powered particle sensor with a loarawan/ttn data connection working on the luftdaten.info map. The hardware is a mix from the workshop from Frank (https://www.thethingsnetwork.org/labs/story/workshop-creating-a-ttn-node) and the original luftdaten.info sensor (http://luftdaten.info/feinstaubsensor-bauen/). The software is pretty primitiv as well, sleeping for 10 minutes, spinning up the fan, getting some readings, sending them and going to sleep again (cycle is around 12 minutes total). The data is then processed in Node-RED and transfered via the REST api to the map.
Fwiw perhaps our efforts to develop a cheap air quality monitor might be of interest, see http://ourairquality.org/ This design uses a NodeMCU/esp8266 Wifi board and the esp-open-rtos framework. It supports the Plantower PMSx003 family of sensors, and the BME280 and a few other temperature and humidity sensors. A dc3231 real-time-clock is supported as an option. Some features that might differentiate it are:
It records all the data from the PM sensor, more that one sample a second. This might help with quickly changing air quality, such as is common from close sources of pollution, and with mapping.
It compresses the data and can store a few days of data on the NodeMCU flash, a circular buffer. This allows it to work offline for a few days, or with intermittent Internet access without losing data.
The compressed data can be pushed to a server or pulled from the device.
It is designed to minimise data manipulation in the data logger and stores the complete raw data from the PM sensor including the crc, and logs data as a journal. This is an attempt to make it more credible on cross examination.
A wall mounted case is also described, folded from a single piece of fluted plastic. This is a attempt (perhaps misguided) to make a cheap case.
The server side software is not as well developed and still under development.
I also have this SDS011 sensor. I like to power it with a boost buck converter by the Lopy 5V supply (when only a lipo is attached) and switch it with an https://www.mouser.com/ds/2/115/2n7000-1163778.pdf that probably has the capabilities to handle the power consumption (up to 500mA). There is a power enable pin at the pytrack.
