Archives for the Month of September, 2008

Solo Long Cross-Country

One of the biggest accomplishments in getting your private pilot's license is the "Solo Long Cross-Country." It marks the home-stretch of a lot of training, practice maneuvres, landing drills, and solo flights of increasing complexity.

This flight is where it all comes together: 150 nautical miles total, landing at a minimum of 3 airports, with one leg at least 50 nautical miles.

I planned this flight as a tour of the San Juans and airports I have never been. It took me from Renton (RNT,) to Skagit Regional (BVS,) through Orcas Island (ORS,) Friday Harbor (FHR,) Sequim Valley (W28,) and then finally back to Renton.

image

Cross-country flights all begin with flight planning, and plenty of it.

Once you've drawn your intended route on the sectional chart (making sure to avoid those pesky restricted areas and military operation areas,) you identify (and plan for) checkpoints that fall every 30 miles or so. For each leg of your journey, you calculate the true direction and distance between each checkpoint. You factor in the magnetic deviation for the area (roughly -18 degrees for most of Western Washington,) and then account for the current atmospheric winds. This gives you a magnetic heading by which you can navigate. Add in the distances and estimated ground speed, and you get a navigation method known as "Dead Reckoning."

Dead Reckoning isn't usually the primary form of navigation, however. The modern aviation world is filled with navigation beacons that help you travel along specific paths from beacon to beacon. These are known as VOR Radials. During your preparations, you identify helpful VOR radials and frequencies, and then account for them in your flight plan.

Finally, you research the airports you plan to land at (and some that you don't) for the communication frequencies, runway information, and traffic patterns. Once you've done all that, a completed flight plan looks something like this:

solo_long_xc_flightplan

I had originally planned to leave at 9:00 AM on Saturday, but low clouds kept me hampered in for the better part of the morning. Even once the clouds had lifted at Renton, the Orcas Islands were still covered by fairly low cloud.

Once the clouds finally lifted, I departed to the north. I had originally planned use one of Paine Field's VOR radials for much of my journey, but fly over their airspace as to not interfere with traffic there. Clouds kept me below the 4500 feet that I would have needed, so I called Paine Field and got clearance to transition over the field. I followed the radial to Skagit Regional airport, notched up my first landing of the day, and checked off the requirement for a leg of 50+ nautical miles.

image

The next checkpoint was Orcas Island. I had originally planned to enter the airport from the north of the island, but the weather favoured a northerly landing. I circled, and instead entered the harbour from the south -- easily the prettiest approach of the day.

image

P1010092 P1010096

The landing went smoothly, so I departed and headed to my next destination. Here's a picture of the Orcas Island airport as you leave:

P1010097

The next landing was at Friday Harbor, a runway I had heard was slightly challenging due to its slope. It proved to be uneventful, so I parked in transient parking and made my way down to the harbour for lunch.

image P1010099

I found a great place right on the harbour -- Downriggers -- and enjoyed an awesome grilled crab and cheese sandwitch. It was also the most expensive meal I had ever had. The bill wasn't so bad, but the commute sure was a killer 🙂

P1010106 P1010100 P1010104

After leaving Friday Harbor, I climbed to 5,500 ft to fly across the largest span of the journey. Climbing to 5,500 feet gives a glide distance of about 15 nautical miles -- enough to safely make it back to shore should the engine fail part-way.

Once I f
ound Sequim, I got to enjoy my most challenging landing ever. Sequim Valley airport is 40 feet wide, much thinner than the 100-150 feet most regional airports offer. My initial pass at the traffic pattern was much too tight, so I spaced myself again and landed well on the second attempt.

image

After a short-field takeoff from Sequim Valley, I hugged the coast to avoid a small chunk of prohibited airspace over the Navy's submarine base at Bangor, Washington. I followed that path until I hit my planned VOR radial for the SeaTac airport, and followed that toward Vashon Island.

image

As you approach Vashon Island, SeaTac airport becomes quickly evident, as does downtown Seattle.

P1010111P1010112 

P1010113

In the left picture, Seattle's Control Tower is about 25% from the left of the picture, about half-way down. Seattle's runways are nearly perpendicular to you at this point.

As you approach Vashon, you contact Seattle Tower to request a transition across their airspace. Transition across this class of airspace is much more restrictive, since it handles such heavy traffic. They give you an exact altitude to fly (usually 1500 feet,) and ask you to cross over the approach-end of the runway. As you cross the runways, you'll continue to see large commercial jets land below you. Since they are landing, you still have 1/4 mile of vertical separation between you. A typical crossing looks like this. It's amazing how simple and clean it looks when you're not battling lineups, security, and crowds.

P1010114

After crossing the Seattle airspace, you get told to head toward downtown Kent. After a short while, they release you from their radar service, and it's back to landing at Renton. At the end of a 4-hour flight, I had no clue what was in store for me.

image

After transitioning through the SeaTac airspace and getting to downtown Kent, I called Renton with my intention to land. They told me to come straight-in for runway 33 (basically North,) and that I was clear to land. They asked me to report when I was 2 miles from the end of the runway. As I reported, they said that I was #3, clear to land. I had not heard anybody else talking with the tower or being cleared to land, so I clarified "#3 clear to land?" A second controller corrected that I was #2 clear to land. Still not a surprise you want to get on your final approach. They told me I had traffic at 12:00 on (obviously short) final approach, which I found.

At this point, I’m making the final adjustments, adding the final notch of flaps, watching airspeed, and we’re about 1 mile out.

As I get closer, the traffic ahead of me still hasn’t landed, and still hasn’t started rolling down the runway. In fact, they appear to be stationary on the end of the runway, and at this point I thought I might have lost the original traffic and was instead watching somebody who had stumbled onto the runway in the midst of an incursion. After reflection, I now think that we were on exactly the same glide-slope – causing little-to-no relative movement between us.

As I was now about ½ mile from the threshold (later confirmed by my GPS log,) this was much too close for comfort. I told the tower that we were too close, and started to make a tight spacing turn. The tower got upset, and said that they only had to give 3500 feet of spacing (although ½ mile is 2600 feet by my calculations.) He had somebody on downwind (parallel the runway, about 1 mile east of it, heading toward me) make a left turn for safety, as I did the same. We both saw each other, and fortunately had plenty of room between us. My diversion to the right, and the left turn after that are the first crags in the bottom part of the graphic below:

image

He then told me to not turn at all, and started to lose control as I complied. These directions left me heading toward the right, so he finally yelled, "What do YOU want to do?" to which I said that I would be doing a "go around" toward the east channel (the upper-right body of water.) After doing that, I entered the traffic pattern like usual (the loop right, and downward,) and then landed uneventfully.

All-in-all, several errors compounded themselves, but it seems to have started with ATC trying to sequence traffic too tightly together. My initial reaction to do a clearing turn was was stupid of me, and was my first Pilot Error. I have no qualms about the decision I made, but do regret the way I decided to do it. I should have just done a go-around – a spacing turn toward the downwind-final direction was dangerous, and easily could have caused problems.

I completed my landing, post-flight checklists, and headed back to base -- completing a huge milestone in my flying journey. Over the next few weeks, I'll be studying like crazy to prepare for the knowledge test and oral grilling that the official flight examiner will give me. Once I feel ready, I'll complete the last 5-or-so hours of practical flying practice and go for my official check ride!

PowerShell 'Suggestion Mode'

One bit of feedback we frequently get is that PowerShell's learning curve has some steeper bumps than we would like. Or simply, is strongly affected by habits learned from other languages or shells.

Interestingly enough, many of these problems aren't new to us -- we just don't have a good way (aside from help) of exposing them to the user. This was something I touched on in the footnotes of a blog in 2005, and started implementing personally shortly after that. Here's an example of its output:

[C:\temp]
PS:14 > "c:\temp\has space\test.ps1"
c:\temp\has space\test.ps1

Suggestion: Did you mean to run the command in quotes?  If so, try using & "<command>"

The core of this is implemented by a script, Get-TrainingSuggestion.ps1. It retrieves the last item from your history, and runs a bunch of regular expression comparisons against it. If it finds a match in the list of training rules, it outputs the suggestion that corresponds to that rule.

############################################################################## 
## Get-TrainingSuggestion.ps1 
## Retrieve a training suggestion (if applicable) for the last command 
## you typed. 
############################################################################## 

$history = get-history -Count 1 

$suggestions = @{ 
   "/\?"="To get help on a topic, use -? instead of /?.`nAlternatively, use get-help <command>."
   ".length"="Try using the .Count property instead of the .Length property.  Although .Length " + 
       "often works, .Count is the more consistent way to get the number of objects in a collection."
   ";[ \t]*$"="Semicolons are not required as line terminators in PowerShell.  Try your command without one."
   "Regex.*]::Match"="PowerShell's -match evaluator is much more efficent than calling it through the .NET API."
   "^`".*`"$"="Did you mean to run the command in quotes?  If so, try using & `"<command>`""
   "start "="Are you trying to run the program associated with that path?  If so, try invoke-item <path>"
   "%.*%"="To access environment variables, try `"`$env:variable`" instead of `"%variable%`""
   "ren[^ ]* [^ ]+ .*:\.*"="Rename-item takes only a name as its second argument.  Unless you want the " + 
       "name to have those path characters, do not include them."
   "dir.*/s.*"="To get a recursive directory listing, try `"dir . * -rec`"."
   "dir.*/ad"="To get a list of directories, try `"dir | where { `$_.PsIsContainer }`"" 
   "^get-childitem.*/s.*$"="To get a recursive directory listing, try `"get-childitem . * -rec`"."
   "^grep"="To search files for text patterns, use the match-string cmdlet."

$helpMatches = "" 

if($history

   $lastCommand = $history.CommandLine 

   ## Get the suggestions from the baked list 
   foreach($key in $suggestions.Keys) 
   { 
    if($lastCommand -match $key
    { 
        $helpMatches += "`nSuggestion: " + $suggestions[$key
    } 
   } 

$helpMatches 

 

To use this, simply update your PROMPT function to call Get-TrainingSuggestion.ps1.

function prompt
{
    $suggestion = Get-TrainingSuggestion
    if($suggestion)
    {
        Write-Host $suggestion
        Write-Host
    }

    "PS >"
}

Admins, Developers, and Constructive Feedback

One tension that sometimes arises in the PowerShell community is between the hard-core developers, and hair-on-fire administrators. As a broad technology, this tension and desire for balance drives our design decisions every day.

PowerShell is all about striking a balance between a range of experiences:

  • Task oriented, and consumption-only. AKA “Copy and Paste Admin.”
    • How do I use PowerShell to restart a computer?
  • Problem oriented, and composition-based. AKA “Admin Scripter.”
    • How do I collect a log file from a cluster of machines I need to parse out of a web page?
  • Technology oriented, and interoperability-focused. AKA “Developer” / ISV
    • How do I expose my product’s transacted object model to PowerShell users?

In general, the output of each category empowers the categories that come before it. As a product becomes PowerShell-enabled, admin scripters can then leverage the cmdlets and providers to solve their problems and scenarios. They might blog them, wrap them in a script or module, or otherwise share them. At that point, they become pre-packaged tasks ready for copy and paste.

We tend to walk a fine line with this goal, but I’ve grouped our 100+ new V2 cmdlets into three buckets: Admin, Developer, and Both. Here is what the comparison looks like right now:

PS >gc newcommands.txt | group { $_.Substring(0,1) }
Count Name                      Group
----- ----                      -----
   75 a                         {a Add-BitsFile, a Add-Module, a Checkpoint
   11 d                         {d Add-Type, d Debug-Process, d Export-Prox
   16 b                         {b Complete-PSTransaction, b ConvertFrom-St

Granted, we’ve spilled more blogging ink on the developer and scripting-oriented features (transactions, modules, eventing, etc,) but that’s largely because it will take some time for our SDK and help documentation to catch up.

In addition, PowerShell’s goal is always to soften the learning curve and blur the distinction between the buckets I mentioned earlier. For example, the scripts and functions you’ve come to know and love now have access to all of the power of compiled cmdlets. Or more simply, some scenarios that used to require .NET scripting (random numbers, split and join, etc) now have task-oriented cmdlets or language features.

Now, what about "constructive feedback?" Frequently, we'll find a blog post or comment saying something along the lines of, "PowerShell just isn't admin-friendly." Or, "PowerShell just isn't developer-friendly." Of course, we're always working to make the product better, but that comment is an ideal spot to help ensure we get this right. The best way to help us is to make your feedback constructive, and something we can act on. Tell us why you feel this way, and it has a chance of improving the product. Aimlessly grumble, and it does not.