Our paper on the development and evaluation of a PPD42NS-based instrument is now publicly available via the AMT Discussion forum (Article [PDF]; Supplement [PDF]). It’s permanently citable in its existing form, though it will technically be in review until March 24. Hope you find the results to be of interest, dear reader.
Here’s a basic way to connect your Dylos to an Arduino. I’m sure it’s far from the most elegant solution, but hopefully someone will contribute an improvement.
Long hiatus on the blog, but it’s been a busy couple of months. I’ve been doing some rapid prototyping with the Shinyei PPD42NS, pictured above in an OtterBox enclosure with a battery, real-time clock, microSD datalogger, and temperature-humidity sensor. I’m thinking of calling it the Bento, what with all the tasty little sensors inside (and h/t to Lady Ada’s Bento). As you can see, I’m no mechanical engineer. But some folks over in Mech Eng at Berkeley are starting to work with us on enclosures. Nice!
The Roving Networks WiFly RN-XV is a nice little device. For $35 at SparkFun you get a low-power 802.11b module with a real-time clock, analog and GPIO pins, basic DNS and HTTP literacy. It’s a perfectly capable wireless sensor node, just by itself. It even has a nifty UART trigger mode, where incoming serial input will send a basic GET request to your favorite URL with the payload tacked on.
For field-testing purposes, I hacked together some plywood “backpacks”. Each has a small lip that hangs over a laptop screen, and with a few pieces of tape or velcro, it secures nicely to the back without much trouble. Duct tape over the surface helps velcro tabs adhere, so you can velcro on a GPS logger. And you can still screw components into the 1/4″ plywood. Makes it easy to rig up a laptop for a morning’s worth of sensing.
In the process I’ve learned at least two things that could help you getter better data out of your PPD42NS:
Tip #1: The Shinyei PPD42NS has a correct orientation (expressed as “UP” on page 2 of the spec sheet). There’s a resistor at the bottom to generate a thermal updraft to move air through the sensing chamber. In the build above, I drilled three round holes into a Radio Shack enclosure, such that they line up with the exhaust port on the basic Shinyei assembly. I cut out an elongated opening near the bottom to line up with the intake port, and Dremeled out most of the enclosure to make room (hence the two absent screws). In most air sampling devices the movement of air happens through the use of a fan or pump, but this is an elegant and quiet solution. It’s not power-efficient, and it’ll be interesting to see if there’s a better way to accomplish the same goal …
Tip #2: cover the large opening to the sensing chamber. There’s also a note buried in the Shinyei docs that says to do so. Why isn’t it sealed? So the lens can be cleaned after extended use. I settled for taping a piece of stiff paper over the triangular opening (you can see this in the gallery pics below). Seems like this probably changes both the ambient light that reaches the sensor, and the airflow pattern induced by the heating element. H/T to Ajay Pillarisetti.
If you have a tip to share, please leave it in the comments!
I’ve been inspired by the lovely results posted by Chris Nafis comparing output from a Shinyei PPD42NS to output from a Dylos DC1700. On Thursday I finished assembling this little charmer, a modestly sized Bluetooth-enabled PM counter. It’s made entirely from components you can get at SparkFun, Seeedstudio, and the like. The box at left houses the following, all sourced from SparkFun except for the Shinyei sensor (which is available from Seeedstudio).
- 6000 mAh LiPo battery
- LiPower 5V boost converter
- Arduino Pro Mini 5V
- Protoshield (for the power rails, basically)
- Bluetooth Mate
- Shinyei PPD42NS
It’s transmitting 60-second samples to the Macbook Air, which is in turn relaying the data to a Cosm feed, visible in the laptop screen at right. I slightly modified the Arduino code posted by Chris to (1) account for variability in the actual sample duration; and (2) output the “raw” signal as well as a a “filtered” signal (just some exponential filtering that’s a lot easier to make sense of when you’re staring at noisy numbers on a console).
When I left it running at my house this weekend, it lasted around 24 hours, which was pretty good, considering the PPD42NS is supposed to be drawing around 90 mA and the Arduino around 40 mA (don’t know about the Bluetooth Mate).
The data looks decent compared to readings from the Dylos DC1700, visible in the background, which I hooked up via USB/serial at the same time. I need to compare the two more critically, but just glancing at the shapes of the traces on the screen, it looks like they’re both picking up some of the same hourly variability. UPDATE: After running both in my office (not shown) for seven days, the 1-hour averages seem to line up nicely.
I’m giving the box to Edmund for some beta testing now that I’m back.