Info

I'm Greg and my experimental weather station.  The station is also listed in the NOAA MADIS  as D9310, on the Weather Underground as KWIAPPLE11, and in Citizen Weather Observer Program (CWOP) as DW9310

The station was brought on-line on Monday, November 7th, 2011.

Currently it reports temperature, barometric pressure, humidity and dew point, wind speed, wind direction and rain fall. The pyranometer is almost complete.

Want to contact Greg?  Use the email link at the very bottom of this page.

Stevenson Screen

The temperature/pressure and humidity sensors are contained inside a Stevenson screen. The inside of the screen is about 16" deep, wide and tall.  This is somewhat smaller than the standard size and is single-louvered (a single direction of louvers that go inside top to outside bottom).  Having it single-louvered is a decision that I regret and may later change.  Light can reflect up from the ground into the box.  That said, inside the screen, there's a secondary screen.  Surprisingly, using a plastic two liter plastic soda bottle with the bottom cut off works to add a secondary screen to the sensors.  The plastic is painted gloss white on the outside and flat black on the inside.  This secondary screen seems to add a level of thermal filtering to help keep daytime temperatures from spiking.

Temperature and Pressure

Temperature and pressure are measured using a Bosch BMP085.  This sensor provides a temperature compensated pressure reading through I2C communications.  The sensor comes calibrated from Bosch.  The BMP085 has had difficulties being in moisture.  As of May 6, 2012, the station is using a Texas Instruments TMP102 as its temperature sensor. The BMP085 has moved indoors and is used only for atmospheric pressure.  On May 4, 2012, outside moisture caused the original BMP085 to fail.

Humidity

Humidity is measured with a Hope RF HH10D.  The sensor provides an a square wave that varies based upon the relative humidity.  Calibration of the sensor is based upon correlations to near-by sensors. Dewpoint is calculated using the Magnus-Tetens formula and the based on the August–Roche–Magnus approximation.

Wind

The anemometer and wind vane are homemade. Both are loosely based upon a kit from Fascinating Electronics. The anemometer uses reed switches to count rotations.  It also uses Mainstays Ladles (UPC 7675333720) as the cups.  They are nylon with stainless handles.  I felt like I hit the jackpot when I found them.  The wind vane uses optical transceivers (SparkFun calls line sensor detectors) that measure the reflectivity of a disk painted with a pattern of glossy white paint and flat black paint.  The wind vane uses a five-bit single track gray code basically copied from a reference in the Wikipedia reference to on single-track gray codes.  The paint job for the 5-bit disk looks dreadful, but what's there is actually good enough based upon the data I've taken.  Go figure.  Current citing of both the anemometer and the wind vane are less than idea.  Improvements are planned in the spring.  The anemometer will need calibration.  Right now the calibration is, at best, loose and not particularly scientific.

 Both the anemometer and the wind vane use roller blade bearings for the rotating parts.  They are epoxied into the smaller diameter end caps.  Stainless hardware was used wherever possible.

The big issue this spring with moving the anemometer and wind vane off to the roof is lightning protection. It's a big deal, and I don't have an answer yet.

Rain Gauge

This weather station uses a tipping bucket rain gauge.  The gauge is from a WS-2310.  I believe the TX11U is the replacement part.  Each tip measures 0.0204 inches of rain. The rain gauge has some heating epoxied to the inside of the rain gauge to prevent snow and ice from freezing up the unit. Four Dale RH-10 2-ohm resistors powered by a 5-V wall transformer (from my old Palm T3).

Pyranometer

The pyranometer is based upon the PDB-C139 silicon photodiode from Advanced Photonix. A Linear Tech regulator creates a stable 3.3 volt supply on the board.  The supply both powers the A/D converter as well as provides the reference.  The TI 16-bit A/D reports back the voltage of the photodiode and resistor on the I2C bus.  Calibration is not yet complete, so the station isn't yet reporting information. It's also in a rotten stop until spring -- velcroed to the top of the Stevenson screen and shaded by the house until late morning.  The basic idea came from the Institute for Earth Science Research and Education's Pyranometer.  The schematic is attached below.  Calibration of this sensor is pretty ad hoc.  But on a clear day you can correlate measurements to expected data through models.  NREL has a reference to the paper.  The model the station used for calibration is a simple average of the USS, MLS and Dave Model 3 models.  The result is: P = 1125.21 * sin(a) + 14.10 * sin(2*a + pi) - 72.66, where a is the solar altitude in radians and P is the clear sky irradiation in W/m².

Data Collection

Data is collected with a Arduino Uno.  A python script on a nettop PC running Ubuntu communicates with the Arduino collecting telemetry and sending it periodically to the Weather Underground and to the CWOP.  While the APRS protocol is pretty comprehensive, the data collection system implements a simple subset of the protocol to push data to the APRSWXNET.  Here's a good page that gives the example I used.  A block diagram/schematic is an attachment at the bottom of this page.  The sketch for the Arduino is attached below.  The code isn't polished.  Don't consider it a reflection of best coding practices.

Data Quality

The station's data is monitored both within the Citizen Weather Observation Program as well as by NOAA MADIS.  The details of how things are going can be found on this page. 

Data Log Information

Internal to the python daemon that collects data, each log entry is a dictionary.  An example dictionary entry is shown here:


Below is a definition of what each key in the dictionary means. 

Key	Meaning	Example	Units / Data Type
barometer	The station barometer (referenced to sea level) in mmHg.  This value is a fixed offset (based upon altitude of the station) to PressurePa.	'30.257'	mmHg string, convertible into a %.3f float.
deltat	The time, in milliseconds in the last, roughly sampling interval.  This interval is used to calculate frequencies and rates based upon the actual time interval in a sampling interval.	'5383'	milliseconds string, convertible to an int.
dewpt	The dew point, in degrees Fahrenheit. A couple extra significant figures are kept around.  It is derived from relative humidity (rh) and temperature (t).	'3.977'	degrees Fahrenheit string, convertible into a %.3f float.
elapsed_counts	The number of rotations of the anemometer in the most recent sampling interval.	'15'	counts string, convertible into an int.
freq	Frequency of the humidity sensor.  The sensor produces a square wave with a frequency that varies with relative humidity.  Individual samples are filtered through an infinite impulse response filter. At the end of a reporting interval, freqf is copied into freq.	'7151'	Hertz string, convertible to an int.
freqf	This key is the accumulator for the filtered humidity sensor frequency samples (suffixed f for filtered).  Each sample is applied to this key as follows:  freqf = k * freq + (1-k) freq.  k is about 0.05.  It's probably unnecessary to expose this variable to the log, but it's here for now.  Extra precision is kept around to avoid quantization errors. At the end of a reporting interval, freqf is copied into freq.	'7150.91'	Hertz string, convertible into a %.2f float.
htick	The number of cycles of the humidity sensor signal, FOUT since the Arduino booted.  This is a 32 bit signed int and will wrap around..	'-806415274'	counts string, convertible to a signed 32-bit int, that wraps.
inst_wind_angle	In the last sampling interval, what was the wind angle.  This info is derived from the WV key.	' 48'	degrees string, convertible to a space padded, three-digit int.
PressurePa	The absolute pressure in pascals at the station. Individual pressure entries are filtered through an infinite impulse response filter.  This info is derived from ut and up (raw data read from the BMP085) and the BMP085 calibration table. At the end of a reporting interval, PressurePaf is copied into PressurePa.	'99728'	pascals string, convertible to an int.
PressurePaf	This key is the accumulator for the filtered absolute pressure (suffixed f for filtered).  Each sample is applied to this key as follows:  PressurePaf = k * PressurePa + (1-k) PressurePaf.  k is about 0.05.  It's probably unnecessary to expose this variable to the log, but it's here for now.  Extra precision is kept around to avoid quantization errors. At the end of a reporting interval, PressurePaf is copied into PressurePa.	'99727.58'	pascals string, convertible to a %.2f float.
pyra_mv	The raw pyranometer sensor signal, measured in millivolts.  This value is measured every sampling interval.  This is the most recent measurement.  The conversion to solar irradiation is through a calibration equation.	'69.44'	millivolts string, convertible to a float.
rain_count	This is an internal counter within the Arduino that keeps track of the number of times the rain gauge has tipped since the Arduino was reset.	'2'	counts string, convertible to an int.
rain_hr	The number of rain gauge tips in the last previous 60 minutes.	0	counts int
rain_today	The number of rain gauge tips since the start of the day (based upon local time).	0	counts int
rain_24hrs	The number of rain gauge tips in the last 24 hours.	0	counts int
rh	This is the relative humidity. It is based upon the info in freq and the relative humidity calibration data.  This is not represented in percent but rather in a number from 0 to 1.	'0.4453'	unitless string, convertible to a float.
ScriptRev	The RCS revision number of the python daemon, weather that manages data collection and reporting.	'1.53'	revision string
SoftwareRev	The RCS revision number of the Arduino sketch.	'1.24'	revision string
t	The raw temperature data from the TMP102.  This element is represented in hex.  The decimal point is four bits in.  For example: 11B is 17.6875 degrees Celsius.	'101'	fixed point Celsius fixed point represent of of temperature in Celsius.
TemperatureC	Before 2:05 PM May 6, 2012, this was the outside temperature in degrees Celsius.  After that time it is the basement temperature where the BMP085 lives.	'16.70'	degrees Fahrenheit string convertible to a %.2f float
TemperatureF	Before 2:05 PM May 6, 2012, this was the outside temperature in degrees Fahrenheit.  After that time it is the basement temperature where the BMP085 lives.	'62.06'	degrees Fahrenheit string convertible to a %.2f float
time	The time the reporting interval closed.  This represented as a string.  The formatting string to parse or output this time format is: "%a, %d %b %Y %H:%M:%S %Z".  This is local time and includes the time zone.	'Sat, 12 May 2012 10:20:03 CDT'	time string, convertible to various time structures.
up	The raw pressure into retrieved from the BMP085 in the last sampling interval.  Converting this to pressure requires ut and the BMP085's calibration constants.  See the BMP085 data sheet for details.	'9BA2'	16-bit hex number string, convertible to a 16-bit number.
ut	The raw pressure into retrieved from the BMP085 in the last sampling interval.  Converting this to pressure requires the BMP085's calibration constants.  See the BMP085 data sheet for details.	'696D'	16-bit hex number string, convertible to a 16-bit number.
wind_accum	A tuple containing an accumulation of the time (sum of deltats, in milliseconds) and the number of anemometer rotations (sum of elapsed_counts, in anemometer rotation counts) over the last reporting interval (five minutes).  This is used to calculate average wind speed over the reporting interval.	(301383, 465)	(milliseconds, counts) tuple
wind_angle	This tuple accumulates the wind vectors recorded in each sampling interval (taken from wind_inst_angle samples).  Together, they create the average wind direction over the reporting interval.	('39.528', '10.096', '56')	(cosines, sines, total counts) tuple, of a float, float and int (all as strings).
wind_dir	This is the average wind direction over the last reporting interval.  It is the information in wind_angle converted to an angle.	'14.3'	angle (in degrees) string, convertible to a float.
wind_freq	This is the number of rotations of the anemometer divided (elapsed_counts) by the sample time interval (deltat).  This value is calculated on the Arduino.	'2.79'	counts / second string, convertible to a %.2f float.
wind_freq_2	The average wind speed over recording interval.  This is a the counts divided by the time from wind_accum.	'1.543'	counts / second string, convertible to a %.3f float.
wind_freq_gust	This is the largest wind_freq measured in the recording interval.	'3.34'	counts / second string, convertible to a %.2f float.
wrf	This is wind rate fastest.  Within the last sampling interval, what is the shortest interval of time in which the anemometer rotated.	'271'	milliseconds string, convertible to an int.
wrff	This is wind rate fastest fastest (okay, silly name, I know) over the reporting interval.  This is the smallest recorded wrf over the sampling intervals within the recording interval.  It is the fastest rotation of the anemometer in the reporting interval.	'271'	milliseconds string, convertible to an int.
WV	Raw wind vane data.  The number of microseconds required for the five photo detectors to settle.  Time over 250 microseconds is considered a 1, under or equal to 250 microseconds is considered a 0.  This tuple is converted to an angle using a lookup table for the five-bit single track gray code.	'(8,2972,44,44,44)'	microseconds string, convertible into a tuple, 5 entries long of ints.

Log

May 14, 2012:  Microsemi has a good app note (Lightning Protection for Aircraft Electrical Power and Data Communications Systems) that seems like a good read for protecting circuits.  While the app note has an avionics slant, the parallels can be easily drawn.

May 13, 2012:  Starting to build the table of data log entry keys.  This will take a while.  Also did some analysis to compare the pyranometer sensor data to solar irradiation data from KWINEENA3 on last Thursday (May 10th).  That was a very clear day that makes the data comparable.  Where P is solar irradiance in W/m² and m is the measured pyranometer sensor in millivolts, the formula I got was P = 0.7405537 * m^1.270819.  R² = 0.9988 for the somewhat cherry-picked data.  I'm still not posting the data until the sensor is moved where it isn't shaded in the morning.  The difference between this calibration and the Bird clear sky model (the average of the USS, MLS and Dave Model 3 models) is very good -- within about 1 percent at 900 W/m².  The simplified model I'm using for clear sky irradiance is P = 1125.21 * sin(a) + 14.10 * sin(2*a + pi) - 72.66, where a is the solar altitude in radians and P is the clear sky irradiance in W/m².

May 12, 2012: The new humidity and temperature configurations are proving to work out.  Although the humidity sensor is not accurate at low humidity.  The last time I ran the correlation with CWOP was in February (see the log entry for February 12, 2012).  I took the last 28 days of data from here and reran the correlation study.  Then I got: rh = -(freq - 7741.5) / 1167.2.  Today I got: rh = -(freq - 7605.7) / 1021.1 (R²=0.926).  We'll have to watch this.  Is there a temperature component here?  Interesting.  In both cases, saturated humidity is within 10 hertz.  That seems really stable.  Updating the formula going forward.  The data above is wrong.  I failed to grab the most current data from the weather station log onto my laptop (minor).  The CWOP data is timestamped in UTC.  The station log is in local time.  The last time I ran the analysis we were standard time.  Now we're in daylight savings time.  Fixing those two things moved the correlation value from 0.926 to 0.955.  The corrected equation is:  rh = -(freq - 7613.1) / 1032.6 (R²=0.955).

May 6, 2012:  While the BMP085 is reading the correct temperature, the pressure measurements are now wrong.  Being read, but wrong.  As soon as the rain stops, I'm going to take the station down to move the sensor.  I have enough data comparing the TMP102 to the BMP085's temperature measurement to feel comfortable with the TMP102's temperature measurement.  It looks like the sensor stopped working reliably about 12:45 AM on Friday, May 4th.  The pressure is being read at the station at 28.83.  Yuck.  Short of the issues with the pressure sensor, the rest of the station weathered the two thunderstorms we had Thursday.  The station saw 0.43 inches of rain in five minutes on Friday morning!  Still anxious about lightning.  At 2:05 PM today, the station is back on-line with the TMP102 reporting temperature and a new BMP085 in the basement reporting pressure.

April 21, 2012:  I created a PVC Y-tube that can hold both of the anemometer and the wind vane.  This is one of the steps needed to get both up onto the roof.  This also got one more cable off the ground. I had reserved a pin on the wind vane connector for the anemometer.  Today I put it to use. 

April 14, 2012:  The TMP102 tracks the BMP085's temperature measurements.  I ran correlations between the two for data collected between April 9th and 8 PM tonight.  It is plus or minus 0.6 degrees Fahrenheit from the corrected BMP085 temperature.  At about 55 F, they agree.  At low temperatures, the corrected BMP reads higher than the TMP.  Above 55 F, the TMP reads higher than the BMP.  The linear slope is -0.0153 deg F / deg F (R² is 0.62).  I took the station down at about 8 PM to paint the TMP102 and the BMP085 with polyurethane to waterproof them.  The orifice on the BMP085 remains the only weakness on the BMP085 at this point.  Earlier today, I took the NWS Storm Spotter training.  Cool stuff.  With Arduino software version 1.24, I've added instantaneous peak wind speed detection.  The Arduino determines the fastest rotation of the anemometer and reports.  Version 1.48 of the python script accumulates those measurements over the 5 minute interval.  This is currently stored in a variable not reported to wunderground or MADIS.  I want to watch it and see if it works.  I also want to make sure I didn't create any goofy race conditions in the Arduino software. As a final comment for the day, I think that I need to take a look at the pyranometer data.  I'm wondering if even at 250 mV the diode is starting to become nonlinear.  Some more sophisticated calibration may be required.

April 9, 2012:  I added a TMP102 temperature sensor to the Stevenson Screen.  This is the first step in getting the BMP085 inside.  I am using the SparkFun Digital Temperature Sensor Breakout - TMP102 board but had to remove the SDA and SCL pull-up resistors on that board.  There's already enough of a pull-up on the bus.  Initially I tied ADD0 to ground but realized that this puts the TMP085 at the same I2C address as the pyranometer's A/D converter. Tying it to VCC breaks the conflict.  What do you figure the chances of that are?  Wow.  Got lucky I could break the conflict with the ADD0 pin.  I need to conformally coat it.  I think I'm going to use clear nail polish.

April 2, 2012:  The BMP085 is dead.  The Arduino wire.endTransmission() call is returning 2.  In the past, the reads simply didn't respond.  If I understand this correctly, the BMP085 is not answering.  I took the sensor out.  I see a bit of corrosion on the decoupling cap and on a couple of the BMP085's pads.  Moisture has gotten to it.  I got it running by wiping it with isopropol alcohol.  But, it's not going to last as I can see corrosion on the resistors on the breakout board.  In the next week, I need to move the BMP085 inside and put a separate sensor outside.

March 25, 2012:  Another seemingly moisture-related failure.  We had a good dew last night.  But the inside of the Stevenson screen was dry.  So, I'm confused.  As the last change short of moving the temperature sensor indoors and using another temperature sensor, I changed the cable running from the sensors indoors.  It's time to seriously consider where to permanently put the screen.  With the series of record high temperature days, the frost is now out of the ground.

March 24, 2012:  It rained yesterday and the station went down with the pressure transducer not talking.  To get things back on line, I brought the pressure/temperature sensor set inside, put it on top of a lamp to warm it up and, more importantly, dry it off.  I let it sit there for half an hour and put it back outside.  It works just fine now.  I think the pressure sensor needs to be inside and an alternate outside temperature sensor is going to be required.  I'm letting the sensors settle to ambient conditions before I put the station back on line.  I unplugged the rain sensor's heater. 

March 15, 2012:  The station suffered stopped reporting between 5:00 PM and 8:40 PM due to what I believe was an Ethernet cable problem.  One of my cables is probably in need of replacement.  I swapped it to a different, less necessary device.  Grr.  That's the first outage since January 23rd -- almost two months. Actually, I'm happy it appears to have been an Ethernet cabling issue, that's actually easier to solve.

March 5, 2012:  The snow over the weekend showed that the rain gauge does only an okay job of melting snow.  But, it should be a little more power to the power resistors, perhaps.  After the storm and the sun came out (as well as a little prodding by me), snow got to the bottom of the rain gauge and melted.  With the rain and the snow, the station hasn't failed on the I2C bus.

February 28, 2012:  Looking at lightning protection.  I'm not sure I have any good answers, but I did find this seemingly practical answer.  Last night I put RainX on the rain gauge.  I failed to mention that on the 26th (at 8:15 PM) I changed the temperature offset from -0.8C to -0.5C.  The -0.8C offset was put in place on January 23rd.

February 26, 2012:  Yesterday was sunny. the five degree tilt toward the sun. The pyranometer is tilted 5 degrees off normal toward the south -- it's velcroed to top of the Stevenson Screen.  After calculating for the tilt and using better numbers from today, a better sensitivity is 3.23 W/m²/mV.  After dark today, I installed a wedge to bring the pyranometer closer to level.  I suspect I'm within 1 degree of flat right now.  That's going to have to do for now.

February 23, 2012:  While it's now cloudy, the brief amount of open sun the pyranometer saw showed that it's linear to at least 600 W/m².  That's great news.  3.03 W/m²/mV seems looking close. 

February 22, 2012:  I took the pyranometer down and changed the photo-diode's load impedance.  It was about 909 ohms.  It is now measured at 324 ohms.  Data recorded after 22:18 local time is based on the lower resistance.  Looking at the data taken so far this week, it looked like the photodiode was starting to go outside its linear region at about 400 mV (400 W/m²).  Theoretical confirmation of the idea is backed up by a good paper from Hamamatsu.  It's also clear that the A/D converter is doing a very good job, so dropping the full scale output by a factor of 3 isn't scary.  Interesting that at 2:30 AM last night, the rain sensor tipped.  I would guess that it was probably close and either some condensation or the vibration from the wind caused it to literally go over the tipping point.  I bought some RainX to coat the inside of the rain gauge.  I also got a heat gun to allow me to attempt to bend up a plexiglass housing for the data collection computer.  There's a big mass of wires coming all wire tied onto a Workmate where the Arduino lives.  That needs to be cleaned up.  It's interesting that the epoxy I've used with two days yellowed up pretty well after exposure to the sunlight.  That was interesting.  The data showed that it yellowed but I'd never see in.

February 21, 2012:  The sensor sits on top of the Stevenson Screen.  It sees shade from a tree in the afternoon.  The house blocks morning sun.  Right now, the mission is to simply test the viability of the sensor.  Preliminary data shows the calibration is somewhere around 1.08 W / mV.  I am thinking of dropping the load impedance with the photo diode (after more carefully reading).  I'm also looking for a thermally stable resistor.

February 19, 2012:  The pyranometer is now outside and connected.  I'm not reporting data externally as I haven't calibrated it yet.

February 18, 2012:  Today I built the pyranometer circuit.  See above for the picture.  I was able to pretty well confirm that the rain gauge tips every 0.0204 inches of precipitation by looking at reports that the WS-2310 made back in 2006.

February 14, 2012:  I have underestimated rainfall by a factor of two as each tip of the rain gauge is 0.0204 inches -- not 0.01 inches.  See page 10 of the manual.  Still I think an experiment to confirm this is probably sensible.  The manual wasn't intended as a hacker's instruction guide, so it isn't clear.

February 12, 2012:  I have just about all the parts for my pyranometer.  I also redid the humidity correlation.  At 6 PM today, I changed the formula to rh = -(freq - 7741.5) /1167.2.  The coefficient of determination, R² was 0.950.  On Friday we got snow.  We weren't around to see it.  The rain gauge measured one count.  We got more snow than that, but it's a starting point.  When we came home, the rain gauge had no snow in it.  p.s.:  February 28, 2012, this calibration formula works well.

February 5, 2012:  Thinking about my homemade pyranometer.  Also, building a tee for the wind vane and the anemometer to sit on.  My current think is to build something like Institute for Earth Science Research and Education's Pyranometer with a TI 16-bit A/D sitting on the I2C bus reporting back info.

February 3, 2012:  On the 1st, I reset the barometer based upon quality data from MADIS to dial the correct calibration.  The sensor seems about 90 Pa higher than it theoretically ought to be.  As figured from here, at the station's altitude (234.1m) the offset from absolute pressure should be 2813 Pa.  Tonight I ran a regression between the HH10D's reported frequency and the analyzed humidity data from MADIS.  The new formula is: rh = -(freq - 7655.8) /1088.1. The coefficient of determination, R² was 0.902.  

January 30, 2012:  Added weatherproofed nylon around the pressure/temperature transducer with the hypotheses that the weatherproofed fabric will keep the station from getting screwed up when it gets damp outside.  It took a good 20 minutes for the sensors to get back to ambient temperature. 

January 29, 2012:  Added 4 Watts of heating power to the inside of the rain gauge.  The goal is to keep snow from clogging the rain gauge.  Is 4 W the right amount of power?  I guess we'll see.  I also have some nylon that I'm waterproofing to go over the BMP085.  But, I've ran out of time for today.

January 23, 2012:  At 5:45 AM this morning, the I2C bus hung.  But, not before the rain gauge (and its software) got a test.  That worked.  Before I left for work I checked the inside of the screen.  It was damp.  I think water is getting into the sensor.  Retrying all day, the system finally recovered around 3 PM -- just as the temperatures dropped to freezing (that seems no coincidence).  That in itself was nice to see.  But, why it failed still needs to be addressed.  But, this is an experimental station.  So, what do expect?  I am considering putting the pressure transducer inside and putting a temperature-only sensor in the Stevenson screen.

At 10 PM I updated the system to put a 0.8 degree Celsius offset into the temperature -- based upon CWOP quality data graphs.  This will drop both temperature and dew point by 0.8 C hopefully bringing data into a little closer alignment to nearby stations.

January 22, 2012:  Yesterday morning the Arduino microcontroller hung.  I suspect it was the I2C bus communications.  This morning I added timeouts to each of the spots where the code waits on the bus.  If it takes too long (and experiments showed that in normal operation it falls through the loop without waiting), a fatal error will be called.  For a fatal error, I wait a minute and restart the micro (I'm specifically not using the word reset).

Late in the day I installed the rain gauge from the long since broken beyond recovery WS-2310.  The only part that was salvageable from that weather station was the tipping-bucket rain gauge.  It's now a part of the system.  I wrote code tonight to bring that data on-line.  It's above freezing.  We're expecting rain tonight.  Just in time.

January 18, 2012:  Created a new secondary screen.  The new two liter soda bottle is both painted white on the outside and black on the inside.  Temperatures now seem to track better to other stations (with a sample size of one day).  Still, this is a significant difference as in the past the spread would go from half a degree at night to three degrees Fahrenheit during the mid-winter day.  How will the system hold up as the sun gets warmer, hotter and higher?  Time will tell.

January 17, 2012:  Quality control data is rolling in through MADIS and the state of the station is better than I expected.  Happiness.

January 15, 2012:  I installed the five-bit single-track gray code encoder wind vane.  But, I didn't move it.  In developing test code for the wind vane, I think I may have run into a stack overflow.  I'm now wondering if the issues with pressure getting messed up have anything to do with stack overflows.  I can't prove anything at this point.  I didn't mention it then, but on the 6th, I put the top of a 2-liter soda bottle, painted white, over the top of the temperature/pressure/humidity sensors.  The goal is to keep light, reflecting up from the ground and through the louvers, from hitting the sensor.  The other goal is to help keep blowing snow from getting onto the sensor.  That has reduced the temperature mid-day pressure spikes a little more.

January 11, 2012:   Yesterday the station showed up on the Weather Underground map (wundermap).  You have to zoom in as only KWIAPPLE3 will be seen at wider zoom levels.  The station today began sending data to MADIS.  Cool news.  The five-bit single track gray code encoder wind vane is built.  Over the weekend I hope to install it (and move the wind vane further from the house).  And, we're getting snow tomorrow.  Fantastic.

January 5, 2012:  Last night I wrote code to upload data to the CWOP through the APRS protocol.  This evening I linked the station to CWOP.  I'm a bit frustrated right now that the station still seems to be blacklisted at the Weather Underground.  Hopefully soon I'll be listed with them.

January 3, 2012:  The temperature got down to the -10.1 degrees Celsius and the problem with pressure calculations again showed up.  This time I had enough info to learn that there's something odd about the way the Arduino does the math to calculate pressure.  The python version of the code I ported gives different results than what's running on the Arduino.  The Arduino has has the discontinuity, and the python code does not.  Using the python results moving forward.  I'll investigate this later.

January 2, 2012: Yesterday I started publishing wind speed (based upon 4 mph / Hz estimates) and wind direction.  More than anything else, I'm looking to get runtime on the instruments.  Temperatures are suppose to dip to the single digits tonight. I have raw sensor information and a python implementation of the conversion code.  We'll see what happens when we cross below -10.1 degrees Celsius.

December 31, 2011:  Installed the wind vane but haven't connected it up to data collection.  See the picture.

December 29, 2011:  Early yesterday (12/28), the temperature briefly dropped below -10.1 degrees Celsius and again, like on December 9th and 10th, the pressure jumped.  I've updated the Arduino to send raw sensor data to allow me to do the math independent of what's going on in the embedded code.  Now we just need cold temperatures again.  I've been working on the wind vane.  A 2-bit sensor will be ready shortly.  I've done some bench top performance measurements.  I'll take some pictures and upload some data at some point. 

I will put the rain gauge out if I can find enough space in the PVC for wires.  I am using extra space in the two 3/4" PVC pipes used for phone and cable TV to route signals into the basement.  In the spring I'm going to need to drill a new hole for weather telemetry.  I'm barely going to have enough room for the wind vane cable.  And, the pyranometer is just going to have to wait (plus I haven't started working on that yet). 

We got some snow on the 23rd.  It's melted.  So, so far this winter, we've seen less than 2 inches of snow.  By this time last year, we'd seen feet of snow.

December 21, 2011:  On Monday night I was able to switch the station over from using data on the Serial over USB connection to the Ethernet connection.  I also created an Upstart service to allow the data collection script to respawn if it crashes as well as to restart on reboot.  In looking at the wind data, it appears that wind speed about 4 mph / Hz.  I'm not ready to post that to Weather Underground.  Working on the wind vane.  I'm fascinated by single-track gray codes.  There don't appear to be good ones that are 3- or 4-bit.  You get 2-bit or 5-bit.  Five ought to be good.  I'll build a prototype with 2-bits.  Thinking about using the "digital" optical detectors that SparkFun calls line sensor detectors.  I'm not sure I can measure time at the resolution required.  Again, need to experiment.  The one thing I am still a little curious about is the degree or degree and a half spike that I see when the sun comes out.  I'm wondering if, with louvers pointing down if reflections off the ground are hitting the temperature sensor.

December 18, 2011:  Once I slowed the I2C bus down to 32kHz, things have been stable.  I've added a picture of the anemometer.  I'm not reporting that data to the outside world yet as the location is horrible and the instrument isn't calibrated.  Over the weekend I moved the Arduino off the USB connection and onto an Ethernet connection.  Snow?  Snow?  Anyone, I want pictures of white stuff. Geesh.  Scope measurements of the system installed with actual field wiring showed a rise time on the I2C bus of 2 us.  I also saw a little bounce on the anemometer signal.  Software debouncing of that signal is required.

I also needed to hard-wire the SPI bus on the Ethernet.  My stack of of PCBs on the embedded system has the Uno on the bottom, the Sparkfun proto board in the middle and the Arduino Ethernet shield on the top.  The Ethernet shield relies on the ICSP signals to work.  Unfortunately, the Spark fun proto board doesn't provide the through-header to connect the Shield to the Uno.  Oddly, the Ethernet Shield doesn't connect the SPI signals on Digital 11, Digital 12 and Digital 13.  So, without the ICSP header, MISO, MOSI and SCK were unconnected between the Uno and the Ethernet Shield.  I installed some rework wires to connect the signals on the ICSP header to the appropriate Digital pins (11 - 13) and all is well (despite seeing the Packers wreck their string of wins as I was soldering on the rework).

December 15, 2011:  The BMP085 would not talk when I tried again this morning.  I think it's a lost cause.  I went outside and opened up the screen.  The inside is dry.  I didn't see an condensation on the sensors (despite the outside being covered in rain from last night).  The station will be down until I can get the replacement (early next week?).  Grr.  I haven't lost hope it will come back as it dries out today, but I'm not going to bet on it. If I can, I'll borrow an oscilloscope from work to do a little poking around on the board.  I also need to understand how much pull-up resistance the I2C signals to the BMP085 and the HH10D can support.  When I get the new BMP085, I may build a second sensor board -- given that I have a second HH10D and will have a second BMP085.

Update:  I brought home an oscilloscope from work and found that the rise time (even with the 4.7k in parallel with the 10k) of the SDA and SCL nets are between 1.6 and 1.8us.  It looked pretty ugly at 100 kHz.  So, I slowed the I2C clock down to 32 kHz.  That looked a lot cleaner.  I was able to get everything talking and back on-line.  Happiness for now.  The scope measurements were taken with the sensors sitting on the kitchen table (without long lengths of field wiring).  Tomorrow I'll put a scope on the system with the cable connected to the outside world.

December 14, 2011:  I ran into issues today.  The BMP085 is reading the calibration data but it's failing on the first byte of the first temperature read.  But, the humidity sensor is  working.  I am ordering a new part.  The one thing that correlates with December 4th is that it's been raining all day.  I haven't gotten out to see inside the screen.  But the humidity is 99 percent outside. Out of frustration, I unplugged the Arduino.  I'll try firing it up tomorrow morning.  Also noticing that the BMP085 breakout board has 4.7k SDA and SCL pull-ups. This was an evening of frustrating debugging.  I ordered a new BMP085.  It's either a) signal integrity on the bus, b) I damaged the BMP085 running it at 5 volts or c) condensing humidity.  A new part can rule out b).  The wind is supposed to pick up.  I may also replace the enet connector between the Arduino and the sensors.  The cable I used has some was old and does have a couple if nicks in the insulation.

December 13, 2011:  I modified the hardware to drive the BMP085 off 3.3 volts.  I disabled the Arduino's config to automatically pull up the I2C lines using a method of disabling the pull-ups within your sketch (rather than modifying the distributed Wire library) adding external 10k pull-ups to the 3.3 volt rail to both the SDA and SCL lines.  Hopefully this will fix what was seen on December 10th.

December 12, 2011:  I took the station down to install the anemometer.  It's uncalibrated, so I'm not going to post data to Weather Underground until I have better information.  Plus the anemometer is in a really bad position, so I'm not sure that even calibrated data is meaningful.  Better positioning will have to wait until the spring.  I'll post a picture soon.

December 10, 2011:  At 10:40 PM last night the pressure reading jumped by 345 Pa (100157 Pa to 100503 Pa absolute pressure, 30.40 to 30.49 inHg sea-level barometer) and then this morning at 8:50 in dropped back down 334 Pa (100662 Pa to 100288 Pa absolute pressure, 30.54 to 30.43 inHg sea-level barometer). The step-wise rise and the step-wise fall are almost exactly the same.  But, the rise and fall didn't occur at the same place nor did it happen at the same temperature (but close it both cases).  Three theories:  a) I'm wondering if the BMP085 doesn't like temperatures in the low teens and causes an issue or b) there's a bug in the Arduino code I got from Spark Fun.  c) The one thing I do notice is that I'm driving this part with 5 volts and not 3.3V.  This error aside, the accuracy of the sensor is stated down to -20 C and the sensor is operational to -40 C.

I'm working on the anemometer.  Nothing to show yet.  I'm basing mine off the kit from Fascinating Electronics.

Also, doing some research shows that the pressure sensor may be affected by light.  See section 5.8 of the BMP085 data sheet.  That might be impacting the temperature bounce when the sunlight comes around mid-morning.  On clear, cloudless days I'm still seeing noise in the temperature signal.

December 4, 2011:  Station down at 2:25 AM.  Looks like an interconnect issue on the I2C bus to the pressure sensor.  Arduino times out communicating to sensors.  Not sure what is going on.  A couple power cycles and some connector plugging and unplugging gets it to run for a couple of reading cycles.  Root cause not understood.  Brought the station back on between noon and 1 PM.  Not sure what happened.  But, it's working again.

November 27, 2011:  I took the station down for 2:30 and 5:30 PM to move the sensors to the new Stevenson screen.  It's too close to the house, but moving it will have to wait until spring when the cables can be buried.

November 8, 2011:  During the day (as of mid-November between 12:30 PM and 4:30 PM local time), solar radiation impacts that temperature readings.   While construction of the Stevenson screen is underway, the temperature sensor sits in a window sill exposed to the outside world.  When wind speed is low, the sensor is impacted by inside air temperature.