MADIS D9310 / Weather Underground KWIAPPLE11


I'm Greg, and this is my experimental weather station.  The station goes by several IDs: at NOAA MADIS it is D9310, on the Weather Underground it is KWIAPPLE11 (Town of Buchanan), in the Citizen Weather Observer Program (CWOP) it is DW9310 and on WeatherBug it is Town of Buchanan/Station P14803, on the National Weather Service Green Bay Office Public Information Statements as "2 W COMBINED LOCKS 767 FT)(APRSWXNET)".

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, rain fall, solar irradiance and sky temperature.

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.  The screen does not have a blower to circulate air.  Generally
speaking, it hasn't been needed.  There is a little bit of a correlation between changes in solar irradiance and temperature changes, but doesn't that make sense?  The sun shines and the temperature rises. The roof above the box is tilted somewhat (to the south).  This both reflects sunlight (acting as a heat shield) and allows precipitation to roll off the top of the screen.

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 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.  Calibration of the sensor, for both the first and second sensor was not readable from the sensor's EEPROM.  Instead of using the EEPROM factory calibration, I correlated humidity analysis data from the CWOP quality data.  The first sensor lasted until mid-September 2012.  The second one is currently being used.


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 wi
th stainless handles.  I felt like I hit the jackpot when I found them.  Hardware is stainless where ever possible.  The vane on the wind vane is ordinary window plexiglass painted flat black.  Counterweights on the vane attempt to keep the rotating assembly somewhat balanced.  The main rotating shafts for both the anemometer and the wind vane fits through a roller blade bearing epoxied into holes drilled the smaller, base end cap.  As of July 2012, the anemometer has spun 17 million rotations (32 million rotations by mid-January 2013 and 108 million rotations by mid-January 2015).  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.  It's important that exposed circuits be coated to waterproof things.  In November, I cleaned things and painted everything with urethane.  The sensor is good to at least 53 mph.

Current citing of both the anemometer and the wind vane are okay -- certainly better than the first year of operation.  The anemometer will need calibration. Right now the calibration is, at best, loose and not particularly scientific. The plan for calibrating it involves a car, a day with calm winds, different Arduino looking only at the anemometer, and driving country roads up and back both north/south and east/west.  Generally, the wind speed has a good match to the CWOP quality measurements.  The station reports slightly higher wind gusts -- as the station measures the time of each revolution of the anemometer determining the gusts by the fastest revolution (rather than the some timed window). 

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.

Ideally, this sensor should be 11 m above the ground.  Right now it is not.  I'm either going to mount it on the roof of the house (using a gable end mount) or on a pole. As a practical matter, the data received now matches pretty well to my the station's peers, so I'm not super worried about this.

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).


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/m2.  To get solar irradiation data from the pyranometer, use the following equation.  Where P is solar irradiance in W/m2 and m is the measured pyranometer sensor in millivolts, P = 0.7405537 * m1.270819.  See the May 13, 2012 log entry for discussion.

Sky Temperature

The sky thermometer data is not reported to the outside world.  The sensor is basically a Melexis MLX90614ESF-BCF-000-TU.  They are available at Digikey.  The -BCF- part is a 10 degree field of view part.  The trick is that it has a barrel. A cover over the top of it is required for outside use.  But, finding a window that's transparent to long-wave infra red (5.5um to 14um wavelength) is very difficult.  Polyethylene plastic is recommended.  I tried four materials: a sandwich bag, two liter soda container material, a freezer bag and plastic wrap.  In the end, the best option seems to be Plastic Wrap.  I took data to figure out a correction.   Pictures and info to follow. A calculation of the impact of having a piece of Surefine Plastic Wrap over the sensor indicates that Terr = -0.0876 (Ta - Tobj) + 0.785.  From Tobjerr = m(Tobj - Ta) + b and Tobjraw = Tobj + Tobjerr we get Tobj = (Tobjraw - b - mTa) / (1 + m).  So, for plastic wrap, m = -0.0876 and b = +0.785.  Measuring Sky Temperature as of Wed, 26 Dec 2012 18:10:02 CST.  The question is whether plastic wrap will be durable.  I'm collecting Appleton METAR data to see what correlation can be made between surface temperature, sky temperatures, dew point and sky conditions.

To talk between the IR sensor and the Arduino, the station uses Peter Fleury's I2C library.  See Sensor Junkie's 14 Feb 2010 comments to explain how to integrate the I2C library into the Arduino libraries (create a i2clib directory and put the cpp file and the header file in the directory) and to get sample code.  It worked wonderfully in nominal conditions out of the box.  But, I've modified it to add timeouts to prevent I2C bus communication errors from hanging the Arduino.  A good tutorial can be found here.

With the current configuration, the sensor does hang up once every several hours.  I've designed the software on the server to hangup and retry.  With that robustness, the system as whole rides through the bus hangs. Plastic wrap seems to last on the order of six months to a year and then it rips.

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.  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.

The Arduino code is not Arduino 1.0 compatible.  Porting the code to the API isn't a big deal.  But, I believe that under the Arduino 1.0 implementation, this implementation runs out of stack space on an Arduino Uno.  It crashes almost immediately.  See the log entry on June 8, 2012.

The pressure transducer, temperature sensor, and pyranometer communicate to the Arduino over I2C.  The wind vane uses five digital inputs.  The anemometer and rain gauge pulse digital inputs.  The humidity sensor is a square wave with a frequency proportionate to relative humidity.

Data Reporting

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. Attached to this page is, a python script used to upload data to APRSWXNET.  If you decide to borrow this code, don't forget to modify the station ID before you start using it.  APRSWXNET has no authentication.  If you use the code without modifying the station ID, you'll overwrite this station's data.  The input to the key function module is a log entry.  See below for the definition of that data.  There's other code in this python module that can otherwise be ignored.

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.  Separately, MesoWest measure's the station's quality 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:

{'deltat': '5383', 'rain_count': '2', 'inst_wind_angle': ' 48', 'dewpt': '3.977', 'WV': '(8,2972,44,44,44)', 'PressurePa': '99728', 'wind_freq': '2.79', 'wrf': '271', 'wind_accum': (301383, 465), 'wind_angle': ('39.528', '10.096', '56'), 'PressurePaf': '99727.58', 'wind_freq_gust': '3.34', 'rain_hr': 0, 'rain_today': 0, 'wind_freq_2': '1.543', 'rh': '0.4453', 'ScriptRev': '1.53', 'wrff': '271', 'barometer': '30.257', 'elapsed_counts': '15', 'pyra_mv': '69.44', 'rain_24hrs': 0, 'freq': '7151', 'SoftwareRev': '1.24', 'wind_dir': '14.3', 'TemperatureF': '62.06', 'htick': '-806415274', 'TemperatureC': '16.70', 'ut': '696D', 'up': '9BA2', 't': '101', 'time': 'Sat, 12 May 2012 10:20:03 CDT', 'freqf': '7150.91', 'tobj': '17.48', 'ta': '25.05', 'tobjraw': '18.93'}

See the Dictionary Meaning section at the bottom of the page for details.


24 Nov 2016:  The humidity sensor is up to no good.   It's measuring very low frequencies.  I'm wondering if it got wet - if the urethane coating has a weakness.  Either that or the frequency output is not crossing through Vil/Vih on the input to the micro.  Some investigation is needed. 
7 Nov 2016:  The weather station celebrates its five-year anniversary today.  I never thought that would happen.  The weather data log is now 402,954,013 bytes long.  The anemometer has rotated 167,792,767 times.  The system has recorded 523,096 log entries.

1 Oct 2016:  Lots of long overdue repairs.  1. I put a new Teflon diffusion shield on the pyranometer.  I had taken it down and covered it with Wal-Mart bags to keep it from getting any wetter.  Using some JB KwikWeld I bought at Menard's (UPC 43425 08276) I cut a new shield from the 6" x 6" piece of raw material I bought in the original construction.  I expected when I disassembled the pyranometer to find a lot of corrosion with the expectation that water would have gotten into it.  I was wrong.  It looked okay.  All it needed was a new shield.  I used a fair amount of epoxy to make sure it was held well that the edges had a good fillet off epoxy leaving now exposed slide edge of the Teflon.  The old Teflon was tan.  This is dark gray.  I think I'll need to do some new calibration here.  2. Earlier this week one of the cups fell came loose and fell off the anemometer.  Despite being outside for almost five years, the cups look fine.  The nylon material is amazing.  It just doesn't degrade.  I lubed the bearings with 30 weight oil and put the cup back on.  I had to find grab a new nut.  The old one was hopelessly lost in the lawn.  3. The cooking wrap on the sky thermometer got brittle and broke.  I cleaned the sensor and put some new wrap over the top of it.  I do need to build a new top to the Stevenson screen.  That will wait for another day.  I should also run a cal on the humidity sensor.  4:26 PM.  I ran a humidity calibration using data for the last 28 days. rh = -(freq - 7680.6) / 986.9. R^2 = 0.879.

10 Jun 2016:  I suspect on 13 February the teflon diffusion shield came off the pyranometer.  Today, I noticed it came loose from its bracket.  I suspect that happened on Monday.  When I went to tied it down (before the storm about to come through, I noticed that the teflon diffusion shield was missing.  The internals of the electronics probably will need some work.  Fascinating.  I also think the bearings on the anemometer are in need of lubrication and/or replacement.  That needs to be investigated.

28 Feb 2016:  I am very interested in the work that Institute for Earth Science Research and Education is doing with inexpensive air particulate measurements.  See here.  I'm also disappointed that it seems to be taking a long time for the Blitzortung guys to complete the new design of their lightning detector. My suspicion regarding the pyranometer issue is that something's up with the load resistors.  When the weather gets a little better, I'll take the sensor down and investigate. 
13 Feb 2016:
  I am suspicious that the pyranometer is going out to lunch.  Even after resets, the returned data is high.  It's too cold to go outside and mess with it right now.  But, Thursday's clear day at almost 900 W*m^-2 is totally bogus. 

2 Feb 2016:  Looks like the pyranometer prescaler faulted yesterday.  Solar voltage measurements for yesterday should be divided by 2 to get a proper measurement.  After dark, I reset the Arduino to have the A/D on the pryanometer get its proper analog scaling back.  A "giant" snow storm is expected today.  The forecast slow degrades to a normal February snowfall with a chance for rain.  Yet, all the schools have canceled.  Thinking about how the dewpoint sensor works, I'm wondering if it needs to be re-engineered to have a voltage regulator on the sensor (rather than relying on regulation on the Arduino).

22 Nov 2015: Humidity and peak wind gust issues seen today.  Added the pull-up mentioned on 15 November 2014 back into the circuit.  The frequency of the humidity sensor went to near zero.  That made the humidity read high and messed with the stations ability to measure wind speed.  There were a bunch of spurious high wind gusts.  I have to wonder if the output level of the 555 timer is a bit temperature dependent.  Today was also the first day we had temps in the teens.  So D2 now has a 4.7 k pull-up to the 5V rail.  Bad stuff started to be seen at about 3 AM this morning.  Pull-up added back at about 1:15 PM.

8 Nov 2015: Yesterday was the fourth birthday of the station.  After a week of nearly record high temperatures, fall weather has returned to northeast Wisconsin. When spring comes everything needs to be cleaned, the Stevenson screen needs painting and the "roof" needs to be replaced (the plywood is bowing).  Short of that, things are okay.

7 Sep 2015:
  Yesterday, based upon weather stations nearby, we received between 1.40 and 1.46 inches of rain.  The station registered none.  This afternoon I put the station in testing mode, went out the back yard, and dumped a cycling water bottle into the rain gauge.  No tips.  I opened up the gauge and what did I find?  A spider had taken up residence.  It's web had enough strength to keep the tipper from moving.  I cleared out the spider and its web.  I put the gauge back together and tested it.  Success.  It's now back online with a working rain gauge as of about 2:45 PM local time.

23 Aug 2015:  The kitchen wrap the goes over the sky thermometer broke a week or so ago and I replaced it.  I think that happened last Monday (the 17th).  I need to re-calibrate the humidity sensor.  I think there's a temperature dependence within the calibration.  Other than those concerns, the station has been quietly humming along.

13 Jun 2015:  Just checking in.  Had a handful of Arduino resets in May.  Beyond that, really nothing to report.  The initial calibration for the humidity sensor was a bit off.  This spring I reran the numbers a couple of times.  It's reasonable now.  When I initially buried the PVC conduit in the ground last summer, I probably didn't cover it with enough dirt.  Need to lay a little more potting soil over the trench.  Beyond that, not much new.  The weather.log has 375,593 entries across 1,316 days.  It's total size is 284,723,320 bytes.

6 Feb 2015:
  The new humidity sensor seems to be working well.  The data quality measurements have returned to two thumbs up.  I've found the lightning detection network, blitzortung, seems pretty interesting.  Right now they are not selling kits, so you can add yourself to the network.  It sounds like they are redesigning the electronics.  Yesterday RadioShack filed for bankruptcy.  As a teenager I went to the RadioShack in the Janesville Mall.  Sad.

11 Jan 2015: I built a new humidity transducer.  The old one wasn't working.  Installed it this afternoon while watching the end of the Packer game.  Sorry, Cowboys, we win!  Probably brought the station on-line too early as the temperature hadn't settled.  It did not hit 33 F today.  Bought parts from RadioShack. I kind of expect that it will be the last time I buy from RadioShack ever.  By the time I have another project, I expect them to be bankrupt and closed.  Sad.  Conformally coated the sensor with four coats of Minwax.
  Noticed the voltage sensitivity of the 555 circuit.  In the lab, at 1.1 volts (VDD) fout was 6300 Hz.  At 1.6 V, 7300 Hz. At 5 V, 7600 Hz.  At 7.2 V, 7700 Hz.  I left the old sensor outside because it has an I2C EEPROM that the Arduino reads (but ignores the data read) at boot time.  Given that I'd need to install a VM to do the build, I'm not going to mess with getting rid of that code.

9 Dec 2014:  The humidity transducer works fine below freezing.  As soon as the temperature gets close to freezing or above, the frequency of the transducer goes up.  Something is still wrong. 

26 Nov 2014:  Bought a new RJ45 connector to replace the one in the screen that had the bent pin.  Used isopropyl alcohol to clean up the humidity sensor circuit board.  Coated the board with a coating of polyurethane.  I no longer need the pullup discussed on 15 Nov.  The other theory is that the 555 timer (at that lower voltage) might be at the lower limits of it's supply spec.  A quick read of a the TI datasheet shows a minimum Vcc of 4.5 V.  Even on a good day, it's 3.3.  But that's worked for years, so I'm not super concerned.  I do wonder if Vcc at 2.5 V might have been pushing things a touch.  I did not see any corrosion on the board.  Anyway, I'm going to let it settle before I try re-calibrating.  In the mean time, I'll listen to the Rolling Stones.  

24 Nov 2014:
Over the weekend, the temperatures came above freezing and it's been rainy and wet.  The frequency of the humidity sensor is rising. As of 9:30 this morning, it's at 8 kHz -- which pins the humidity at completely dry (which is SO not true).  My working theory is that leakage current is getting around the resistors in the 555 circuit.  If I had to guess, I would suspect that the conformal coating on the board has failed.  I'll need to bring the sensor inside, dry it well, clean it up, coat it again, put it outside, and wait and see.  Moisture is one of this station's nemeses.

15 Nov 2014:  This was fun.  Spent some time debugging the humidity transducer.  Took the sensor to work and looked at it on the bench.  It worked great.  Brought it home and it still read 80 Hz.  I took a look at the fout signal (Arduino D2) inside.  The waveform was going from 0 to 2.5 volts.  The 2.5 volts violates V_IH for the Atmel micro (the datasheet indicates V_IH for VCCs between 2.5 and 5.5 volts should be as follows:  V_IH_min = 0.6*Vcc = 3.0V and V_IH_max = Vcc + 0.5 V = 5.5 V). 
Knowing that the humidity sensor has an output impedance of 1 kohm, I pulled up D2 with a 4.7 kohm resistor to the 5 volt rail.  This is a total hack but it shouldn't harm the 555 on the sensor nor the micro.  But that moves the square wave to low at 0.9 V and high at 3.6V -- which is fine. I also noted that the pin on the female RJ45 connector at the Stevenson Screen had a bent pin on Pin 2.  I bent it back.  It feels like that connector ought to be replaced, but that's for another time.  I should review whether I can run the temp sensor and the humidity sensor on five volts.  The wind gusts since yesterday are totally bogus (and should be ignored). 

14 Nov 2014:
  I bought some new sensors for the humidity transducer.  In replacing them, I'm now measuring about 80 Hz for the humidity.  I swapped out the old sensor with a new one.  The new one measured nothing.  I took that out and put the original in.  It went back to ~7200 Hz.  I put the new on in, I got 80 some Hz.  I cut the leads short, I still got 80 Hz.  I put in a second new sensor.  I got ~80 Hz.  I put the original part in.  Now it reads 80 Hz.  This implies that it's something other than the humidity sensor.  Given this is a 555 astable oscillator, it could be a handful of other things.  I think I need to take it into the lab and look at it on a bench.  So, for now, wind speed and rain sensing might be a little off.  Humidity will be VERY off.  Such is life.

7  Nov 2014: 
Happy 3rd birthday, KWIAPPLE11!  I have a new humidity sensor.  I'm planning on installing it later this weekend!

25 Oct 2014: The humidity sensor frequency is now going up.  It was stable after a reseated connectors back in late September.  The humdity/dewpoint data begins to deviate from what makes sense on Thursday morning.  My concern is that I can no longer find a replacement sensor.  And, the challenge is that this sensor is both needed for measuring humidity as well as for providing a polling clock to lots of other things.  If it stabilizes, I can at least attempt to recalibrate while I find some other plan.  It looks like Futurelec is about the only place that sells this sensor.  Their reputation doesn't seem so hot.  Doing a little more research, it looks like one can replace the sensor part on the HH10D with Measurement Specialities P/N HPP801A031 (available at Dig-Key).  I'll probably buy a couple for safe keeping.  The lifetime of these sensors seems like about 18 months. The reference circuit Measurement Specialities has in their datasheet is essentially the same circuit that Hope RF used.

28 Sept 2014:
  Humidity went to zero frequency.  This is bad.  The clock for the humidity is also used to sample the rain gauge and the anemometer.  So, if it goes to zero, we won't detect wind or rain.  The hardwired end of C1 at the Arduino looked good.  I reseated the ethernet cable both downstairs and outside.  That seems to have fixed things.  In fairness, I'm not sure which cable end had issues.  When I did both and restarted, I had a proper clock being measured on fout.

31 Aug 2014:  
Built a small shelf that I've screwed the the concrete basement wall.  This moves the station electronics away from sitting in front of the electrical panel (where it's been since 2011).  Now I we can upgrade our cable without worrying that technicians will accidentally break something.  And, it's now move up to code.  You just shouldn't have stuff in front of the electrical panels.  In the process, I did break a wire on connector 1 that I needed to repair.  Done. All's back to normal.

Independence Day 2014:  Over the last couple week's I've been working on burying 1" PVC to contain cables going to the outdoor instruments.  This afternoon I finished the task and switched the wiring over to the new cables that are buried.  This brings the anemometer back online!  Damn rabbits.  They won't beat me again.  And, I got the sky thermometer back on-line.  The inside of the box was wonderful.  No corrosion.  The electrical tape sealed the cable entry very well.  ...The rabbits had completely eaten through the sky thermometer cable.  In total, I think I spent 8 to 10 hours out messing with things.  I plan on ordering the Franklin Lightning Detector I2C breakout board from TAUTIC on Tindie.

June 15, 2014:  Took anemometer down.  Held wire in place with Wal-mart bag handle tied off and over a cap.  Used DMM to confirm that anemometer on female RJ connector goes to 0.5 ohms when rotated to point where reed switch closes.  Some corrosion on yellow in of female connector.  Scrub with alcohol and pencil eraser.  Put an RJ11 cable on the connector.  Works.  It doesn't appear to be the instrument or the connector.  Didn't take the instrument apart.  Put it back on the pole.  Looked at the connector on near the wind vane.  Solid.  Dead.  Cabling or the Arduino.  Time to buy PVC...

June 11, 2014: Tuesday morning the anemometer started acting up.  It showed a number of really high gust values and then the Arduino stopped receiving any data from the sensor.  It seems like more than a coincidence that this was a little more than a day after I was fiddling with the wind vane.  Given that and the fact that the anemometer cable goes through the wind vane's cable harness, that's the first place I'm going to start the investigation.

June 8, 2014: 
Wind vane repair day.  Is the wind vane broken or is the cabling broken?  Downloaded Arduino IDE (on new laptop), put Mstimer2 in libraries directory, added library. Took down weather station, removed bottom bolt on pole, unhooked wind vane, put onto spare Arduino, use optical_prox_test sketch, plug in wind vane to arduino per weather station schematic (using breakout RJ5: GRN=+5, BLU=ground, BLU/WHT=D5, GRN/WHT=D6, BRN=D7, BRN/WHT=D8, ORA/WHT=D9).  Test 1s and 0s (stuck bits) on instrument.  Direct measurement shows msb bit 2 (sketch pin b, D6 is always reading high).  It's not a cabling thing, it's an instrument thing.  Mechanically, its sticking. Shaft has moved off center - easy to fix. Disassemble.  Galvanic corrosion on 2 of the 5 bits...  WV_A and WV_B are both (using the 250 cutoff threshold) stuck at 1.  Picture made.  Label top of wind vane base with bits names with Sharpie by manually verifying.  Will cleaning with alcohol work?  Scrub.  Scrub some more.  Check again.  They all work.  Much more polyurethane this time (make sure the urethane doesn't get on the optical parts.  Line on encoder disk says "N" - what that really means is that it should point toward the direction of the vane (front not tail).  N on inside of base should go toward North. Of course, the wiring does need attention.

May 24, 2014:  On May 11th, it looks like bit 1 (numbering 0 to 4) on the wind vane is stuck high.  I think it may be related to the fact that the rabbits started eating the exposed wring outside.  This happened over the winter.  The rabbits were so hungry that they were willing to try plastic.  Better cable management is needed.  Wind direction between then and now is wrong.  The answer to the problem is going to take a little time.  I need to bury the cables in PVC.  That means digging up with I have.

January 6, 2014:  The phrase of the day is Polar Vortex.  Coldest temperatures we've seen since 1996.  The thoughtful man is humbled by the reliable supply of natural gas today.  The system is running reliably.  I'll probably need to clean up the wiring to the Arduino as I suspect we'll be upgrading our Internet service in the next couple weeks.  I'm a bit fearful that the very act of fussing with the wires will break something.  The station quietly celebrated two years of operation in November.

October 31, 2013:
  Good low pressure system coming through.  The barometer is at 29.21 inHg / 989 mbar.  LOW.

August 23, 2013:
  Upgrade the Ubuntu server to 12.04 LTS. Evidence suggests that the house probably took 70 to 90 mph wind on the 7th.  A EF1 tornado went through the area.  It bounced up and down put probably wasn't far from our house (although it was not touched down here).  

August 7, 2013:  It's 1:20 AM.  A pretty good line of thunderstorms just passed through Appleton.  The station probably saw the largest wind speeds that it's ever seen.  The house shook as it went through.   The station, our router, our wireless network and/or our DSL modem bounced up and down as the lightning on the leading edge came through.  Unfortunately, the station didn't get good data between 12:40 AM and about 1:15 AM as various pieces of the infrastructure were up and down.  I'm sure the winds exceeded 50 mph.  Improvements need to be made!

July 5, 2013: 
On June 29th or 30th, the anemometer stopped working.  This morning I went and took it apart to see what was going on.  The main bolt loosened up from the bearing.  While I had it apart, I notice the bearings were dry.  I put some Phil Wood's Waterproof Grease in the races.  Oddly, the anemometer had started working sometime overnight.  I didn't realize that until after I was running tests to confirm things were working.  The dry bearings weren't a good thing, so I'm happy I got out there.  The last time I had it apart was last September.  The bearings being dry left some rust particles on the bottom side of the roller skate bearing.  I also reset the arduino on Monday night as the pryanometer had a prescaler issue again.

May 16, 2013:
  Yesterday at around 11 AM local time, the prescaler inside the pyranometer spontaneously changed causing the A/D values for the pyranometer to be half what they should be.  I thought perhaps a bird had pooped on the sensor aperture, but it was instead an electronics thing.  At 8:15 I rebooted the Arduino to restore normalcy. While I was at it, I unplugged the rain gauge heater.  The styrofoam insulation fell off and blew away a couple weeks ago. Thinking some more about the lightning detector.  I still need to deal with EMC protection and the occasional dropout of the sky thermometer.  

April 10, 2013:
  Last night we had over an inch of rain that ended with fall temperatures.  The rain iced on everything.  The wind vane froze for the day pointed ENE.  The anemometer had ices that centrifugal force pointed away from the instruments center axis.

March 10, 2013: 
The station hung up for the first time since November.  I caught it right away as I saw the email when it came it.  It was raining.  It's windy.  It's at freezing.  The back yard is a pond.  I'm honestly surprised anything electronic can work in that environment.  Hopefully this isn't a repeating issue.

March 3, 2013: Hit normal amount of snow for the winter.  The sun is getting higher in the sky each day.  Spring will be here soon.  As for the weather station, not much to report.  The sky thermometer does get covered with snow following snow storms.  Uncovering that has been the majority of the maintenance this winter.  I need to get a rain gauge that can better measure the snow (by melting it).  I also still need to consider lightning / electrical fast transient / surge with the summer coming.  I dodged that issue in November when I moved things.

January 27, 2013: Mid-week I had the first meaningful debounce problem with the anemometer.  The instrument measured a single 167 mph wind gust.  Obviously that's not real.  I deleted it from the Weather Underground data set.  This evening we had thunder snow!

January 20, 2013:  Last night an arctic cold front came through with some pretty strong winds.  Having moved the anemometer in November, it can see the wind better.  So, last night's pair of 53 mph wind gust is the strongest it's seen so far.

13, 2013:  The sky thermometer resets about every four hours due to either a CRC error or a failure to initiate communications.  The system is fault tolerant enough that everything starts back up and keeps going.  I should add that level of error recover to the main arduino.  On Friday it rained.  The rain sensor barrel got wet as water wicked up the plastic.  Yesterday I removed the plastic, let things dry out and put a bigger piece of plastic over the sensor.  Everything seems normal again.

January 1, 2013:
  We almost went below zero last night but not quite.  I've spent a couple days updating the i2c library used to communicate with the IR thermometer.  The key need was to add timeouts.  I'm not sure that the I2C bus was intended to go across CAT5 cable in one's backyard.  It's been a nice Christmas break.  Tomorrow it's back to work.  With a second Arduino, I created a third thread in the daemon to manage communications with the new Arduino.  Using the threading module, I'm using the semaphore Lock() to control access to a set of variables shared between the two threads.

December 29, 2012:
  Sky thermometer lasted more than a day before it hung.  Added a diagnostic to the LCD to figure out where in the loop it's hanging -- the assumption that the LCD library is not the cause.  Otherwise the sensor is doing well.

December 28, 2012:
  The sky thermometer goes down every couple hours.  Added more error handling and retry ability.  Now it's been running for 10 hours without a fault.  Huh.  I'm thinking the next sensor is a lightning detector.  There's an interesting circuit here.  Another good discussion is here.  There's also a one-chip solution that seems to do the trick.  Nice snow today.  I've had to run out and brush snow off the sky thermometer a couple times.  Cross country skiing in the snow is wonderful though.

December 27, 2012:  The sky thermometer stays up for about 8 hours at a crack.  Added more error checking and reporting into the Arduino code in an attempt to catch what's going on.  Also, slowed the I2C bus down from 50 kHz to 32.768 kHz. I think the reads may be hanging.  More run time will help figure it out.

December 26, 2012: Finished building the sky thermometer before Christmas.  Installed it outside this afternoon.  Using python threading library to communicate with the new Arduino that handles that sensor.  The cabling downstairs is a total disaster right now.  That needs to be fixed.  Also, with the second Arduino, I may have a chance for assembling a watchdog for the first Arduino.  That would be cool.  Not enough heating in the rain gauge at this point.  I bought a higher power, multiple voltage wall converter (they aren't really wall transformers any more).  I've since used it for the second Arduino.  I also need to update my code to handle the second Arduino to retry connecting in the cast that the connection it fails.

December 16, 2012:
Ordered parts for the sky thermometer.  Everything came in Wednesday and Thursday. I assembled the design and it worked out of the chute.  The only concern I have is that the 10 degree field of view thermometers (MLX90614-xxF) from Melexis do not have their lens/window at the top of the sensor.  There's a open barrel with the window at the bottom.  This leaves a place for moisture to pool.  Putting a window on top of the sensor is impractical.  So, I'm probably going to order a sensor that has the 35 degree field of view (MLX90614-xxC).  The snow that fell last weekend is gone. 

December 9, 2012:
  The resistance of the total circuit to the rain gauge heater is 13.7Ω.  The heater is 8.0Ω. There is 5.7Ω of loss in the cabling.  Added a styrofoam insulator around the outside of the rain gauge.  

December 8, 2012:
  Looking at parts, Digikey stocks a better sensor (a visible light filter, in stock and with a tighter field of view).  It will require a second Arduino.  With a month of data from the new location of the weather station, I am very happy with how things are working.  This seems like a really good compromise.  Leveling the anemometer mast also really helped allow the wind speed to be measured at lower speeds (before the sensor sticks at zero).

December 4, 2012:  It would be neat to know (even at night) whether there are clouds outside.  One way to do this would be to build a laser ceilometer.  That's NO small endeavor and would probably require hundreds of hours of engineering.  Another way to look at the problem might be to look at the sky temperature.  That seems like a much easier problem.  Sparkfun has an infrared thermometer.  I'm wondering if that would get 80 percent of the information that a ceilometer would provide?!

November 25, 2012:  The right place to fix the software bug found yesterday is on the Arduino.  I'll need to recreate the development environment (I re-imaged my laptop this fall).  We received our first snow last night.  I'm glad I didn't put the pyranometer on the roof.  How do you easily clean it when snow piles up on top of it if it's on top of a two-story building with a 6:12 roof?  Good lesson.

November 24, 2012:  Yesterday we reported a 49 mph wind gust and that was reported on the National Weather Service (Green Bay Office) Public Information Statement.  This station is identified as 2 W COMBINED LOCKS (767 FT)(APRSWXNET).  Today I leveled the mast with a 1/2" shim.  Since it was moved two weeks ago, it's listed 1.2 degrees toward the north.  The hope is that with it a little closer to level that it will spin at lower wind speeds.  It seems to cut out at around 4 mph (1 Hz).  Moving the cables around caused the pyranometer not to be read, rebooting the Arduino and causing the first couple minutes of humidity data to be bad (a software bug).

November 17, 2012:
  A week on the new configuration without issues.  I have increased confidence that this is working!

November 13, 2012:  It was a nice sunny day.  The unshaded pyranometer data looks good.  Measured wind speed and direction look fantastic the last couple days (winds have been from the south and west).  Data transmission has been solid.  This is a great way to start year 2.

November 11, 2012:
  We've got a solid day's worth of runtime on the new location.  I'm as happy as one can be in a day.  I'll wait to see how things go over the next couple days.  Given that the pyranometer is now in a good location, I have now started to report solar irradiance to APRS, Weather Underground and Weatherbug. 

November 10, 2012:  Somewhere between October 14th and 17th WV[1] became stuck.  It now always reads a value of zero.  Disassembled the wind vane.  Corrosion on many things.  Cleaned everything up with alcohol and put some urethane on it.  Hopefully that will fix things.  I ought to write a diagnostic to look for stuck bits.  One thing to be said is that a stuck-at bit on a single track gray code encoder really messes with things.  But given how dreadfully the location of the wind vane was, I didn't notice it.  I moved the screen out to the garden.  Rise times on the I2C bus have gone up to around 4.5 us.  I'm not sure that's sustainable.  We'll have to see.  Needless to say I didn't remove the cables from where the screen was.

November 9, 2012:
Happy anniversary.  One year.  Today I moved the wind vane, anemometer & pyranometer to an intermediate spot on top of the fort/slide in the back yard.  The pyranometer shouldn't be shaded by anything now.  The anemometer and wind vane see a better (but still not ideal) view of the wind.  The sensors are now 15 feet above the ground.  I buried cable in the ground using an ice chipper to cut a small trench.  The wires aren't buried more than 3 or 4 inches below the ground.  That's okay.  This caused difficulties.  The extra capacitance slowed down the I2C signals so that they had a rise time of 10 us.  Fortunately, the SDA and SCL pull-ups were 10 kohms.  I change them to 1 k.  That speed things up to about 2.8 us.  Last December when I measured them I had about 1.2 to 1.6 us.

October 1, 2012:
Sometime on Saturday a bug got stuck in the anemometer.  It froze until I unfroze it about 6 PM tonight.  Also, yesterday (Sunday) the Arduino went down for a couple hours.  I so very much wish the watchdog worked on the Arduino.

September 16, 2012:
  The humidity sensor is shot.  There was a spider living on the sensor's circuit board, but the sensor itself (talking off its cover), seemed fine.  I soldered in the spare sensor and brought the station back online at 11:20 AM local time (17-Sep 16:20 UTC).  Calibrating it will take a little time.  The data, though, won't look any worse that what's been out there recently.  I did have to add a little urethane to complete the conformal coating.

September 14, 2012:  Looks like the humidity sensor saw another stepwise offset in calibration at about 4 AM (UTC) on 13-Sept. 

September 8, 2012: Updated the temperature offset was -0.555 C.  It's now +0.056 C. 

September 7, 2012:
  Adjusted the humidity cal again.  It's drifting quickly.  I need to replace the current sensor.

September 6, 2012:
  Last night the anemometer got hit by an errant football.  One of the cups was rotated.  This morning I fixed it.  A potato beetle crawled out of it.  I wonder if it needs to be taken apart and cleaned?  Took it apart in the evening.  For rotating 16 million times over the last 10 months, it looks great.  One of the nuts loosened up.  Fixed it.  Beyond that it was in great shape.

September 3, 2012:  The station's data is now shown on WeatherBug.

September 2, 2012:  Updated the humidity cal again yesterday the dry air frequency went up another 20 Hz.  Today I wrote the code to interface the station server to WeatherBug.  It will probably take a couple days to show up on the WeatherBug maps.  But, their server is accepting data as of about 5 PM CDT today. 

August 25, 2012:  Updated the humidity cal again.  Updated at 12:40 PM.  rh = -(freq - 7878) / 1301.  This evening I went to use the family iPad (that had WeatherBug loaded on it).  The station isn't listed there.  That got me to wondering, can it?  Looks like it can.  From the FAQ I found that the uploading API is here.  It's time to build the pad for the screen.

August 19, 2012:  The calibration function for the humidity sensor seems to have shifted.  I ran analysis of data between 13 Aug 19:51 and 19 Aug 16:21 to get a new function:  rh = -(freq - 7830) / 1262 (R2=0.954).  The frequency output for saturated air seems stable.  The low humidity value seems to be drifting higher.  I'm wondering if the pyranometer sensor is too close to the pole.  Are reflections from the while pole adding extra measured solar irradiance as the sun is in the south?

August 18, 2012:  The linear transfer function that describes relative humidity as a function of sensor output frequency is not linear down to low relative humidity values.  Yesterday the station reported a dew point of 15 as a result.  That's not right.  A little more analysis needs to happen here.  

August 12, 2012:  Moved the pyranometer onto the pole with the wind vane and the anemometer.  The station was down from 2:10 PM to 3:35 PM.  Before, the pyranometer cable was hard soldered to the sensor.  I added an RJ45 connector that now connects to a standard Ethernet cable in the pole (protecting it from the weather).  With this, the pole and the screen are ready to be moved.  Both of these moves should happen this fall.  The screen needs an second coat of paint.

July 22, 2012:
  Moved the rain gauge.  Updated the wiring to use extra pins on the temperature/humidity cable.  One less cable running in the house.  Testing the rain gauge, I am noticing that I'm loosing counts.  I do need to look at the debouncing of the rain gauge.  At 9:30 PM, I brought version 1.28 of the Arduino software online. Preliminary testing shows it works better.

June 18, 2012:  Great test overnight.  We had a good thunderstorm.  Interestingly, between 4:45 and 4:49 AM, the Arduino reset (during the middle of the storm).  I lost a couple rain counts -- at least 3 before it reset and 1 after.  That would have brought the rain total from 0.59 inches to 0.68 inches.  That's still low compared to everyone else nearby.  Is the debounce count too high?  In the past, the rain data had been close.  Given the reset, lightning protection implementation is important.

June 17, 2012:  I looked at the debounce logic more carefully.  And rewrote it.  Took the station down for 45-minutes to test the updates.  This also fixed a bug where the rain gauge seemed to "count" a large number of tips at the boot time of the Arduino.  I don't even want to explain the issue.  It's a bit embarrassing.  Made one more update at the end of the day to record the last captured anemometer and rain gauge count length.  I was reminded of issues I had going back to November.  If the Arduino is connected to the USB port of my laptop (and not powered by a wall transformer), the frequency measured by the HH10D bounces all over.  As soon as I power the unit off the wall transformer, the data stabilizes to within a couple Hertz.  I wouldn't have even noticed it had the system crashed a couple times with relative humidities that would have been zero.  There's a bug in that the daemon that sets relative humidity to zero if the relative humidity reads very low (off scale).  That might better be set to 0.5 or something.  Taking the log of zero doesn't work so well.

June 8, 2012:  This weather station is experimental.  I keep repeating that to myself.  I went to update the Arduino with the fix for rain gauge and anemometer debounce bug.  Between the last firmware update and today, I updated my laptop to Ubuntu 12.04.  12.04 uses the Arduino 1.0 API.  So, the effort should have been a two-step process.  First, update the code to the 1.0 API.  Then, add the bug fix.  Unfortunately, the 1.0 API code update failed miserably.  Ethernet stopped working.  So, the station is down.  Worse, the Arduino doesn't archive binary files, so I can't just upload the last binary that did work.  I'm building a VMWare image with Ubuntu 11.04 to load Arduino 0023 in hopes of getting back on-line.  Lesson: save the hex files (even if the Arduino tools are trying to be nice and keep the clutter away).  ...Several hours of non-value added time elapse... Back on-line at 10:45 after a yucky rebuild process.  But, now, I have the hex file that was used for the build.  Ugly lesson learned.  I now have a VM environment for the build.  To get some sense of accomplishment from this, I deployed the debounce fix.  Something came from this.

June 5, 2012:  The station had a nuisance rain count last night (and one over the weekend).  I need to think it through more carefully, but I think both the rain gauge code and the anemometer code may have a defect.  I think if (rainSwState == 1) { should probably read if (rainSwState == SWITCH_DEBOUNCE) {.  Either that or SWITCH_DEBOUNCE needs to be longer (more counts).  After looking at 28 days of run time on the TMP102, it's reading about 1.0 F high.  Subtracting the offset.  This is effective 8:55 PM local time.  The relative humidity update from mid-May seems pretty solid. Verified that, with the A/C fan running, pressure measurements aren't adversely affected by positive or negative pressure in the basement.  That also looks good.  Built a pinhole camera to look at the Venus transit tonight.  Took pictures of the results.  Neat.

June 2, 2012:  Building a platform to set the rain gauge on top of the Stevenson Screen.  I'll also be working on wiring it up, so that only one cable will be required for the screen.

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/m2 and m is the measured pyranometer sensor in millivolts, the formula I got was P = 0.7405537 * m1.270819.  R2 = 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/m2.  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/m2.

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 (R2=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 w
e 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 (R2=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 (R2 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 measurement
s 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/m2/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/m2.  That's great news.  3.03 W/m2/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/m2).  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, R2 was 0.950.  On Friday we got snow.  We weren't around to see it.  The rain gauge measured one coun
t.  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, R2 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 el
se, 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.

November 7, 2011:  First entry in the weather.log at 7 PM local time:  {'TemperatureF': '56.12', 'htick': '741366', 'deltat': '15157', 'TemperatureC': '13.40', 'oldhtick': '535844', 'Pressure': '98426 Pa', 'time': 'Sun, 06 Nov 2011 19:00:06 CST', 'freq': '6802', 'tickchange': '51552'}

Dictionary Meaning

Below is a definition of what each key in the dictionary means.  This section is at the end of the page as its mostly reference only.

KeyMeaningExampleUnits / Data Type
This represents the number of counts (at the frequency of the humidity sensor) that the anemometer signal was active during the last time it asserted.  This is a diagnostic used in the debounce of the reed switch.
string, convertible to an int.
The station barometer (referenced to sea level) in mmHg.  This value is a fixed offset (based upon altitude of the station) to PressurePa.
string, convertible into a %.3f float.
deltatThe 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.
string, convertible to an int.
dewptThe 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.
The number of rotations of the anemometer in the most recent sampling interval.
string, convertible into an int.
freqFrequency 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.
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.
string, convertible into a %.2f float.
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.. 
string, convertible to a signed 32-bit int, that wraps.
inst_wind_angleIn the last sampling interval, what was the wind angle.  This info is derived from the WV key.' 48'
string, convertible to a space padded, three-digit int.
The absolute pressure in pascals at the station. Individual pressure entries are filtered through an infinite impulse response (IIR) 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.  This might also be referred to as station pressure.  This is the actual pressure (not adjusted down to sea level).
string, convertible to an int.
PressurePafThis 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.
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.
string, convertible to a float.
rain_countThis 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.
string, convertible to an int.
rain_hrThe number of rain gauge tips in the last previous 60 minutes.
The number of rain gauge tips since the start of the day (based upon local time). 
The number of rain gauge tips in the last 24 hours.  0counts
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.
string, convertible to a float.
This represents the number of counts (at the frequency of the humidity sensor) that the rain gauge signal was active during the last time it asserted.  This is a diagnostic used in the debounce of the reed switch.'170'
string, convertible to an int.
ScriptRevThe RCS revision number of the python daemon, weather that manages data collection and reporting.
The RCS revision number of the Arduino sketch.'1.24'revision
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;  '4' = +0.25C;  'FFFFFFFF' = -0.0625C
'101'fixed point Celsius
fixed point represent of of temperature in Celsius.
taAmbient temperature seen by the IR temperature sensor.
'25.05'degrees Fahrenheit
string convertible to a %.2f float.  'nan' if no value available.
TemperatureCBefore 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
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
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.
tobjTemperature of the sky seen by the IR temperature sensor.  This is corrected for the cover for the sensor.
'17.48'degrees Fahrenheit
string convertible to a %.2f float.  'nan' if no value available.
tobjrawTemperature of the sky seen by the IR temperature sensor.  This is the uncorrected temperature seen by the sensor directly.
'18.93'degrees Fahrenheit
string convertible to a %.2f float.  'nan' if no value available.
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.
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.
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)
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_dirThis 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.
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_2The 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.
This is the largest wind_freq measured in the recording interval.
'3.34'counts / second
string, convertible to a %.2f float.
This is wind rate fastest.  Within the last sampling interval, what is the shortest interval of time in which the anemometer rotated.
string, convertible to an int.
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.
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.
string, convertible into a tuple, 5 entries long of ints.

Greg Hawley,
Jul 22, 2012, 8:37 PM
Greg Hawley,
Jun 17, 2012, 12:39 PM
Greg Hawley,
Feb 22, 2012, 8:59 PM
Greg Hawley,
Jul 28, 2012, 10:07 AM