WXforum.net
Weather Station Hardware => Other Weather Station Hardware => Topic started by: JohnG on August 07, 2017, 10:42:27 PM
-
About two years ago I started thinking about weather stations. Just over a year ago I received a Raspberry Pi 2 and began collecting the bits needed. While it is easy enough to purchase off-the-shelf stations for reasonable (to me) money, but the time you collect, log and publish the data there can be serious money involved. Knowing that I could get mechanical sensors to measure Pressure, Temperature, Rain fall, Wind speed and Wind Direction; then take periodic photos to be published for cheap money, I decided to get serious about the electronics.
Understanding the I/O of a RPi was a *real* challenge. I began last fall trying to get my RPi to read the sensors I bought with mixed success. After spending two days reading and re-reading, I discovered that jumping from system purchase to installing a 3rd party software like WeeWx was fool-hearty at best - KISS is the rule!
Last weekend I made huge headway after stumbling on a WXF member's post about his WeeWx system, that pointed me not only to the code for the tipping bucket, but more importantly to a "How To" of GPIOs on the RPi. There have been a number of changes in the two odd years since I got my RPi, and jumping to the latest version of Python was a BIG MISTAKE. Now that I have an editor that I like (Geany) and understand that Python 2.x.x will work with my hardware and 3.anything will NOT, I have data!
My set-up looks something like:
RPi2 (Jessie, GPIO ZERO v1.4)
BME280 by Adafruit for Temperature (T), Barometric Pressure (P), Humidity (Rh) connected via I2C
HMC5883L by Adafruit for Wind Direction (WD), also connected via I2C
WS-1080-WC as the Anemometer (WS), connected to GPIO #12
WS-2080-RC for the tipping bucket Rain Gauge (RG) to GPIO #21
So far, I have the i2C stuff working using Python scripts that I found, some linked from WXF!. I do not have the final adjustments completed as the system is still in the early validation stages, but I can read both I2C sensors and see each bucket tip of the rain gauge.
I will try and attached a couple photos for reference.
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
The project for today was to figure out why the BME280 suddenly stopped working. Keen-eyed folks might notice in the photo above that I had connected the HMC5883L correctly to the I2C bus, but had the BME280 backwards. :oops:
I conclude this happened when I re-oriented the sensors to match the 40-pin GPIO on my board. #-o
Since I found that problem quickly, I decided to read thru the code for the temperature part of this sensor, because as others have pointed out, Temp reads high!
My discovery is that parameter (parm) for Temp is in SI units and a function of the converted raw digital output of adc_t then another function of an offset calculation. At the end of the day, since Pressure and Humidity *seem* to be very close to actual, I am assuming that only the final output for Temperature has the error (Atm and RH appear nominal).
The last line for the temperature calculation in *C reads "cTemp = (var1 + var2) / 5120", therefore if I manipulate the denominator "5120" to get Temp in *C to more closely match observed, I will correct the *F reading as well without affecting the RH or Atm calculations as they DO NOT use "cTemp" as a variable.
Overall, I am happy! \:D/
Now if I could just get than damned Anemometer to read and figure out how to count bucket tips. ](*,) ](*,) ](*,) ](*,) ](*,)
-
And look - in Python, too! :) https://pi.gate.ac.uk/posts/2014/01/25/raingauge/
-
=D>
When I saw the graphs, I knew I had seen them before! Thanks!
-
Photo of reading prior to the temperature function adjustments. Being off by ~4*F is a fairly large error, but unable to correlate except for normal indoor temps.
[ You are not allowed to view attachments ]
-
Did you feel like shouting, "Eureka! It's alive, it's alive!"
-
Did you feel like shouting, "Eureka! It's alive, it's alive!"
YES!!!!
It has been a good week for sure! Still running into seemingly innumerable roadblocks with the bucket tip counter and anemometer. I can see the tip, but counting them is a completely different matter ](*,)
-
\:D/
THIS GUY IS STOKED!
\:D/
I got ALL the I^2C sensors reading at the same time and then found a way to add CPU temperature to boot! Even managed to get the sensor outputs aligned for easier reading :)
Now to get that damned bucket tip counter working... ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,)
[ You are not allowed to view attachments ]
-
Now to get that damned bucket tip counter working... ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,)
Are you doing hardware or software debouncing on the input from the bucket?????
-
The BME280 datasheet says the temperature reading is likely to be above ambient?
...temperature value depends on the PCB temperature, sensor element self-heating and ambient temperature and is typically above ambient temperature.
-
Are you doing hardware or software debouncing on the input from the bucket?????
I have tried no debounce, software (0.01s - 1.0s) and even though I can see each individual tip, I cannot figure out how to count (accumulate) them. I have tried about 20 scripts for counting button presses, GPIO inputs, coin counters and either I get one tip counted for each debounce, or one tip with no accumulators.
This morning, the BME280 decided not to read again :( Syntax error line 33 for the I2C, but nothing changed since last night except a reboot.
Will hit it again after work.
-
Cannot believe it has been almost two weeks!
Update: I have done the ice-to-boiling water calibration test on my thermometers. Presuming I waited long enough, I get high readings at low temperature and low readings at high temperature. Typical ambient in this area ranges from 20*F to 110*F and within that range the differential is reasonably constant.
I also discovered that I^2C devices do not like long wire runs and that is why I was dropping signal on the BME280 at times. A couple pull-up resistors of the 470 ohm variety fixed that right quick. There is not a ton of mention about this foible, I just stumbled on it, seems to be treated as "common knowledge" within the Electrical Engineering ranks.
The rain counter is *sort-of* working. It will count bucket tips fine, but reporting them the way I want (every 5 minutes for example) is not working AT ALL. I can run the program and see when another 1/10" has fallen, so at least the hardware and software are ok.
I calibrated the bucket tipping to inches of rainfall using the following:
- running water *just* slow enough to be steady (we have constant "city" pressure)
- placed sensor in water stream and counted 100 bucket tips (100 in 32s)
- placed a cylinder in the water stream w/o making ANY adjustments
- ran for 30 seconds and measured depth of water
- determined the AREA of the cylinder, compared to the area of the rain sensor (Cyl = 5.94, Rain = 8.22)
- determined the "equivalent" rainfall had the areas been equal
>> Divided the water depth by number of bucket tips = 17 tips to the 0.203" ==> 83.7438 per inch
The highest rainfall rate ever recorded in this area is less than 6"/hr, or 502 tips per hour ~ 0.14 tips/second == 7.16s per tip. This is WELL within my ability to accurately measure w/o incurring hardware, software or other IO problems.
-
I whipped up a couple hand-drawn diagrams of the intended system.
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
I also performed some tipping bucket rain sensor tests. Three 8oz volumes were poured thru the sensor at various installation angles, all deviating from two-plane level by under 5*.
Suffice it to say, there is a large measurement error along the bucket axis and a much smaller one transversely. Some effort should be made to ensure the sensor is level, mine has a built-in bubble level and if the center of the sight glass is entirely within the bubble, your errors will be small, if not undetectable.
As the edge of the bubble gets closer to the red ring, the measurement error goes up quickly!
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
Late last night I finally found a way to get the anemometer to read!!!! The program I have should also help solve the counting problem I have with the rain gauge.
Once I have all the software reading correctly, I will start final design and construction of the station. I am still wondering if I should mount the RPi remotely, or as part of the station, suggestions and experience of member is welcome here!
Remote mounting
Advantages:
a) can use a battery back-up system
b) easier access (no ladders needed)
c) weatherproof enclosure not needed
Disadvantages:
a) less portable
b) longer wire runs to sensor array
c) cannot use on-device sensors
d) no "line-of-sight" for Wi-Fi
Station mounting
Advantages:
a) can use solar power, no need for line voltage
b) have line-of-sight for Wi-Fi connection
c) more portable
d) may be able to use on-device sensors
Disadvantages:
a) weather exposure, specifically moisture and temperature are big concern
b) more cost if solar powered
c) access would be by ladder only
d) all wiring would need to be made with UV tolerant and moisture tight connections
Time to get to work!
-
You can "plumb" all the wiring inside weather-proof PVC which can be cut, bent, and glued to just about any shape...just remember to install the "pull" string/wire before you glue everything up.
-
I never bother with a pull string pre-install. I just use a vacuum cleaner later to suck the string through.
-
I never bother with a pull string pre-install. I just use a vacuum cleaner later to suck the string through.
Didn't work for me on my 90-degree corners...I had to cut, thread an old guitar-string with string (twine) attached thru, then re-glue.
-
The trick is to start with light fishing line or heavy thread.
-
I never bother with a pull string pre-install. I just use a vacuum cleaner later to suck the string through.
One caveat... Any buried horizontal run of conduit, over time, may fill with water from condensation. I ruined a household vacuum cleaner that way. Best to use a wet/dry shop vac.
-
The trick is to start with light fishing line or heavy thread.
I've had good luck with mason's twine and a bit of rag or paper towel tied to the end to create something to get carried long by the air.
-
You can "plumb" all the wiring inside weather-proof PVC which can be cut, bent, and glued to just about any shape...just remember to install the "pull" string/wire before you glue everything up.
Well you promoted me to consider something I had not....
I have tele wire run from the house to the shop, where the actual station will be placed, it's 8 conductor twisted. Obviously there is no reason for that with the advent of cell phones ;) I am currently using a spool of same for testing on a rack in the yard, so I KNOW the I^2C stuff will work on it and I am getting wind speed just fine.
Since I have 8 wires to use, I could potentially wire as:
1) 3v3
2) Gnd
3&4) I^2C: Wind direction, Temp, RH, Pressure
SCL
SDA
With sensors connected to:
5) GPIO #21 = Rain
6) GPIO #18 = Wind
That would leave two left over and the RPi indoors!
Hmmmmm...........
-
A man with a plan!
-
The trick is to start with light fishing line or heavy thread.
I've had good luck with mason's twine and a bit of rag or paper towel tied to the end to create something to get carried long by the air.
Back in my BHP days we used a "Mouse".
Nothing more than little bit of rag tied to a bit of fishing line.
Then blew it thru the pipe with an air hose.
20m runs thru inch water pipe were common.
Only thing was that they did have a huge air supply;
100psi 1" air hoses in most places.
-
Today I got the WS sensor reading finally!!!! Also have the rain gauge actually measuring rainfall (no photos of that).
A few photos of the WS sensor installed on the weather vane, compass will be inside the vane as well, for direction.
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
I completed the magnetometer and RTC calibrations late yesterday. Really nothing to see with the RTC, but know that it is not an obvious process, at least for the device I chose (DS3231). It is really only four steps, but I spent maybe 10 times more time on it that should have taken, but at least it is complete.
As for the magnetometer calibration, that was more like a "three hour tour", but just as the weather (pun intended) started getting rough... PRESTO, I had the device reading more accurately and most importantly, with more repeatability than any smart-phone or traditional compass in the house.
[ You are not allowed to view attachments ]
-
Additional progress has been made. All sensors are now reporting, I divided the data into SI and US groupings as it was a little cluttered for my liking when grouped by data type.
I rediscovered "resistivity", it is resistance, but with a twist. The long-distance wire I was using to validate the anemometer function (100ft +) measures just 2.3 ohms over that distance, so 4.6 for the round-trip. Normally that is not going to create any issues, but when you are trying to measure pulses between 3.3v & 5.5v, there is not enough voltage or current left in the pulse to set the GPIO trigger. So the 22ga wire run is out and a 18ga wire in. Data is still not 100%, but at least it catches most pulses. Looks like if I want to keep RPi indoors, an AD converter that will broadcast the data over I^2C (I2C) may be needed.
Tasks for the holiday are: verify if the wiring to the shop is good, get the code to run on a timer and once those two are completed, try again to get the rainfall to total for a 24 hour period. Right now, the script hangs when it gets to rainfall, because that program runs continuously. There has *got* to be a simple solution, I just have not figured it out yet. I am trying to write the rainfall amount to a variable and pick up only the value of variable. But thus far, all I have been able to do is call the script each time the program runs.
Below is a photo of the current sensors, except for rain as we had none, as they display in a terminal session:
[ You are not allowed to view attachments ]
-
As can be seen from the screen-shot, I also was able to add "calculated dew point" to my outputs. This took some searching and math coding in the program, but was not too terrible. I learned long ago, that while RH is a useful measure, nothing will tell you more about the outdoor comfort level than Dew Point and temperature.
-
As can be seen from the screen-shot, I also was able to add "calculated dew point" to my outputs. This took some searching and math coding in the program, but was not too terrible. I learned long ago, that while RH is a useful measure, nothing will tell you more about the outdoor comfort level than Dew Point and temperature.
Don't "forget" the 'forgotten(*)' atmospheric measurement, Wet Bulb Temperature (Twb)! It comes in handy whenever anything is evaporating to dry.
(*) = To my knowledge, only MesoWest (UofUtah) calculates & displays Twb; neither NOAA nor NWS do.
-
I won't have enough data for Twb based on what NOAA suggests as inputs. It certainly does bring a more comprehensive representation of "total uncomfortableness" into the mix.
In other news, I will explain how I "calibrated" the Anemometer (aka Wind Speed Sensor).
I had code for the "Fine Offset" anemometer that I purchased, but it was in kph and had been tested with Python code to determine an accurate WS function. Knowing that the kph readings were more than accurate enough (much internet searching) based on the function used and design of the sensor, I set out to correlate kph to mph.
I know what the mathematical conversion is between kph and mph, but to validate I get the expected results is a little more complex.
The set-up included a two speed hair drier with the temperature set to off. I positioned the nozzle such that it would be directed at the cups of the anemometer and took 5 wind speed measurements using all three "programs": Original code in kph, my code in kph (then converted to mph) and my mph code. I did not change anything except which code ran, (it takes 6 seconds per run) and recorded the results. I then set the drier to "Hi" and conducted the testing again as backup, using only 5x2 though.
For statistical purposes, 5 data points were taken from each program:
WS (original) kph: 10.09, 9.85, 10.09, 10.09, 10.09 ~ 10.04 avg (~6.22mph)
WS_mphV2 mph : 9.73, 9.79, 9.73, 9.97, 9.73 ~ 9.8mph :-(
WS_mph_v6 mph : 9.76, 9.76, 9.76, 9.76, 9.76 = 9.76mph :-(
Seeing that both WS_mph programs returned essentially the same erroneous readings, I elected to do two things: 1) modify the calibration from the original WS = 1.18 as carried over to 0.765 and 2) perform the testing on only the "final" code version of the WS_mph_v6 program.
Results:
WS (original) kph: 17.3, 17.3, 17.06, 17.3, 17.3 ~ 17.26kph ~ 10.70mph
WS_mph_v6 mph : 10.71, 10.71, 10.71, 10.71, 10.71 = 10.71mph \:D/
So I am SET in my anemometer calibration with the verified original WS in kph matching my code to within 0.01mph in 10.
No, I do not believe that is the true accuracy of the device, but for winds < 20mph, it should be accurate enough and better than what most commercial weather stations can do for 5x the cost.