Reliable climate records can be hard to find for some areas, especially with the significant local variability you see in tropical locations. But it is important for understanding the hydrology of the caves so as I rebuilt the Pressure and R.H. loggers following the ECL05 epoxy failures, (I’m trying out some urethane this time round…) I thought a bit more about putting together a logging weather station. The temperature record from the “naked” drip counter we installed during the last deployment hit almost 60°C, which fried the SD card controller. This made it clear that any sensors on left on the surface need decent protection from the sun. A full Stevenson Screen is impractical to transport, and the smaller pre-made radiation shields seem unreasonably expensive for what they are (~$100 ea). Since I still don’t have a 3D printer to play with, I cobbled one together from dollar store serving plates and nylon standoffs which thread directly into each other; making it easy to add as many layers to the shield as you need. The trick is finding dishes made from flexible plastic like polyethylene that is easy to drill; polystyrene tends to be brittle and cracks when you try to make the large central hole. Even with a $6 can of spray paint thrown in, these shields only cost about $10 each, but I will try to find plates that are white to begin with for the next builds:
With temperature, pressure and relative humidity in hand the next task was to convert my cave drip counters into recording rain gauges. Earlier sensor calibrations had shown me that nozzle diameter was the key to consistent drip volumes, and I modified a funnel with some heat shrink tubing to yield a smaller 5mm tip. A large sewer pipe adapter provides a heavy stable base, offering the necessary sun protection and allowing me to add some inclination so the sensor sheds water from the impact surface.
A riser tube then holds the catchment funnel sufficiently far away that the drops gain some momentum and these funnels do a good job of converting fine misty rains into drops big enough to trigger the sensors. As usual, everything is held together with cable ties so that it can be disassembled for transport. I picked up an old school Stratus rain gauge to calibrate the loggers and set everything up in the back yard just in time to catch a few summer thunder storms. Ideally these gauges would be up off the ground, out in an open field, but my yard has few areas that are not directly covered by trees. I also noticed that high winds can sometimes shake the units enough to create false positives, so I now anchor the bases to cement blocks. Even with these sub-optimal factors, these loggers report within 10% of each other. Not USGS quality yet, but I am happy with them as prototypes. I will add a larger 8′ funnel later, to bring the loggers in line with NOAA standard rain gauges.
Wind is the next piece of the puzzle, and I still have to choose which way to go for that. Some brave souls DIY their anemometers with hard disk motors, mouse scroll wheel encoders, or salvaged optocouplers & roller blade bearings. But my gut feeling is that achieving linear-output is non-trivial exercise even if you can just print out the vanes. There are plenty of cheap “rotating egg cup” sensors to be had for as little as $20 and I would gladly pay that just to know the calibration constant (which you need to convert those rotations into actual wind speed). These cheap sensors are used in the Sparkfun kit and have simple reed switches. It should be easy to convert those switch closures to interrupts or to pulse counts, which my drip loggers could record provided I can debounce them well enough. I tried this approach before when I was evaluating shake switches for the early drip sensor prototypes. Although I rejected those sensors (because they kept vibrating for too long after each drip impact) they did work with essentially the same code that supports the accelerometer interrupts.
And there are other options: Modern Devices has a thermal loss sensor that looks interesting because it has no moving parts and is sensitive to very low wind speeds. A few of the more serious makers out there have built ultrasonic anemometers, which are some of the coolest Arduino projects I’ve ever seen. But even if I could do a build at that level I’m not sure it would be a good idea. As soon as something stops looking like a “cheap hunk of plastic” and starts to look like an actual scientific instrument (as those ultrasonics do) , it draws a bit too much attention for unsupervised locations.
Wind direction sensors often use reed switches & resistors, and that should be easy enough to sort out by reading voltages on an analog pin. The key would seem to be pin powering the resistor bridge only at read time (using a 2n7000 mosfet) so that you don’t have voltage dividers draining the battery all the time. For both wind sensors there will be some questions for me to sort out about averaging those readings in a meaningful way.
My first builds will have a separate logger dedicated to each sensor since the loggers are less than the cost of the sensors anyway. The wireless data transmission that most weather stations focus on is not as important to this project as battery operated redundancy. But I can see the utility of separate sensor nodes passing data to a central backup unit so that might spur me to play with some transceivers.
During outdoor tests some of the the small grey catchment funnels became plugged up with leaf litter. Since I needed a larger diameter catchment funnel to conform to the NOAA standards anyway, I found an 8 inch nylon brewing funnel on ebay that had an integrated strainer, and set up another comparison test in the back yard. I left the units running for almost two weeks and nature obliged with a few good rain storms to give me a decent data set.
Fences and trees surrounding my backyard mean that the location was likely to produce significant variability, and I saw almost 15% difference between the two loggers with the large funnels, with most of that showing up during the peak rainfall events which suffered the effects of wind going around the nearby trees. I standardized the drip tips to 6 mm with heat shrink tubing, but I will still have to do more indoor tests to determine if other factors, like accelerometer sensitivity, might also be contributing to this variability (and keeping in mind that it’s not unusual for consumer units to see >5% variability even under idea conditions). With the Stratus as my reference, the new loggers were seeing between 3-4 drips per ml of captured rainfall. That’s larger than the 0.25 ml drip volume asymptote listed by Collister & Mattey, which made me suspect the units were under reporting. Further tests revealed that the new filter screens are so hydrophobic that they suspended a significant volume of water, no doubt holding it there long enough to evaporate. Argh!
Our first real world deployment of the rain gauges gave us some excellent data from Rio Secreto.
Most people are familiar with concrete countertops, but I wanted to post a link to this coffee table build. The first thing I though when I saw it was: “That would make a really solid weather station platform…”
In the mean time we are making due with cement blocks; tucking pressure, temp & RH loggers inside the hollow channels. Over time I’ve been lowering the sensitivity of the accelerometer to reduce the spurious counts from wind noise, which has turned out to be the Achilles heel of this method for measuring rainfall. Dual deployments with trusted gauges is getting us closer to settings which will keep that under control. One of the cool things about these tests is that the loggers are running exactly the same code for both the accelerometer and for the traditional tipping bucket gauge: in both cases it’s simply an interrupt counter, with a longish sleep delay for de-bouncing. A lot of wind speed sensors use the same reed switch mechanism at the met. rain gauge, but a standard promini only has two hardware interrupts, so either I give each device its own logger (for high redundancy) or I dig into pin change interrupts to add more than one of these sensors to the same logger.
With internet access being non-existent in our fieldwork areas, it’s still not worth pursuing IOT level connectivity for our diy weather stations. However I am hoping that more libraries pop up for using an Arduino to intercept wireless transmissions from the plethora of cheap weather station sensor/transmitter combinations (like the inexpensive La Crosse series, the Oregon Scientifics, or the upscale Davis VantagePro stations) before I reach that point on my to-do list. At the same time it’s also becoming easier to create your own wireless system with RFM12b modules, or by hooking each sensor directly to an ESP8266, and then using a Moteino, or Anarduino as a central server node to receive the data and save it to an SD card.
And I’ve given up on plastic Stevens shields shown above. The local varmints used them as chew toys, busting the all the struts. There are some really cheap solar shields are now popping up for ~$10USD anyway. The nylon funnels have also been taking a beating under the tropical sun, so I am scouting around now for good aluminum or stainless funnels to replace them. The key there is to make sure they have good integrated screens made of metal so that they stand up to the U.V.
Just stumbled across this Humidity sensor shootout by kandersmith, along with a brilliant example of humidity sensor calibration work. The Bosch BME280 won easily as the most accurate. I also found this video about the TAHMO weather station, which is probably the sweetest sensor combination unit I’ve ever seen. And after seeing all that elegant work, I have to throw in a link to this perfboard monster over at the Louisville Hacker space; just to balance your weather station karma 🙂
IP68 2-way and 3-way junction boxes have recently fallen below $3 on ebay. My DIY waterproof connectors are more robust, but for quick connections to weather sensors, these cheap pre-made junctions might also do the trick.
Abstract: Existing methods for dynamic calibration of tipping-bucket rain gauges (TBRs) can be time consuming and labor intensive. A new automated dynamic calibration system has been developed to calibrate TBRs with minimal effort. The system consists of a programmable pump, datalogger, digital balance, and computer. Calibration is
performed in two steps: 1) pump calibration and 2) rain gauge calibration. Pump calibration ensures precise control of water flow rates delivered to the rain gauge funnel; rain gauge calibration ensures precise conversion of bucket tip times to actual rainfall rates. Calibration of the pump and one rain gauge for 10 selected pump rates typically requires about 8 h. Data files generated during rain gauge calibration are used to compute rainfall intensities and amounts from a record of bucket tip times collected in the field.
The system was tested using 5 types of commercial TBRs (15.2-, 20.3-, and 30.5-cm diameters; 0.1-, 0.2-, and 1.0-mm resolutions) and using 14 TBRs of a single type (20.3-cm diameter; 0.1-mm resolution). Ten pump rates ranging from 3 to 154 mL min21 were used to calibrate the TBRs and represented rainfall rates between 6 and 254 mm h21 depending on the rain gauge diameter. All pump calibration results were very linear with R2
values greater than 0.99. All rain gauges exhibited large nonlinear underestimation errors (between 5% and 29%) that decreased with increasing rain gauge resolution and increased with increasing rainfall rate, especially for rates greater than 50 mm h21 . Calibration curves of bucket tip time against the reciprocal of the true pump rate for all rain gauges also were linear with R2 values of 0.99. Calibration data for the 14 rain gauges of the same type were very similar, as indicated by slope values that were within 14% of each other and ranged from about 367 to 417 s mm h21. The developed system can calibrate TBRs efficiently, accurately, and virtually unattended and could be modified for use with other rain gauge designs.