• ### Anemometer & Wind Direction circuit

It has been several decades since I did a complicated Karnaugh Map to lay out a digital circuit. Which means it took a lot of time and review to get the knowledge brought back to the front of my memory and skill stack.  Anyway, the concept for the circuit was deceptively simple.  The way the sensor works it it has two magnets and two reed switches. One sensor physically aligned with north for the wind speed rotor and one for the direction vane.  The number of counts per minute of the rotor vane is a representation of the wind speed.  The wind rotor also has a magnetic shield that extends up into the direction vane.  This means the direction switch will close once each revolution when the rotor aligns with the direction.  The time difference between the two closures is therefore the proportion of the circle between north and the direction vane. Clever and patented.

The beauty of this approach is the significant resolution improvement over more traditional multi-switch direction sensors or drag and friction in potentiometer sensors.  It allows the entire assembly to be completely sealed from the elements and corrosion.

The circuit to use the Peet style anemometer needs to respond quickly, since at high wind speeds and directions near to north, the time between pulses can be very short.  In order to get the resolution I wanted, it was too short for an Arduino. It would likely work on the faster MCUs like the ESP series.  However, that still would not resolve any variability in processing timing to count the time. So I decided on simple "jelly bean" digital logic as an inexpensive and reasonably stable timing platform.

I have attached my prototype circuit (done in Logisim-Evolution) and it will be the basis for the first breadboard circuit.  Once I have gone through the necessary datasheets and part selection I will include those parts in the list and do a Kicad schematic.

• ### Statistics math is full of jargon - but useful

It has taken me a lot longer to understand the accuracy specifications of the various sensors I need to compare and/or choose from.  A lot of this is because the manufacturers leave details out of the datasheet when they specify accuracy. For example is the ± 0.1 ºC an absolute accuracy, a standard error, or what? And if they bin their sensors to fall within that accuracy, what sample standard deviation is allowed, etc.

Thankfully Sensirion has that information available if you dig deep enough. It will not show up on a Google search or a search of their website.  However, I did finally find it in the certification part of the Quality Control section of their website.  From what I can understand, they use a 95% confidence error on a sample group to generate their specified tolerance.  Hooray for Sensirion! They are doing things right and I can now use their sensors with reasonable expectations of repeatability and proper accuracy estimates.

This all is a bit esoteric and unnecessary for a simple home weather station. But since this project is aiming for a station that has calculable uncertainties, it is quite important. For example, each of the various sensors (e.g., pressure, humidity, temperature, etc.) generally output temperature.  Each has a different error band though.  By having statistically calculable error bands, all of these temperatures can be statistically compiled with a specified confidence interval and that will improve the station readings dramatically.

All of that means better accuracy with a lower cost.

• ### U.S. National Oceanic and Atmospheric Administration (NOAA)

Just found out about the Citizen Weather Observation Program (CWOP) hosted by NOAA. The have a wealth of data that I am working my way through.  In particular the previous project logs show my concern with accuracy for wind speed and relative humidity. It turns out that those concerns were well placed as they are difficult things to accurately quantify.

From their information and other sources I have decided that I need to make this station in a way that allows aspirated temperature and humidity measurements.  My own experiments show that in the gulf coast U.S. (and other equatorial areas), humidity above 80% is common and becomes a real problem for nearly all "membrane" type electronic humidity sensors.  For that reason I am developing an aspiration method that will allow for three simultaneous sensors:

1. Electronic digital temperature & humidity sensor
2. Dry bulb digital temperature sensor
3. Wet bulb digital temperature sensor

Having a wet bulb system really adds to the complexity, but seems unavoidable if reliable low cost humidity measurements above 80% RH are needed.  On the other hand, the wet bulb system falls short of design goals for very dry (less than 15%) areas like deserts and for RH measurements below freezing.  My hope is that the membrane sensor will fill in those weaknesses.

My current plan is to use common PVC fittings for the aspiration system because I don't want to take the time to learn enough 3D software to model it for 3D printing.

• ### Anemometer input processing

Just finished concept review for the anemometer input.  As I noted, some form of input conditioning will be required (and maybe isolation?).  When I did the spreadsheet to look at the time intervals per rotation across the range of the instrument I found that a low clock speed counter is all that is required.  I also did an complex math curve fit to the calibration data from the manufacturer to allow me to look at the edge cases and what timing would be required.  What I found is that for this particular anemometer sensor the curve "bottoms out" at a smidgen above 1 mph.  But from my experience in the past I think that anything below 1.5 MPH (0.67 m/s) is unlikely to be useful.  Wear, bearing drag, dust/dirt, etc. all create a start-up drag that is unpredictable.

The sensor is also unlikely to realistically survive at much above 100 MPH, so I looked at that and 120 MPH (45-54 m/s).  When using a period counter for timing, this upper speed limits the resolution at the top end and the starting speed creates the maximum count required without roll-over.

By balancing these two factors it led to a clock speed choice of between 30-60 Hz and a 16 bit count.  This can be achieved with about \$5 of logic level integrated circuits (ICs).  I found a nice clock generator with an inbuilt divider that is programmable from 0-22 bit with an internal clock.  When I put that in my spreadsheet for the anemometer, it gave optimum results with a divider of 15.  That will output a clock of 31.9824 Hz leading to a count range of 59,921 to 625 across the desired range.

I plan to couple this with a Schmitt trigger and debounce input.  Then a parallel to I2C output finishes the process.  Also I selected a D-style latch that can be used to get the time count from the start of the rotation to the direction arrow pulse.  The time between these when compared to the time between speed pulses gives the wind direction (by multiplying that ratio times 360).

EDIT:

Oops, I just realized that the direction resolution will be dependent on the minimum number of clocks per revolution.  So I need to modify and re-validate my spreadsheet.

Once the wiring schematic is roughed out I will order the parts to breadboard it.

• ### Sensor information and status

I'm back on this project as a priority and making some headway.  I began prototyping MCUs and sensors a few weeks ago and have created the following test bed/prototype:

• ESP8266 MCU (will be the controller of the Remote Terminal Unit)
• Temperature/Humidity sensors (SHT11, DHT22 [AM2302], SHT35-DIS)
• Real Time Clock (RTC)
• AS3935 Lightning sensor

and I have an HX711 load cell sensor working. The load cell will be used for a subset of this project and used for bee hive monitoring.

All of the above components have been working together and I am now in the process of building a proper software framework for the final project code.  Things have now gotten complex enough that I have begun outgrowing the "quick and dirty" code in the Arduino IDE.  As a result I got an Eclipse instance working and installed the wonderful Sloeber plug-in.  My future code development will be there.

I also have started a github repository where I will put any code that is not fully embarrassing, as well as project documentation and spreadsheets.

Status - most recently I began real-world testing of the DHT22 sensor, thinking it would be a less costly option for the bee hives.  Sadly they fail fully in our weather.

Here in the Houston, Tx area we often have long periods of very high humidity. I have placed several DHT22s outdoors. They are under a roof so they are not subject to rain, any direct moisture and we are too far inland to have salt air.

Thus far all of them have begun giving false humidity readings after a day or two. Our typical day has been between 70% and 100% humidity with the temperature between 70F (21C) and 94F (34C).

[N.B., yes that is correct, our dewpoint has not been below 21C for the last 4 weeks or more]

In the failure mode the sensors continue to give humidity readings but the readings are about 15% RH too high.

It appears this is a saturation problem and basically renders them useless for anything except air conditioned spaces.  I have not tried to recover them or recalibrate them because I want a reliable sensor and will not be using these for the foreseeable future.

• ### Anemometer Calculations

I did a bit more thinking about the anemometer. The way the units I have (and have seen) work is by closing a reed switch with a magnet on the rotating cups. Both of them use the rotation speed to convert to wind speed. The interesting thing about wind speed versus rotation speed in an anemometer is that it is a "segmented" equation. In my mind I see it as analogous to a pump curve in fluid flow. What you see in both cases is a low flow regime where the inertia and friction forces dominate. In the middle region the movement is controlled by a "positive displacement" line. Then at the higher speeds you begin to see the effects of drag and edge spillage dominate.

The anemometer I am going to re-purpose is from Peet Bros., but the concepts and equations would be the same for my old Davis unit or even one that was DIY. Only the constants would change. For my anemometer the change from "slow" to "middle" happens about 8 MPH. The shift from "middle" to "high" happens at 135-ish MPH. However, at that speed the anemometer would have long since self-destructed. Therefore I am only going to look at the range from calm to 110 MPH.

When I do the math from the anemometer equations (which I will upload later in the project when I have cleaned up my ugly spreadsheet), I find that across the wind range of 1.5 MPH to 110 MPH, the output will vary between about 0.5 pulses per second (PPS) up to 145 PPS. That is too slow to easily measure as a frequency but will be easy to do as a period measurement which is then inverted in software to be a frequency.

The bottom of the range at 1.5 MPH is likely below the speed required for the wind to overcome the friction in the anemometer and start it turning. 0.5 seconds is 2000mS and on the upper end of 145 PPS, that would be about 7 mS. That is a very large range for a sensor, but not a problem for software. Using a non-blocking interrupt counter on the Arduino will likely be all that is needed, apart from input conditioning.

On the other hand, since the input will need some passives and a Schmitt trigger to condition the input, it would be very easy to add a gated counter and handle the counting at the input before "bothering the Arduino" with an interrupt. I need to look at the pros/cons of that. Any method used will need to gracefully handle a rollover condition in the counter for times when the wind is calm or too slow to turn the anemometer.

• ### Figuring out the GPIO needs

What I need now is an inventory of all the interfaces that my potential sensors would require. I took the list from the previous log and put it in a spreadsheet. Then I went through each datasheet and looked at the interfaces.

Here are the results if I were to put in every sensor:

 3 – Dallas one-wire type 6 – I2C 1 – SPI 3 – digital I/o (pulse, data/clk, etc) 1 – serial I/0 6 – analog (volts or current) 1 – AC resistance

From this I can now do a quick look to see what interfaces I need to augment for the Arduino style inputs. The Arduino A/D system does not have the accuracy or range this project needs so an outboard chip will be required. From the above I can see an 8 input multiplexed IC with an I2C interface would be a good choice. For example I will look further into the \$2 TI ADC128D818.

• ### Quick Thoughts

I did not elaborate on my direction with some of the more unusual sensors. Here are a few quick thoughts:

• The various photodetectors will be used to measure the illumination with a rough spectral breakout. In other words IR, R, G, B, and UV.
• Additionally a more traditional illumination measurement will be done that can correlate to the output of a fixed, tilted solar panel. In this regard I am thinking about using an IR thermopile to measure solar irradiance (W/m²)
• The Watermark sensors will be placed at a depth of about 1m (3ft) and 20cm (8 inches) to give a relative measurement of soil moisture in the tree root zone and grass root zone, respectively. The waterproof temperature sensors will be buried along with them for soil temperature measurements.
• Separate to this project I will follow with an evaporation pan system to allow estimations of leaf water loss. The current project should have an interface to allow other sensors like the evaporation system to "just plug in".
• The GPS module would be used to provide very accurate real times for data timestamping. It could also monitor any location deviations for inexpensive precision differential GPS. This would be a big help for things like bee hive siting, tree planting, fences, etc.
• Relative humidity and dewpoint are notoriously difficult to measure accurately. The reason for having two high accuracy temperature sensors is to allow the construction of a dry bulb-wet bulb arrangement. This will allow traditional methods to be used as well as the digital humidity sensors. I am curious to see what the comparative levels of accuracy are.
• The microphone output will be monitored for large peaks (like thunder) which could enhance the data from the lightning detector. It will also be used for very long term (hourly?) averaging to create a baseline background noise measurement. Subjectively I have noticed a large increase in noise as the city of Houston grows nearer us.
• I am still researching to determine if there is a very low cost leaf wetness sensor that can be incorporated into this system. Usual sensors are simple resistive or capacitive probes (printed circuit boards), but it seems to me that they would need continuous maintenance to remove dirt and dust.
• ### What sensors do I have?

I dug through my "junk box" to see what sensors I have acquired over the last couple of years. I anticipated building enhancements to the existing consumer weather stations, but found that closed software and proprietary protocols were not friendly to the process. As I mentioned that , plus the failure of my third consumer station (2 Davis & 1 Peet Bros.), motivated me to just build the complete thing.

Here is a list of what I found in my project box (-10 to 50 °C typical accuracies listed):

• 6ea - DS1620 digital temperature sensor, ± 2.0 °C
• 6ea - DS18B20 digital temperature sensor, ± 0.5 °C (2ea waterproof probes)
• 1 ea - HTU210F digital temperature + humidity sensor, ± 0.3 °C, ± 2%RH
• 4ea - SHT11 digital temperature + humidity sensor, ± 0.4 °C, ± 3%RH
• 2ea - MCP9808 digital temperature sensor, ± 0.25 °C
• 1ea - HM55B digital compass sensor, ± 9 μT
• 1ea - MPL3115A2 digital pressure sensor w/altimetry, ± 0.4 kPa
• 1ea - LSM303DLHC digital accelerometer + magnetometer, ± 60 mg, ± 1.3 μT
• 1ea - PR300A? (Fairchild 5154-20) selenium photocell, >10Meg dark, approx 500 ohm light
• 1ea - AS3935 Franklin Lightning Sensor, TBD, greater than noise floor (can set from 28-2000 μVrms)
• 3ea - RT100 platinum temperature sensor, ± 0.5 °C
• 1ea - CMA-4544PF-W microphone + MAX4466, combined calculated at ±3.5 dBV
• 4ea - various light sensors (more on these later)
• 2ea - Anemometers + wind direction, need rebuilding due to wear
• 2ea - Tipping bucket rain gauge sensors, 8 inch, 0.01 inch accuracy
• 3ea - Watermark soil moisture sensors, accuracy depends on soil - must be calibrated
• 2ea - Unknown type GPS modules, likely USGlobalsat with SiRF StarIII chipset

As I mentioned all of these were acquired over the last two years and ranged from a few cents at hamfests/swapmeets to about \$7-12 USD for those on breakout boards. Nearly all of the above (or their improved successors) are available from Adafruit.com currently. I highly recommend them as a source for any DIY sensors and/or breakout boards for prototyping.

One of the stated objectives of this project is to have high inherent accuracy to eliminate, or at least simplify, the calibration of the final station.

In the discussion a suggestion was made to make this unit wireless. That is a nice goal for "Phase 2", along with solar power. However, to keep things simple and prove the concept I will make the prototype and initial station as wired with PoE. That will allow it to run on a single Cat5e direct burial cable and will allow for actual power consumption evaluation in preparation for solar power.

My research on the Stevenson Screen also turned up several papers and in-depth measurement comparisons for natural measurements versus aspirated (fan driven) measurements. Surprisingly the aspirated "gold standard" was invented and has been in use since the late 1800's. A LOT of data is, therefore, available.

From all this, I am leaning toward having both types of sensors in the initial proof of concept system. My conclusion from the papers is the natural aspiration tends to be good at providing stable, consistent measurements where the aspirated ones are superior in measuring rapid changes and layering.