Ones and Zeros

Instructor M and I are flying today.  Our task is to practice holding patterns around an NDB and VOR both.  There’s one NDB near here that also has a VOR nearby.  So we head there.

I’ve been diagramming ADF and DGs from the last lesson.  I’ve been reading up on holding patterns, and I think I’m really prepared now.  So, we brief the lesson and go flying.

I track down toward our practice area and our first hold target.  I’m happy with my heading and altitude control.  I’m finding several things;  First, the less I mess with the flight controls, the better my control of the plane.  I’m tending to over control.  Flight is smoother if I emphasis trim and make only small corrections.

Second, if I allow myself 100 foot tolerance on altitude, I’ll use all of it.  But if I allow myself only a 50 foot tolerance, I’ll keep my altitude within 50 feet.  My expectation of what I can do is important.

My hold entry is a direct entry.  But as that’s too easy, M takes control and we go for a short jaunt.  When I have the airplane back and look at the VOR indicator and the DG (Directional Gyro) and promptly go in to brain freeze.

I see a bunch of numbers and can’t make sense of them.  I find the heading for the VOR and turn to it.  But I have no idea how to enter a hold or where to head in the hold.  Or as the Three Stooges said, “I’m tryin’ to think but nothin’s happening!”  I’m not nearly as prepared as I thought I was.

M talks me into the hold while I reboot my neurons.  Once I’m in the hold I get the picture and I follow the hold.  Not smoothly, but I can follow it.  We follow it around again, then head to the NDB.

We do a hold at the NDB too, M talks me into this as well.  I follow it outbound and do the procedure turn, then back to the NDB.

We head home with a chastened pilot flying.  In our debrief we review the VOR entries again.  And plan the next lesson on the school’s flight sim.  And, I plan my own flight sim at home too.

I wanted to practice instrument flying more, but didn’t want to use the plane (and instructor).  They’re essential, but expensive.  I can practice at home; that means a simulator.  My wife and I run a Linux/MacOSX household, so MS Flight Sim was out.  Besides Microsoft just laid off the Flight Sim developers.  So X-Plane it is.

But the latest version of X-Plane uses 70 GBytes, mostly for scenery files.  I had 4 GBytes free.  That meant a new disk as well as the software and the controls.

After researching it, I ordered the new disk from MCETech.com.  The disk came reasonably promptly, but the installation instructions weren’t included– despite their website saying they were.  My first call resulted in one of their folks trying to email the docs.  But I never received them as they were too big for email.

On my second call the tech pointed me to websites with some instructions on them and assured me that the instructions were also on the disk.  The websites were useful, but the disk was not formatted so there was nothing on it.  The tech also suggested a particular disk copy program too.

The websites were handy, but of course to read them required another computer while I had mine taken apart (there were many pages with lots of pictures).  I pointed that out to MCETech, also pointed out that they had a website with an “installation instructions” section that lacked these installation instructions.

In the end the physical replacement of the disk was straightforward.  I probably could have done this without the instructions as I’m reasonably handy.  But for my main computer I wanted assurance.  (I have precision screwdrivers in torx and phillips both.  You’ll need them if you do this.) I got the system back tother and booted from my MacOSX installation DVD.  I would rather copy the disk before I installed it, but that’s not how this worked.

I connected my old disk in the enclosure provided and ran the disk copy program suggested.  And got a new set of problems.  Twice this program just halted.  The “time used” clock didn’t increment, and the disk busy light on the old disk (now my external) was locked on.  No activity was happening.

The third time was the charm and I was able to get the disk copied successfully.  But the next time I have to do this I expect to look elsewhere.  I’m not happy with MCETech or with that third-party software either.

And remember the X-Plane flight sim?  That’s how all this started.  Well, I still don’t have the controls yet.  But I do have disk space now!  And the controls will be here soon.

There are basically two kinds of navigational beacons used for aviation: NDBs (non-directional beacons) and VORs (VHF Omni-Range beacons). The former are the older type of beacon. An automatic direction finder (ADF) indicator gauge in the plane has a needle that just points directly to the beacon. If I’m crabbing into the wind so I can track a straight course line over the ground, the needle still points to the beacon which is now not on my nose anymore. So it shows all my cross-wind adjustments.

Many planes don’t have an ADF (see the box with three knobs on the right) anymore since many of the NDBs nationwide have been decommissioned, including many in my area. Mine plane has an ADF, and it works. So when I take my IFR examination I’ll have to demonstrate working with an NDB.

Today we’re flying to an available local NDB, it is inside the SFRA (ADIZ) so I’ll have to file specially for that. We’re not going to land at that airport, so I put “IFR airwork” in the flight plan. This causes some confusion later with ATC, I should have just put “airwork”.

I’m flying with instructor R today. He briefs the lesson and it all seems so straightforward right now, here on the ground with no turbulence and no plane to fly. My job as a pilot with NDBs is to maintain the necessary heading to or from that beacon. In a crosswind I need to adjust for the wind direction by angling the plane toward the wind somewhat. This means that the ADF pointer will point away from my heading by the amount I have to angle the plane. That amount is determined by the wind’s strength, it’s direction and my speed.

If I keep the ADF pointer straight ahead, but the directional gyro (DG) keeps turning then I’m homing in on the beacon by following an arc to the beacon. I’m not tracking a straight course over the ground. I have to keep the directional gyro straight, and the ADF steady too. But in the presence of wind, the ADF will point to the side by the amount of my wind correction.

Once R and I are in the plane and I’m tracking toward the NDB this all becomes harder. I’m still having to keep the plane straight and upright by instruments alone (my view below). And we’re getting bounced around a bit. Our plan is to fly the approach course, then do the missed approach turn and follow the approach course away from the NDB, then do the procedure turn and follow the approach course again. All this is meant to be at the same altitude, we’re not doing the vertical descent part of the approach or the climb of the missed.

Meanwhile, Potomac ATC wants to know what we’re doing and to help us, we need to contact CTAF at the airport near the NDB so the other traffic there knows what we’re doing too.

With R’s help this all works. He has mercy on me and handles most of the radio calls. He has me peek out under my foggles to see the airport just below us. But the numbers and headings are hard work for me. I’m using too many neurons just flying to make the rest of it smooth. And since this is my first time with it I don’t have enough practice to make this automatic.

Three times around; follow the course inbound, follow the missed approach procedure to turn to the outbound course, then after a one minute count, turn right 45 degrees to prepare for the procedure turn. Then turn 180 degrees and re-intercept the course inbound again.

R seems satisfied enough at the end. I feel beat up. I’ve got to get this more automatic. R recommends working out scenarios on paper with the DG and ADF. I plan to do so. I also plan to try this out on my planned X-Plane flight sim at home too.

First, happy square root day!  And do you have your plans set for pi day?

At work we had a problem with accessing the internet today.  Our IT person - a sharp guy - had found that it wasn’t an outside problem, but one on our own internal network.  His conclusion is that had two devices on one IP address.  Unfortunately that address was the main gateway address so some of the packets that should leave our network for the internet were not doing so.

We’re a small company, we don’t really have any network monitoring.  And our “smart switches” are well, short a few chips from “smart”.  So the only way to track that device down is the painful step of unplugging each wire from the main switches, testing, the trying the next one.  Doing a binary search is better, but still painful.

But I worked out a way to find the problem device.  I used ARP and the ARP cache along with the “ping” command to find it.  First, some background.

When you use the network, even for a simple ping command, your computer first has to find where to send those data packets.  On ethernet-based networks the real network address is an ethernet address, each then has an IP address assigned to it as well.  At the actual network level though, all the data packets are addressed with ethernet addresses.

But the higher level software (your email or web browser for example) wants to send packets to an IP (Internet Protocol) address.  It’s called an internet protocol since it connects multiple networks.  That “www.google.com” URL is translated to an IP address to be used in your browser software.

So how does your computer knows which ethernet address to use when all the software has are IP addresses?  The ARP - address resolution protocol - does the trick.  Your computer sends out an ARP broadcast packet that says “who is assigned the IP address xx.yy.zz.aa?”.  The reply is from the device that has that IP address and your computer uses that reply’s ethernet address to send the packet to.  Of course this address may be the gateway from your ethernet to another network where it would eventually get forwarded to google in my above example.

It hit me I could use ethernet and ARP to figure out the problem device.  I cleared the ARP cache in my machine, and pinged the problem IP address we had.  This forced that ARP broadcast.  Then I dumped the ARP cache and found the ethernet address of the problem machine.  I looked up the vendor code (the first three bytes of the ethernet address) in the IEEE listing.  We run a mixed shop and fortunately there weren’t many machines of this type.  I was able to examine a short list of machines of that type and found the problem machine.

Oh, and the actual problem?  An inadvertent misconfiguration of a proxy on that system duplicated the gateway’s IP address.  Nicely solved once we found that figured out that a proxy was on that system.