Footprints frozen in the Creek

Reading today’s weather discussion from the Weather Service, they state:

LITTLE OR NO SNOWFALL IS EXPECTED IN THE FORECAST AREA FOR THE NEXT WEEK.

The last time it snowed was November 11th, so if that does happen, it will be at least 15 days without snow. That seems unusual for Fairbanks, so I checked it out.

Finding the lengths of consecutive events is something I’ve wondered how to do in SQL for some time, but it’s not all that difficult if you can get a listing of just the dates where the event (snowfall) happens. Once you’ve got that listing, you can use window functions to calculate the intervals between dates (rows), eliminate those that don’t matter, and rank them.

For this exercise, I’m looking for days with more than 0.1 inches of snow where the maximum temperature was below 10°C. And I exclude any interval where the end date is after March. Without this exclusion I’d get a bunch of really long intervals between the last snowfall of the year, and the first from the next year.

Here’s the SQL (somewhat simplified), using the GHCN-Daily database for the Fairbanks airport station:

SELECT * FROM (
    SELECT dte AS start,
        LEAD(dte) OVER (ORDER BY dte) AS end,
        LEAD(dte) OVER (ORDER BY dte) - dte AS interv
    FROM (
        SELECT dte
        FROM ghcnd_obs
        WHERE station_id = 'USW00026411'
            AND tmax < 10.0
            AND snow > 0
    ) AS foo
) AS bar
WHERE extract(month from foo.end) < 4
    AND interv > 6
ORDER BY interv DESC;

Here’s the top-8 longest periods:

Kinda scary that there have been periods where no snow fell for more than a month!

Here’s how many times various snow-free periods longer than a week have come since 1948:

We can add one more to the 8-day category as of midnight tonight.

Early-season ski from work

Yesterday a co-worker and I were talking about how we weren’t able to enjoy the new snow because the weather had turned cold as soon as the snow stopped falling. Along the way, she mentioned that it seemed to her that the really cold winter weather was coming later and later each year. She mentioned years past when it was bitter cold by Halloween.

The first question to ask before trying to determine if there has been a change in the date of the first cold snap is what qualifies as “cold.” My officemate said that she and her friends had a contest to guess the first date when the temperature didn’t rise above -20°F. So I started there, looking for the month and day of the winter when the maximum daily temperature was below -20°F.

I’m using the GHCN-Daily dataset from NCDC, which includes daily minimum and maximum temperatures, along with other variables collected at each station in the database.

When I brought in the data for the Fairbanks Airport, which has data available from 1948 to the present, there was absolutely no relationship between the first -20°F or colder daily maximum and year.

However, when I changed the definition of “cold” to the first date when the daily minimum temperature is below -40, I got a weak (but not statistically significant) positive trend between date and year.

The SQL query looks like this:

SELECT year, water_year, water_doy, mmdd, temp
FROM (
    SELECT year, water_year, water_doy, mmdd, temp,
        row_number() OVER (PARTITION BY water_year ORDER BY water_doy) AS rank
    FROM (
        SELECT extract(year from dte) AS year,
            extract(year from dte + interval '92 days') AS water_year,
            extract(doy from dte + interval '92 days') AS water_doy,
            to_char(dte, 'mm-dd') AS mmdd,
            sum(CASE WHEN variable = 'TMIN'
                     THEN raw_value * raw_multiplier
                     ELSE NULL END
               ) AS temp
        FROM ghcnd_obs
            INNER JOIN ghcnd_variables USING(variable)
        WHERE station_id = 'USW00026411'
        GROUP BY extract(year from dte),
            extract(year from dte + interval '92 days'),
            extract(doy from dte + interval '92 days'),
            to_char(dte, 'mm-dd')
        ORDER BY water_year, water_doy
    ) AS foo
    WHERE temp < -40 AND temp > -80
) AS bar
WHERE rank = 1
ORDER BY water_year;

I used “water year” instead of the actual year because the winter is split between two years. The water year starts on October 1st (we’re in the 2013 water year right now, for example), which converts a split winter (winter of 2012/2013) into a single year (2013, in this case). To get the water year, you add 92 days (the sum of the days in October, November and December) to the date and use that as the year.

Here’s what it looks like (click on the image to view a PDF version):

The dots are the observed date of first -40° daily minimum temperature for each water year, and the blue line shows a linear regression model fitted to the data (with 95% confidence intervals in grey). Despite the scatter, you can see a slightly positive slope, which would indicate that colder temperatures in Fairbanks are coming later now, than they were in the past.

As mentioned, however, our eyes often deceive us, so we need to look at the regression model to see if the visible relationship is significant. Here’s the R lm results:

Call:
lm(formula = water_doy ~ water_year, data = first_cold)

Residuals:
    Min      1Q  Median      3Q     Max
-45.264 -15.147  -1.409  13.387  70.282

Coefficients:
             Estimate Std. Error t value Pr(>|t|)
(Intercept) -365.3713   330.4598  -1.106    0.274
water_year     0.2270     0.1669   1.360    0.180

Residual standard error: 23.7 on 54 degrees of freedom
Multiple R-squared: 0.0331,     Adjusted R-squared: 0.01519
F-statistic: 1.848 on 1 and 54 DF,  p-value: 0.1796

The first thing to check in the model summary is the p-value for the entire model on the last line of the results. It’s only 0.1796, which means that there’s an 18% chance of getting these results simply by chance. Typically, we’d like this to be below 5% before we’d consider the model to be valid.

You’ll also notice that the coefficient of the independent variable (water_year) is positive (0.2270), which means the model predicts that the earliest cold snap is 0.2 days later every year, but that this value is not significantly different from zero (a p-value of 0.180).

Still, this seems like a relationship worth watching and investigating further. It might be interesting to look at other definitions of “cold,” such as requiring three (or more) consecutive days of -40° temperatures before including that period as the earliest cold snap. I have a sense that this might reduce the year to year variation in the date seen with the definition used here.

Prototype temperature sensor

Last week I got permission to install a simple weather station where I work at ABR. The Fairbanks office is located on Goldstream Road, just past the intersection of Murphy Dome Road, across the street from the Peat Ponds. It’s on the uphill side of a south facing slope, and is about half a mile from Goldstream Creek. More importantly for me, I can find out what the temperature is at work when I’m dressing for riding my bike or skiing.

We ran three Cat5e cables from the computer room, outside and under a footpath, then down the hill from the Main building. The cables end up in a mixed spruce-birch forest, and the sensors will be about six feet off the ground in one of those cylindrical “white plate” style enclosures.

I’m using a pair of DS18B20 temperature sensors, which have a 0.5°C accuracy across their range, and will work down to -67°F. The data is retrieved using the One-Wire protocol, which is well supported by Arduino. I built a prototype of the sensor before soldering it down on a board because longer distances can require a smaller pull-down resistor than the 4.7KΩ typically used between the voltage and data lines. I also wanted to experiment with whether I could run two using parasitic power, or would need two data lines. As it turned out, 4.7KΩ worked, as did parastic power mode.

The schematic is below, including the wires I used in the Cat5e cable. I followed the PoE standard, even though I could really have used whatever wires I wanted.

I also used a contributed library called DallasTemperature which abstracts most of the work of using OneWire and converting the values into meaningful temperatures. Here's the setup code:

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 8
#define TEMPERATURE_PRECISION 9

OneWire oneWire(ONE_WIRE_BUS);

DallasTemperature sensors(&oneWire);

// Use a testing program to find your addresses:
DeviceAddress thermOne = {
    0x28, 0xBC, 0x29, 0xE3, 0x02, 0x00, 0x00, 0xE1 };
DeviceAddress thermTwo = {
    0x28, 0xCF, 0x97, 0xE3, 0x02, 0x00, 0x00, 0xCD };

void setup(void) {
    Serial.begin(9600);
    sensors.begin();
    sensors.setResolution(thermOne, TEMPERATURE_PRECISION);
    sensors.setResolution(thermTwo, TEMPERATURE_PRECISION);
}

And the part that does the work:

void printTemperature(DeviceAddress deviceAddress) {
    float tempC = sensors.getTempC(deviceAddress);
    Serial.print(DallasTemperature::toFahrenheit(tempC));
}

void loop(void) {
    sensors.requestTemperatures();
    printTemperature(thermOne);
    Serial.print(",");
    printTemperature(thermTwo);
    Serial.println();

    delay(1000);
}

Here’s the schematic. The top form shows two sensors in parasitic power mode (where you only need a single data line, power and ground), and the bottom form shows how you’d wire a single sensor. If I had trouble with getting reliable data from the sensors in parasitic mode, or with a 4.7KΩ resistor, I would have dropped the resistor to 3.3KΩ or 2.2KΩ. The next thing I would have tried would be running power and ground to both sensors separately (coming from wires 4 and 7 in the cable), and used wire 1 and wire 2 for the data lines to each sensor. As it turned out, I’m only using three of the eight wires in the cable.

Update 2012-10-15: I moved the resistor from the sensor board (you can see it in the photograph at the top of the page) to the Arduino end of the cable inside ABR, and the data is still flowing. I was a little concerned that the resistor might be adding a small amount of heat to the enclosure, and putting it at the Arduino side prevents that possibility.

Update 2012-10-19: Today I added a third DS18B20 in parasitic mode and I’m getting data from all three sensors. I would guess the total cable run is around 100 feet from the Arduino to the sensors. So: 100 feet of Cat 5e, three sensors in parasitic mode, with a 4.7KΩ pull-down resistor between power and data on the Arduino side of the cable.

Nika in a blizzard

This morning we had five inches of new snow on the ground, and it’s been snowing pretty consistently since, with really heavy snowfall in the last hour or so. As of midnight last night Fairbanks was 12.7 inches below normal for cumulative snowfall since July 1st (last year), but if this keeps up, we may actually get to the normal amount of snowfall. It’s been many years since that happened.

Unfortunately, like last year, the blizzard of 2012 is coming at the very end of the winter. Last year we got more than a foot of snow at the end of February, and this time around it’s even later. Still, there’s at least three more weeks of good ski conditions to look forward to, and this snow may help flatten some of the bumps on the Valley trail.

It’s hard to take a photograph that captures what a blizzard looks like because the snow that’s falling just mushes the background, but take my word for it: it’s really coming down!

Over the past couple weeks I’ve been experimenting with a data logging shield from adafruit. My original idea was to build a unit I could take with my on my commute to work to see how the temperatures change over the route. I’m also interested in watching the temperatures inside a dog house when there’s a dog sleeping in there. During the cold snap, where temperatures got as low as -55°F, how warm could the dogs keep their houses (which are insulated)?

I added a three axis accelerometer (ADXL335) with the idea it could tell me when I was moving, but I don’t think I can afford to read (and log) the sensors that often when it’s running off batteries (6 AA cells) at cold temperature. Instead, it’ll tell me the position (relative to the ground) of the logger, and I’ll use that to indicate when I start whatever activity I want to measure. The data logger starts logging as soon as it gets power, and even though it has a clock, it may drift relative to GPS time, so I can time the start based on when the logger’s position changes.

Here’s the schematic:

I wired it on a breadboard first to confirm the circuit was correct and to get the program storing the data. The data logger shield has a 10 x 10 perfboard section, so once everything was working, I soldered the parts directly onto the board using the plan below. The black lines are above the board and the orange lines are the solder joins below the board.

I don’t know yet how long the battery will last, but I ran it last night in the arctic entryway and got the following data:

The orange dots are from the temperature sensor on the board, wrapped in bubble wrap and sitting inside a cardboard box. The cyan dots are from the waterproof sensor outside of the box. Our arctic entryway is heated with a ventilation fan that blows warm air from the house into the room, so the oscillation in the temperature shows the fan going on at the bottom of the sweep and then off at the top. The insulation in the box reduces the temperature fluctuations and traps the slight amount of heat produced by the electronics.

Time to watch the Super Bowl.