[werk_ag]

You didn't mention the height above ground to mount the assembly, but () I believe it normally would be at about  "head height" (~1.5 metres), similar to the primary weather T/H sensors.  Of course sometimes a different height may be needed to keep away from "human influences",  or perhaps that's what some might want to measure (vehicle exhaust, etc.).

Hi Alan,

I also agree that (for obvious reasons) an Air Quality Sensor should be placed around the "head height". Mine is placed 2.0 meters above ground level.
I talked about put it away from "human influences",  exactly because some locations may suffer from an excessive of these influences, ex: a place where the people go to smoke, near a garage, etc, etc

Going a little Off Topic:  For my (urban) location, one of the advantages of the Weatherduino concept is that the Solar sensors can be mounted "up with the wind sensors" on a mast and / or "on the roof", sharing a Transmitter board.  So the only "missing" low-level meteorological measurement from the AQM is Rainfall (if there are no no leaf / soil wetness requirements).  Therefore, in the longer term, might it be possible to add a "Rain" input capability to the AQM, so that the present (low level) "Transmitter" board could be omitted (or moved up to "Wind/Solar" duties)?

Of course there are complications, for example in defining which are the "primary" and "extra" sensors.  Also, the Nano might be "sleeping" to save power, but the Rain signal is only a simple and infrequent pulse and there do appear to be spare Nano interrupt inputs.  The AQM sensor(s) might add some local heating to the enclosure, but then there is a "free" fan to give some Aspiration.

I think I understand what you mean, but wouldn't be preferable keep the AQM as a independent device? I think so. One possible problem I see, is combining the code of the AQM and the code of TX (even if only for the rain gauge) in the same Nano.
Only the array to allow having a 24h rolling average of the PM25 readings, with just a sample at each 15 minutes, takes around 20% of the 2K Nano memory (96 entries x 4 bytes, - each entry need to be long type).

Personally, I would like to support an "extra" Rain sensor, although I don't know how (or if) this might be "managed" with the Davis protocols.  A few years ago I purchased a Hydreon RG11 rain sensor, when it was being discussed on the Sandaysoft forum here and here.  Generally, its optical method is not as accurate as a tipping bucket in good conditions, but it is more sensitive, particularly faster in detecting the onset of rain.  It's also ideal for "difficult" and remote sites, being immune to falling leaves (blocking the funnel) and the notorious spiders of tipping bucket sensors.  Unlike most tipping buckets, it does need a small power supply (preferably 9 volts, but 5 volts can be used) which fits well with a the Weatherduino concept.

If the output of the Hydreon RG11 produces a pulse per each tip, I think you could use it with the WeatherDuino. The Rain Gauge connector on the TX board doesn't have the 5V or 9V available, but you can easily get any of these voltages from some points on the TX board, and wire it to one of the two unused pins of the Rain Gauge connector. Then its just a matter of defining in the software the rain value corresponding to each pulse. Hope I'm not saying anything wrong.