Archive for May, 2009

IFR 19: NDB Approach

Sunday, May 17th, 2009

Yes, I’ve got an over-full work schedule, but what better way to decompress and get my mind off work than by practicing a full NDB approach in gusty crosswinds! Fun stuff huh?

After over two weeks of not flying due to delays from scheduling and weather problems instructor R and I took off into winds of 15 kts gusting to 21 this morning. But first, we talked and planned our flight.

The talking covered several things, one key thing was if we should fly or not. After discussing the effects on enroute flight, takeoff, and landing, and recognizing that we didn’t have to land at our destination, we decided to fly. Enroute, the winds just cause turbulence. Since we’re both familiar with flying in bouncy air and don’t have potentially quesey passengers, this wasn’t an issue. Actually, it was a benefit since it got me practice flying IFR in bumps.

The cold front had passed, and the weather was trending smoother. But that trend was slow and wouldn’t happen soon enough to affect our flight. So, takeoff and landing was the key issue. Our home airport was reasonably well aligned with the winds for a 5-7 kt crosswind component on departure.

I once memorized the table of sines for each ten degree increment. (The trigonometric sine of the wind angle to the runway times the wind speed is the speed of the cross wind component. The cosine gives the headwind/tailwind component.) But I don’t use that now. Instead a rough approximation is close enough: 1/3, 1/2, 3/4, or full for the angles 20, 30, 45, or 60 degrees and over.

The plan for today is the NDB approach at KCJR (Culpepper). R was playing Potomac Approach giving me my headings and altitudes as the controller would do. He took me around the class bravo and eventually gave me direct Casanova VOR the to the approach. CSN VOR was a transition to the approach and the missed approach holding fix as well. The NDB approach to Culpepper does not have the NDB on field, instead it is 4.4 miles before the field. So, the approach would go from CSN to MSQ (the NDB), then outbound for the procedure turn, then back inbound to the NDB again. I would pass the NDB for a second time, then continue outbound from the NDB to the airport.

I expect this will keep me occupied.

During the first approach I was behind most of the time. The ADF needle points directly to the NDB station, if I’m flying with a 20 degree adjustment to my course for a crosswind correction, I need to “adjust” the reading of the NDB in my mind correspondingly. My actual heading is my magnetic course plus or minus my crosswind correction. Outbound from to the airport I will need a right crosswind correction, inbound I’ll need a left correction. Determining the correct NDB reading is taking up way too much of my brain cells. So, I was behind. Two weeks off didn’t help.

I had brain freeze on my minimum altitude and my heading corrections. R talked me through it. One good thing: At least I remembered to start my timer crossing the NDB for the second time on our way to the airport. That time is the only way to find the missed approach point for this approach.

Finally, at the missed approach time and the right altitude (thanks to R), I looked up and took the foggles off. Wonder of wonders, the runway was more or less where it should be. I’d previously got the winds as 350 at 8 kts gusting to 18, with this runway heading that 8 gusting to 18 was the full crosswind component. I made the landing, using the crosswind skills I picked up at the crosswind simulator last year.

After landing on the centerline and coasting to taxi speed on the runway (R saying, “stay off the breaks, no need to use tire rubber if you don’t have to”), I pulled off. R praised my crosswind landing and he taxied back for takeoff and praised my crosswind landing as we talked out the approach.

R tells me, “It’s easier to use 30 degrees or 45 degrees correction on the NBD, you need to keep it simpler for yourself. Don’t make work. But inside the final approach fix, you can’t use that much. Keep it smooth, and even. Make small changes, watch your trend.” I wanted to go back and do this approach again, I wanted to get it right.

So, why am I spending effort learning NDBs? After all they’re being decommissioned, there are only two in my area that are still working now. Because first, my plane has an ADF, so I need to know how to use it. Second, if I can fly an NDB approach successfully then I’ve got enough spare brain cells to handle everything else. Third, I want to. It’s fun, in a weird masochistic way. (Yes, I accept that my idea of fun is, uh, different.)

So, we took off, climbed to 2500 and intercepted the NBD outbound again. It went better this time, I was if not ahead of the plane, then roughly abeam it at least. The ADF needle was off a little near breakout, but not very far off. And it had been a bit off the first time too.

But this time when I took off the foggles, the runway wasn’t in front of me, it was about 40 degress to the left. “Jesus!” was my comment.

R said, “I’m glad this happened. First, it tells me you’re not cheating (looking below the foggles). Second NDB approaches aren’t very accurate. This teaches you that you have to look all around when you break out on an NDB approach.”

“So that’s why the minimums are so high for an NBD approach, I’d have to circle to land now.” I said.

R asked, “What are the circling minimums?” I looked, they were the same as the NDB minimums.

We headed back home. R continued to play Potomac approach for me, and he found some covers for the instruments. I promptly “lost” my heading indicator and reverted to my compass in rough air. Ok, I remember how to do this, but for some reason I can’t seem to remember that a standard-rate turn is 3 degrees/second, or 3 seconds for ten degrees. So, when he asks how long do I turn, I made sounds, but no useful speech comes out. R ignores that and tells me. Duh, I remember now.

I keep thinking UNOS: Undershoot North, Overshoot South for the compass turning errors. And getting mixed up as the compass is numbered backward (we see the backside of the aviation compass, so the numbers go the “wrong” way). I should have this down by now! Something else to practice on my X-Plane simulator software.

R takes me up toward home. I’m thinking he’s gradually turning me to the airport, but he’s not. At some point he puts a scenario forth: Something’s gone wrong and I need to find the nearest airport and land there. So, I push the “nearest” button on the GPS, and it gives me a 138 degree heading. This can’t be right. I’m on a heading 060 degrees to home! This GPS heading sends me away from home, something’s wrong.

After dithering, and some prodding from R, I turn to the now 140 degree heading and he has me take off my foggles after a bit. The airport’s ahead. The “something wrong” was not the GPS of course, it was my idea of where we were. I’d lost my situation awareness in all the compass heading stuff.

So, a good lesson. I got some rust off, became more confident on using NBDs, albeit not highly proficient. And I got a very good lesson on trusting my instruments - including my GPS. And, my landing at home was in a 6 kt to 12 kt crosswind. I still have my crosswind chops.

Next up: proficiency check flight with a VOR, ILS, and GPS approach. Then, on to cross-country flights.

Ten Lines of Working Code per Day per Programmer

Saturday, May 16th, 2009

The title is an old rule of thumb for the volume of work a team is capable of. Of course, each programmer would write more that than per day, but after debugging and corrections this would be the net result.

There are other studies that say that the difference in productivity between an average programmer and an expert programmer can be very large: tenfold or greater. And expert is one with ten years or more experience AND who has kept up in the field.

I’m hoping that’s true. I have two weeks to write around 1500-2000 lines of working code. Ignoring weekends, the rule of thumb means I can get 140 lines working in that time.

But I’ve been writing software since 1984 more or less. (I actually learned programming four or more years earlier, that was first in assembler then Basic.) So I hope I’m an expert now, I will need to be one for the next two weeks at least.

Fear, Risk, and Airplanes

Thursday, May 14th, 2009

We are at home with the familiar.  Even when the familiar is risky.  We are more aware of risk with the exotic, even when the exotic is relatively safe.

There are some things I think I’ve figured out.  First, nothing is completely safe. Second, if I try to live my life in perfectly safely then I’ll have a very poor life.  Third, the actual risk is probably controllable to some extent.  And last, the actual risk is probably not what the popular view holds it to be.

Bruce Scheier, in writing about the Virginia Tech shootings, says, “Our brains aren’t very good at probability and risk analysis, especially when it comes to rare occurrences. We tend to exaggerate spectacular, strange and rare events, and downplay ordinary, familiar and common ones.”  Our perception of risk is distorted by familiarity.

I have friends that don’t like to fly.  One has a reason: he flew helicopters in Viet Nam and was shot down.  He’s got a conditioned reflex there that I can understand.  Another prefers driving.  Statistically that’s less safe, but she feels in control even if she isn’t really.

My strategy is to deal with this by education.  In short, find out more information and look at it dispassionately.  Sometime before I actually learned to fly, I read all the NTSB reports for two years for one area of the U.S. and came to a several conclusions.  First, unavoidable situations and catastrophic mid-air accidents are quite rare.  Second, around 2/3s of the accidents I read had two things in common: flight into weather the pilot or plane was not equipped for, or running out of gas.  There’s also a category of just stupid pilot tricks like exceeding speeds that an airplane is capable of, or getting too slow and stalling at low altitude.

Those are controllable.  If I eliminated those dumb moves, checked my fuel tanks, and was careful with weather I was actually safer than driving.  After all, in driving I’m moving fast perhaps only 8 feet away from someone who’s reading a newspaper or talking on their cellphone and gesturing with both hands.  (Yes I’ve seen both, a number of times.)  So in learning to fly and since I’ve made it a habit to always check fuel, to only trust the fuel gauges when I’ve verified the tanks.  I’ve also made weather a strong interest.

Accidents of all sorts, not just in aviation, have a characteristic that usually several things have to go wrong.  Accidents are a chain of events that all have to happen correctly (or incorrectly) to cause the problem.  If the chain is broken, there might be a “close call”, but no accident.  Another analogy I like is the “swiss cheese” model.  The holes in the layer of swiss cheese have to line up just right to let an accident through.

The aviation system is built with margins and backups to make that chain longer and keep at least one link from breaking.  But, accidents still do happen.  It is a fact of life that humans make mistakes.  It is a personal effort to improve and avoid mistakes, not something that can be legislated.  There are people who fly all their lives and have never had an accident.  I strive to be one of those.  More that than, I am planning and training and making that personal effort to be one of those.

But on a level of our whole society. if we are to accept a technology into our lives, we must accept that there will be, unfortunately, an accident.  No matter how safe we try to be. If we use gasoline, fires will happen.  If we have guns, shootings will happen, if we have cars, car accidents will happen, and so on.  If we accept a technology, we accept its consequences wether we know we’re doing that or not.

That is not to say that we should just accept our fates and have accidents, but we should accept that we will never get rid of all accidents.  We should strive for safety and work for it.  But the modern tendency to want to be perfect safe is not only unrealistic but probably undesirable.

Risk, a calculated and careful kind of risk, is the only way to move forward.  If we never risk, we never try anything new.  We can only learn new ideas and facts by trying new things.

Cap and Trade: Using Markets as a Tool

Wednesday, May 13th, 2009

Quick: What are the basic outlines of a cap-and-trade approach? Or, more generally, what is cap-and-trade supposed to affect?

If you, my readers, are typical, about 75% of you don’t really know. The other 25% can correctly say that it is intended to control carbon emissions. The Rasmussen Reports gives this statistic about people in the US at least.

More generally cap-and-trade systems are used to control pollutants. The idea is that there’s a legal cap on what the total pollutant can be emitted into the environment. That total gets divided up by the companies in that industry that emit that pollutant somehow more or less equitably. (Or based on who spent the most on lobbyists.) Then this cap is lowered over time.

That’s the “cap” part. The “trade” part is that a company that wants to emit more pollutant can buy the right to emit that amount from another company that isn’t using its full allocation. A new market is created for the “right to emit” the pollutant. Then, Adam Smith’s invisible hand of the market that the free market enthusiasts are so vocal about comes into play.

The problem with dumping pollutants into the air, rivers, and lakes is that this doesn’t really cost the companies that do the dumping. It affects all of us and costs us in health and cleanup costs, but isn’t captured in the market price of what the companies produce. Therefore there is no incentive to stop pollution. This is one of those “market externalities” I’ve written about before.

A cap-and-trade system neatly takes that market externality and internalizes it. This is a wonderful use of market economics and human nature.

In some circles there is currently criticism of capitalism, or market economies. The idea of an economic market is just a tool. The tool isn’t at fault, instead it is our fault for not using the tool correctly. Cap-and-trade can be (depending on its implementation) a good use of this tool.

I think of this general approach as an engineering design approach to economics. Thus neatly putting together an vocation and avocation.