Two words that one doesn’t expect to see together, assuming one knows what they mean.

Brisket, of course, is a cut of meat from the chest area of the beef animal. Brisket is a cheap cut ($3.99/pound from my butcher) because it’s a working muscle, and therefore has a lot of connective tissue. Which makes it tough if you cook it like you would cook any other cut of meat. But if you cook it for a long time and it gets to a nice high temperature (195 degrees F, or so), the connective tissue breaks down and you end up with a very tasty piece of meat.

The best way to cook brisket is on a smoker – you can add a wonderful wood smoke flavor to the already flavorful meat. But there are a few downsides.

First, smoking takes a long time. A *long* time. Cooking times of 12 hours are not uncommon, and that means that if you want to eat brisket at 7PM, you need to get it on the smoker at 7AM, and spend the day tending the smoker. Or you could use an electric smoker like I do, though you still need to tend it every hour or so to add wood.

The second downside is that the time it takes to cook is quite variable. It takes energy to break down the connective tissue and the amount of connective tissues varies from brisket to brisket, so the amount of time it takes to get to the final temperature varies. It might be 12 hours, or it might be 16 hours.

Purists would say that that is the price of good brisket, but I’ve been looking for a shortcut, and I think I’ve found one.

You start the way you normally would, by trimming the fat off the brisket and using a nice dry rub one it. You can trim off more fat than you normally would because you don’t need to protect the brisket from the heat for as long. In this case, I cut the brisket into 7 pieces so that I wouldn’t need to cook them all at once (more on that later). The brisket went in the fridge for the night.

In the morning I set up the smoker (a cheap electric bullet one), put some mesquite in, and put the brisket pieces on the grate. After an hour, I replenished the wood, and went on a 4 hour bike ride. It probably would have worked better to keep putting wood in every hour but I was time-pressed that day. After I got home, I took all the pieces off, and put all but one in the freezer. I need to do that because the foodsaver I use to vacuum-pack won’t seal the hot chunks of meat – it will must pull the juices out of them and pull that into the foodsaver.

So, now we have a chunk of meat that is nicely smoked but only at about 150 degrees or so.

The second step is the Sous-Vide one. I get out my rice cooker and hook up my temperature controller, setting it at 195 degrees. Generally when you do sous-vide, you use a totally sealed package. If you do that with high-temperature sous-vide (say, about 180 degrees or so), the moisture in the meat that you are cooking will go into gas, which will blow up the package until it bursts, at which point you are now poaching it. What I do is make a tiny hole in the corner of the sealed package, thread a bit of butcher’s twice through it, and use that to hold that part of the pouch above the water. That does compromise the heat transfer rate but it doesn’t matter much.

So, make sure the twine holds up the pouch, close the top of the cooker, and then leave it. For the one that came straight of the smoker, it was nice when it had spent 5 hours. I did a couple that were frozen and then thawed in the fridge, and they did pretty excellent in 9 hours (I put them in before heading to work and took them out when I came home).

After it’s cooked, pull it out, cut it up, and then put it in a bowl with the juice that was in the pouch.

Downsides? Well, you don’t get the same crusty ends that you would get in the cooker, but other than that it’s great.

 

 

 

Sous-vide would seem to be a great solution – it’s designed to get a food to an exact temperature

Let’s start with a summary:

Statistics:

Time: 3.5 hours
Steps: 11385
Elevation gain: 5’ 8”
Calories burned: 3557
Tickets: 2
Pursuits: 1
Sleep: 4 hours
Food: 528 calories

Map:

I have a snazzy new Garmin 705 GPS enabled cycle computer. Here’s the map:

 Gear:

It’s generally a bad (where “bad” = “lying on the ground wishing you hadn’t done something so stupid”) idea to use gear that you haven’t tested on the day of a ride, but this time I decided to make an exception. It’s pretty dark that early in the morning, so having some extra light and visibility is a good idea. Here’s what I chose:

Overall:

I felt pretty good in the morning, though (unsurprisingly) I got a little tired as the day wore on. I’m definitely looking forward to RAMROD 2011, assuming my back and shoulder are better by then.

If you’ve been shunning the bakery section of your supermarket for a while, you may not be up on the “two-bite” phenomena. Basically, “two-bite” is brand for an assortment of deserts that come in clear tubs. I’m not sure why they are named “two-bite”, since they are more correctly called “byte-sized”, and if you try to eat them in two bites you get crumbs all over.

I’m a fan of both the brownies and the scones.

Last week I needed to pick some snacks for the meeting, and came across a new “two-bite” produce – a brookie, a combination of a brownie and a chocolate-chip cookie. Sounds great, right?

Yes it does. In fact, it sounds better than it is.

The first problem is the cookie. The essence of a chocolate-chip cookie is something that spreads out, is a bit crunchy and still a bit soft. What you get is a cookie-cake, which everybody knows is not as good as a cookie. The brownie also suffers – it’s dry rather than full of creamy and chocolatey goodness.

Not recommended.

I've used http://www.accelerade.com/mountain berry as a hydration drink for quite some time. It works pretty well, but it has a problem - it's sweetened mostly with sucrose, which means that it's quite sweet. They use some citric acid to counter that a bit, but after a couple of hours it gets too sweet to drink.

Some people dilute it, which makes it less sweet but also reduces the number of calories in a bottle. I prefer to make the existing drink less sweet.

What we need is a sugar that acts like sucrose but is less sweet. Maltodextrain is a complex carbohydrate - a chain of glucose molecules all hooked together (sometimes known as a glucose polymer), and it breaks down to glucose very easily.

I get mine from the supplement house:

 

My current recipe is 2.5 parts Accelerade to 1 part maltodextrin. I did one batch at 2:1 which is another option.

Recipe:

3 3/4 cups Accelerade (750 grams)
2 1/4 cups Maltodextrin (300 grams)
1 teaspon salt

Put in a big bowl and mix. This amount will fit in one of the small accelerade containers. The amount of salt is slightly more than what it would normally have - if you want to keep the sodium the same, you need 8/10ths of a teaspoon.

This also has less protein - instead of the 4:1 ratio, you're down to something less than that. You could add more whey protein if you wanted.

 

I wrote some custom code to convert the community server blog entries to a blogml version so that I could import it into blogengine.net. I considered using the blogml assembly to create the code, but decided to hand-code it instead.

The way to use this is to create a blog, write one post, export it out (settings->export), and then hand-insert the categories and post sections into that exported file, then re-import it back. I decided to skip comments to make things easier.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.SqlClient;
using System.IO;

namespace blogconverter
{
    class Program
    {
        static SqlDataReader Execute(string query)
        {
            SqlCommand command = GetConnection().CreateCommand();
            command.CommandText = query;
            SqlDataReader reader = command.ExecuteReader();
            return reader;
        }

        static SqlConnection GetConnection()
        {
            SqlConnection connection =
                new SqlConnection(@"Data Source=HOMELAPTOP\SQLEXPRESS;Database=BCCommunityServer;Integrated Security=SSPI;");
            connection.Open();

            return connection;
        }

        static void Main(string[] args)
        {
            using (StreamWriter writer = File.CreateText(@"c:\data\website\posts.xml"))
            {
                string categories = GetCategories();

                string posts = GetPosts();

                writer.WriteLine(categories);
                writer.WriteLine(posts);
            }

        }

        static Dictionary _CategoryLookup = 
            new Dictionary();

        static string GetCategories()
        {
            StringBuilder b = new StringBuilder();
            b.Append("");
            SqlDataReader reader = Execute(QueryCategory);

            while (reader.Read())
            {
                int categoryId = (int) reader.GetValue(0);
                string name = (string) reader.GetValue(1);

                Guid id = Guid.NewGuid();

                _CategoryLookup.Add(categoryId, id);

                b.Append(String.Format(
                    @"
                       

My hosting company, Webhost4life, has basically imploded - they have been upgrading all their user sites and apparently killing most of them in the process, so I've decided to switch to a different provider (the hard-to-pronounce arvixe.com), and I've also switched over from commumity server.com to blogengine.net to make thing simpler. I'm going to have to do some hand-work to get the old posts to show up.

I've also decided to merge together my two blogs, just to make things easier. I'm not sure yet what's going to live on thegunnersons.com, as soon as I get the domain transferred over.

That's my second lesson on this - park your domains on a domain company, not with your service provider. If you do that, it takes 5 minutes to make them point to a new set of servers. If one of your domains is registered by your service provider and they get in trouble, you have to work to get it back.

Last spring, I had the pleasure of spending $1200 to replace a set of brake rotors (because you can't resurface BMW rotors) and the window mechanism on the driver's side (a design defect in 3-series cars). That, combined with the spousal desire to have a second AWD car led me to sell the BMW in September and start looking for a replacement. I didn't need to get a replacement right away since we had the car that I got for my daughter - a 1998 Honda Accord - but when she gets her license in May, I'd be stuck driving the Ranger.

After a bit of research, I settled on a not-so-obvious choice - a Subaru Legacy sedan.

Subaru spends a lot of effort marketing the Outback, the Forester, and the WRX. They've spent - at least until this year - very little money marketing the Legacy.

This perplexes me. The base legacy is a pretty nice 4 door AWD sedan at a good price. And they also put a slightly detuned version of their WRX turbo engine, making it a bit of a stealth racer. 0-60 under 6 seconds.

So, of course that was the one we wanted. But there was a problem.

We wanted a manual transmission. We wanted the Limited version (leather, heated seats). And, if at all possible, we wanted it in red. After a couple of months looking through auto trader and craigslist, I found one in San Jose at a dealer, but that one fell through. Then I finally found one in Portland, and picked it up about a week ago.

It's quite the sleeper. Looks like a normal 4-door sedan, flies on the road.250 hp, 250 ft-lbs of torque, intercooled turbocharger. Needs a new stereo to round it out.

Very nice, but according to the rules, it doesn't count as a midlife crisis because it's not a 2-door, so I guess I'll have to look elsewhere...

The software is all written in C using Codevision AVR, a pretty nice C compiler. It has a very nice wizard that lets you say that you are running your chip at 8MHz and then allows you to set (for example) the timer1 refresh rate to by 52000Hz from a pulldown menu rather than knowing that you need to set a specific register to a specific value. It also writes the shell of your interrupt servicing for you. Oh, and it knows what AVR microcontrollers support which features, so it won't let you configure the chip to do something it can't.

The only place where it falls down is setting the fuse bits (burned in settings for things like clock speed, whether you use the internal/external clock, and some pin assignments), which it just labels by name. For those I use AVR studio, Atmel's free development tool. If you want to go this route there is a version of GCC that you can use.

For the base station, all of the important operations are handled in interrupt code - the main loop just loops endlessly.

Timer1 code

The timer code runs at 10Hz. We get there by the following:

The timer rate is set to 31,250Hz. Since I'm looking for 10Hz, I need a base frequency that is evenly divisible by 10. The timer is set so that an interrupt is generated whenever the timer overflows (ie goes from 0xFFFF to 0x0000). We need this to happen every 3125 counts, so we set the initial value to 0xFFFF - 0x0C35 = 0xF3CA. That gives us the heartbeat.

Here's the code:

interrupt [TIM1_OVF] void timer1_ovf_isr(void)
{
        // Reinitialize Timer1 value
    TCNT1H=TCNT1H_VALUE;
    TCNT1L=TCNT1L_VALUE;

        // read the buttons from the remote, and turn on the output channels as necessary.
    HandleButtons();
    
    if (timeRemainingTicks > 0)
    {
            // In the last 5 minutes, blink the lights off for 1/10th of a second every minute.
        if ((timeRemainingTicks % 600 == 0) &&
            (timeRemainingTicks <= 3000))
        {
            PORTB = 0;
        }
        else
        {     
            PORTB = outputState;
        }
        timeRemainingTicks--;  
    }
    else
    {
        outputState = 0;
        PORTB = 0;
    }

        // every second or if the state is changed, we send out the heartbeat over the serial link.

    ticks++;
    if (outputState != outputStateLast || ticks == 10)
    {
        SendOutputState();
        outputStateLast = outputState;
    }

        // every second we blink the led for 1/10th of a second
    if (ticks == 10)
    {
        ticks = 0;
        if (outputState != 0 && timeRemainingTicks > 0)
        {
            STATUS = 1;
        }
    }
    else
    {
        STATUS = 0;
    }  
}

Serial port code

The interrupt handler is simple:

interrupt [USART_RXC] void usart_rx_isr(void)
{
    char status,data;
    status=UCSRA;
    data=UDR;
    if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))==0)
    {
        HandleChar(data);
    };
}

char state = 0;

void HandleChar(char c)
{
    switch (state)
    {
        case 0: // ready;
            if (c == 'S') state = 5;
            break;
            
        case 5: // 'S'
            if (c == '1')
            {
                AllOn();
            }
            else if (c == '0') 
            {
                AllOff();
            }
            state = 0;
            break;
    }
}

HandleChar is an implementation of a finite state machine - it looks for “S0” or “S1” and performs the appropriate action.

Remote Code

The remote uses the same timer approach as the base station.

// Timer1 overflow interrupt service routine
interrupt [TIM1_OVF] void timer1_ovf_isr(void)
{
        // Reinitialize Timer1 value
    TCNT1H=0xF3CA >> 8;
    TCNT1L=0xF3CA & 0xff;

        // The timeout is set to 20 ticks. If two seconds go by without
        // getting a heartbeat from the base station, we turn off the link LED    

    if (linkDetectedTimeout > 0)
    {
        linkDetectedTimeout--;
        LED_LINK = LED_ON;    
    }
    else
    {
        LED_LINK = LED_OFF;
        LED_LIGHTS = LED_OFF;
        currentLightState = 0;
    }

        // Set the light LED based on the current light state    
    if (currentLightState == 1)
    {
        LED_LIGHTS = LED_ON;
    }
    else
    {
        LED_LIGHTS = LED_OFF;
    }
    
        // If the button is pressed (and it's newly pressed),
        // send the appropriate on or off command.
    if (BUTTON == 0)
    {
        if (!buttonPressed)
        {
            buttonPressed = 1;
            if (currentLightState == 1)
            {
                SendString("S0");
            }
            else
            {
                SendString("S1");
            }
        }
    }
    else
    {
        buttonPressed = 0;
    }
    
        // Flash the power LED on for one cycle out of 10
    tenths++;
    if (tenths == 10)
    {
        tenths = 0;
        LED_POWER = LED_ON;
    }
    else
    {
        LED_POWER = LED_OFF; 
    }  
}

Serial port

void HandleChar(char c)
{
    putchar(c);
    switch (state)
    {
        case 0: // ready;
            if (c == 'E') state = 3;
            break;
            
        case 3: // "E"   
            if (c == 'G') state = 4;
            else state = 0;
            break;
           
        case 4: // 'EG'
            if (c == '1')
            {
                SetLightState(1);
                LinkDetected();
            }
            else if (c == '0') 
            {
                SetLightState(0);
                LinkDetected();
            }
            state = 0;
            break;
    }
}

Another finite state machine. Whenever it gets "EG0" or "EG1", it sets the link timeout and the appropriate light state.

I've finished my landscape lighting project, and thought I'd share how it came out.

I had a few requirements:

1. I wanted to be able to turn on and off the lights from out where the lights were (some 150' from the house) so we could have light when we showed up at night.
2. I wanted the lights to turn off automatically after 2 hours if they were accidentally left turned on.

My first design was pretty simple - I would put pushbuttons out with the lights and do a simple program for an AVR microcontroller to detect the pushbuttons and handle turning on and off the lights. That hit a couple of snags.

The first was a physical one - putting physical pushbuttons out meant that I'd have to run about 700’ of signal wire, build waterproof boxes to hold the pushbuttons, mount them on the trees, etc. That was a fair bit of extra work, and not the fun kind.

The second was a bigger problem. Sensing physical pushbuttons was insufficiently challenging and interesting.

So, a V2 design was born. I had been looking for an excuse to do something with some of xbee radio modems, and I decided to use the xbee pro modems for the project, since they are higher power and longer range. These are really cool devices which, in their default mode, act like a virtual serial cable. You send characters into the modem at one end, and the same characters come out the other end. It will do this at up to 250kbps and a maximum distance of a mile (your mileage may vary. Actual mileage will probably be less). You can do a lot more sophisticated stuff with it (meshes, repeaters, etc.) in the advanced modes as well. The modems also have some built-in analog->digital conversion and digital I/O circuitry built in, but since you need a microcontroller to drive it I don't see a ton of use for that in most applications (though it might be useful in some pc connected applications).

If you are building something that is xbee-based, I highly recommend getting one of the usb adapter boards like the one from sparkfun. It is really useful to send command from the PC, and you can use putstring to write debugging information back to the PC.

After a fair bit of experimentation, I ended up with the following scheme:

The base station sends out a status heartbeat every 1/10th of a second. It also handles the status led, any button presses on the wired remote, and timekeeping. Separately, it also handles any on/off command that come in over the xbee.

The remote receives the status heartbeat, and uses that to turn on the link led (lighted whenever the status heartbeat is received), and set the light status either on or off based on the current status of the lights.

Time for some pictures. Click on the picture for a bigger version that has the parts identified.

The big black box on the left is the base station. To the right of it is the wired remote, and on the far right is the wireless remote.

I should note that everything here is hand-wired. It's not what you would call neat, but it is simple to do and functional. The thin wire that you see is 30 gauge wire wrap wire, which is more than enough to carry digital signals. When I'm hooking it to discrete components (caps, resistors, leds, etc.) I use my cheap wire-wrap tool and wrap the wire around 3 or 4 turns, and then solder it. This makes it easy to hook the wire up so it doesn't come off while I solder it.

We'll start with base station.

In the upper left is the xbee pro radio modem sitting on top of a sparkfun adapter. The sparkfun adapter gives you easy access to all the pins, but the only reason I used it here was because it does the conversion between the 5v that the attiny is using and the 3v that the xbee wants. I could have done it all at 3v, but I didn't think about that option until I had already put in my last order for parts in.

Below that is the relay board. It has 4 channels (I added individual channels addressable from the base station). Each channel features a 5V relay that switch the 12VAC that the lights use. I'm not a big fan of relays - for AC either using solid-state relays or triacs is generally simpler, but 12VAC is an odd beast and nobody builds a lot of designs for that, so I went with the relays. The downside of the relays is that they require a fair bit of current - about 200mA each. That will cause a bit of an issue later. Each relay is driven by a dedicated transistor, since there's no way the ATTiny can push 800mA through it. The transistors are NPN power transistors in TO220 packages, which are a bit more rugged than the small ones in case I needed to dissipate a bit more heat. The relay board is the the least optimal part of the design, since it requires a 5V power supply that can put out a lot of current. A better approach would have been to use relays with 12VAC coils, and then drive the coils with some small triacs - that would have reduced the power supply requirements way down. If I had built that power supply up front and tested it driving 4 relays, I would have found that out, but I drove it from my bench supply instead. At the bottom of the relay board is where the 7805-based power supply lived originally, which worked but put out way too much heat.

To the left of the relay board is the terminal strip to connect the lights, and the 12VAC input at the bottom. This sticks through a slot cut in the side of the box.

To the right of the relay board is the switching power supply. I could have built one myself using the popular lm7525, but to make things simpler I ordered a prebuilt one. There's a hefty 2200uF capacitor on the input from the board to smooth out the rectified 12V from the full-wave bridge on the relay board, and then a 470uF capacitor to smooth the output of the 7525. That gives me the power I need to drive the relays without too much heat.

Finally, on the right side is a DB9 (aka “old-school serial port”) connector. In my current installation, the base station will live close to the wired switches, but will eventually move to an outbuilding. At that point I can just pull some cat5 wire and add connectors to hook the base to the wired remote. To the right is the wired remote, which couldn't be simpler - there are 5 pushbuttons and a status led, some wire, and a DB9 connector.

On the far right is the wireless remote.

In the upper left is the power switch. I went with a hardwired switch because the remote will likely rattle around in a glove compartment, and I was worried that any button-press approach would be prone to accidental activation. Below the switch is two AAA batteries, which gives me the 3V that the remote runs on. To the right of that is the xbee pro module, with 4 wires hooked to it - +3V, ground, transmit, and receive. Above that is the on/off pushbutton. Finally, lurking at the top-right is the bottom of the board that holds the attiny2313 - it's upside down because the status LEDs are underneath the board on one end, and if it was the other way it would be likely to short out.

Here are the assembled remotes:

On the left one, we have the three separate channels on the left, all on/all off on the right, and status at the top. The wireless remote has the pushbutton, on/off switch, and 3 status leds. The top led is power - it is on for 1/10th of a second, off for 9/10ths of a second. The middle led is link status (on =  linked), and the bottom is the light status (on or off, in case you can't actually see the lights).

My first year or so, I was shooting my daughter's lacrosse team, which played on weekend afternoons. Then, when my daughter entered high school, she switched to playing games that are in the late afternoon, early evening, or night. There are significant challenges to shooting these games, and there are some weird things that can happen that are very confusing.

This is where it gets expensive. My first year I was shooting with my Rebel XT and 70-200mm F4L, and in most of the games I was done by halftime because there simply wasn't enough light to be able to get any decent results. I upgraded to a 40D and the F2.8 version of that lens, which gave me about 2 more stops, which is the difference between 1/800th (tolerable), and 1/200th (not even close). This year I just upgraded to a 7D, which should give me another stop, perhaps 1.5 stops.

And I'm sure I'll still be complaining that I don't have enough light. It's just really hard to get the kind of results you can get during the day. Though I will say that having the equipment that lets me be functional at night provides much more flexibility during the day - instead of being stuck at F4 @ 1/800th, I can go to F8 or shoot closer to 1/2000th if I want to.

I like to think of these as three different environments, though you may get all of them in a single game.

Last afternoon (before sunset)

There are a few obvious things here. As you get closer to sunset, you are going to have to deal with less light. If it's cloudy, you will start with less light but it will generally hold up a bit longer, while if it's clear the light can go off really quickly. Consider shooting shots during warmup, and try to get a lot of the action early, especially if your gear doesn't do well in low light.

You will generally want to shoot with the light source at your back, though sometimes you may want to break the rules:

This is shot almost straight into the sun, and then I used a fair bit of fill light in lightroom to bring out the players. If you look at the original, it's pretty noisy, but it works well in B&W, and I like the outline of the sun in the hair.

This time of day does encompass the golden hour, and sometimes you get lucky, and the sun gives you perfect lighting. Not only is it nice and warm, but it can get inside helmets or headgear because of the angle.

Dusk/Twilight

At this point you are either contending with rapidly waning light or a mix of natural light and artificial light. The light will be changing pretty rapidly, so you may need to play around with your ISO settings often. The color balance may be weird, as the light from the sky will be very blue but the artificial lights usually aren't quite as blue so it can be hard to get colors that look decent.

Artificial lights

Artificial lights are designed to make sports at night possible. They are not - unless you are lucky enough to be in a college or pro stadium where they do TV - designed to make photography work well.

There are a few things that you may have to deal with, in addition to the lack of light:

You can't see it, but the majority of stadium lights pulse at 120Hz - they go on and off 120 times per second. If your shutter happens to open while they are off, you don't get any light. To improve this, many places use what is called three-phase power. Instead of one set of lights that go on and off every 120th of a second, you break the lights on each pole into three groups, with the second and third group each delayed a bit from the group before. So, you never have a time when all the lights are out.

Unfortunately, this sometimes doesn't happen. Sometimes a whole pole will be on one phase, so you may get pictures where one part of the field is lighted and the other isn't lit at all. If this happens where you're shooting, you have my sympathy - short of getting the lights rewired, there's no fix.

Even with correctly wired lights, you still have the problem that during each cycle the lights heat up and cool down a bit and the color temperature shifts.

Alternatives

If you can't get a decent shutter speed with your equipment, there are a couple things you can do. Some photographers shoot with strobes. To do that you would need decent power from the flash, a subject that's close, and approval from the coaches.

What I do is turn the iso down and get the shutter speed into the 1/10th of a second range, and pan. You can get some nice abstract shots with this.