Close
0%
0%

Climate & Environment Monitoring Station

Create a monitoring station to measure weather, soil, seismic, solar, magnetic, and gravity conditions - focus best accuracy/dollar w/COTS.

Similar projects worth following
Create a system with commonly available sensors and hardware in conjunction with good engineering to get the best accuracy reasonable. How will this be different from the thousands of very good DIY weather station projects? I grew up "pre-digital" so am a bit obsessed with true accuracy and not just resolution. This project will attempt to include an error band estimate for any measurements. The overall goal will be to have a "meteorological" quality station that is in reach for any hobbyist. A second goal is to have the fun of adding other data sensors for the environment as well.

(placeholder photo by US National Weather Service [Public domain], via Wikimedia Commons)

An old saying from my mother was, "In for a penny, in for a pound". Since I have gotten accustomed to Hackaday.io as a workflow blog, I decided to put up another of my ongoing projects. This one grew out of my frustration with the expense, inaccuracies, and closed approach of various personal "Weather Stations". I have owned several Davis versions and, most recently, a Peet Bros. unit.

Afer one repair of the Peet Bros. temperature/humidity sensor and later when the display system died the other day, I had my fill and started building my own as a replacement. This was about 18 months ago, so this is another in medias res project. (Note to my high school English teachers -- see, I was paying attention even though you didn't think I was)

That means you will need to overlook the scattered approach to the first few postings as they were a data dump of that happened up to 2016.

Sadly I did not have anything ready on this for Hurricane Harvey.  Even my new calibrated tipping bucket rain gauge failed.  The old school approach was the 18ft swimming pool at the bunkhouse.  It was empty on Friday Aug 22 and full to the 42 inch line on Tue Aug 26.  Oh well, I will have it ready for the next one.

  • 1 × ESP8266 Core MCU used for prototyping
  • 1 × DS1307 Real Time Clock (RTC)
  • 1 × SSD1306_128X32 OLED 128 by 32 dot OLED
  • 99 × Misc other components As project progresses the above list will be continuously expanded when decisions are made for each particular item

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

    sparks.ron10/11/2018 at 22:14 0 comments

      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

    sparks.ron10/01/2018 at 17:51 0 comments

    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

    sparks.ron09/30/2018 at 22:27 0 comments

    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)
    • 32x128 OLED display (local readings and menu)
    • 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

    sparks.ron02/21/2017 at 18:24 0 comments

    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

    sparks.ron02/07/2017 at 17:43 0 comments

    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

    sparks.ron01/05/2017 at 19:41 0 comments

    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?

    sparks.ron01/04/2017 at 20:01 0 comments

    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.

  • The Stevenson Screen

    sparks.ron12/12/2016 at 23:09 0 comments

    photo Kindly placed in the public domain by Cambridge Bay Weather

    The familiar box that houses various weather instruments has an interesting origin. The father of the famous author Robert Louis Stevenson (Dr. Jekyll and Mr. Hyde, Treasure Island, etc.) was a British civil engineer who specialized in lighthouse design. He realized that the lack of standardization of how weather data was measured and recorded was causing inaccurate results and incorrect analyses.

    He created a standard for the small double-louvered box with no floor in the middle 1860s. It was later modified to include the double roof and was ultimately adopted as the standard for the British Meteorological Society in 1884. Apparently there have been a number of regional variants including one for the "Cotton Region" of the US. I was surprised today to find that one of the regularly cited works for that is "The Effect of Thermometer Screen Design on the Observed Temperature", W.R. Sparks. It would be fun to find out if W. R. is a distant relative of mine.

    According to Wikipedia the traditional interior size for a single unit (like the photo) "may be" 76.5 by 105 by 59.3 centimetres (30.1 by 41.3 by 23.3 in). In my reading of other papers it appears that there is a huge variation on those dimensions. Obviously given my current location in the Texas Gulf Coast (which may include "cotton" region), I will attempt to track down the 1972 paper on screen design and other design comparisons.

    Because my budget does not allow me to buy a pre-made screen. I will be designing and building my own. I have learned a lot of "life lessons" regarding the design of outdoor equipment for use here in Texas and in most of the more than 3 dozen countries I have had the opportunity to work in. More on that to come.

  • What is my current status?

    sparks.ron12/12/2016 at 17:59 0 comments

      As I noted this project log is starting reasonably far into the actual project itself. If you want to see my approach and how I got to here, I will answer things in the discussion section but there is little sense in blogging it. On my Gamma Scintillation project I will be blogging a lot of the methods that got me to today on this project, so there is no need to repeat them here.

      This project got pushed into the "holding box" (a literal box) when my life situation changed this summer. The restart on this now will begin with an inventory of what is in that box and what has been prototype vs what needs to be done.

      In general I had the Arduino base unit working and talking successfully to a temperature/humidity sensor and tested that over a long-ish distance piece of Cat5e between the Arduino and the sensor. My reasoning was to ensure I could read data for both "inside" and "outside" the unit. Those terms are a bit arbitrary because the three application scenarios I have here are:

      1. Generic accuracy indoor/outdoor measurement for energy consumption analyses.
      2. High accuracy outdoor weather/climate station. In that case "inside" would be in the case holding the electronics and the "outside" would be the actual measurement being performed inside of a Stephenson Screen a couple of feet away. My plan is to house the electronics and such separately from the real measurement sensors to minimize any localized self-heating, etc.
      3. Flight ready balloon launch package. In this case "inside" is the interior of the payload and "outside" is the atmosphere around the payload/balloon. It is important on balloon flights that we minimize the change to the electronics inside the payload. We use repurposed Styrofoam chests to help moderate the temperature changes from launch, through flight, to recovery. Here in the Texas Gulf Coast it is not unusual for launch to occur at 90F (32C), pass through the stratosphere at -65C (-85F), increase at upper altitudes to -20C (-4F), and then reverse back through to 90F at landing. COTS hardware could not stand that if it weren't for some reduction in the swing along with the short-ish (± 5 hrs) time of exposure.

      I also remember having the barometric sensor working as well as the high accuracy temperature sensor. Where things stopped was just as I was beginning to put multiple sensors on the data bus simultaneously.

      I had done a bit of experimenting with the pulse output of anemometers and wind direction indicators. With that I began gathering scientific research on how to calculate an anemometer's relationship with true wind speed. My hardware prototyping was hindered by cable and connector issues with my existing anemometer setup, along with some very calm days that gave me zero output.

      At this point I will restart by getting out the project box and doing some photography of what bits I have.

View all 9 project logs

Enjoy this project?

Share

Discussions

sparks.ron wrote 09/09/2017 at 03:19 point

I am having second thoughts about not doing this on WiFi.  I will post to the log soon and explain my new approach.  In essence the ESP8266 is a game changer for WiFi coupled with Ethernet.  I now plan to do both and use an MQTT publish method for data transfer.

  Are you sure? yes | no

sparks.ron wrote 12/08/2016 at 20:57 point

That would be pretty straight forward as a "Phase 2" once the prototype is working well and ready for expansion before committing to a PCB.  The option that pops to mind is the Adafruit FONA 3G Cellular Breakout (#2696) at about $80 US and can include free service from Ting mobile (which works on the T-Mobile or Sprint networks).

The big issue would be whether there is 3G network coverage in the area where the system is setup.  That is not a problem around cities, but in the areas where realtime data is sparse, network coverage may not be available/reliable and the data logging to a flash drive or card would be critical.  That is why I have been focused on the logging aspect first.

Thanks for the great suggestion, I will definitely look into it further once the version 1.0 is up and running.

  Are you sure? yes | no

Winston wrote 12/08/2016 at 14:42 point

You can fill what I see as a gaping hole in economical remote weather station monitoring by having your station send its data via cell phone SMS. Every economical and DIY weather station product I've seen always requires data network access by either wifi or a more expensive cell phone data service.

  Are you sure? yes | no

sparks.ron wrote 09/10/2018 at 00:15 point

Your comment was well taken.  I decided to investigate the options for wireless.  When I did, I found that the problem of communication method was only one piece of a huge puzzle.  The protocol, the packaging method, the server, the client, local data storage, time tracking, battery consumption, and many other pieces.  For now it looks easier to go wireless than to do wired, so that is what I have decided to do. Thanks for the suggestion.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates