Flight planning spreadsheet

[Roger Long]

I'm working on an Excel spreadsheet to do flight planning using formulas
from Ed Williams site:

http://williams.best.vwh.net/avform.htm

Basically, it will duplicate what I used to do with an E6B and a paper form.

The log is set up so that all the information needed in flight is on one
half of an 8 1/2 x 11 sheet with the input data on the other half. You can
then fold it in half and have the rest of a clipboard size kneeboard
available for other stuff.

I like putting in the distance, course data, etc. well ahead of time and
then plugging in the weather information just before I go. Driving the
Sporty's E6B through it all is just too much work now that I'm no longer a
student and don't have to show my work to anyone. This spreadsheet should
make it easier.

(Yeah, I know there are all sorts of flight planners out there but I'm a
tightwad. Besides, I like simple, homebrew stuff that I can set up the way
I want.)

I've got good agreement between the spreadsheet and the E6B on heading but a
few percent disagreement on ground speed. I haven't done a complete hand
verification yet but the spreadsheet actually looks more accurate. When
there is an exact headwind, the spreadsheet give the right answer while the
E6B is off a couple knots. Does the Sporty's E6B use some approximations?

If anyone who is a wiz with formulas and Excel would like to take a look at
this, I'd appreciate it. Anyone who wants, to play with it, further develop
it, use it, whatever, feel free to download the in-progress file at:

http://home.maine.rr.com/rlma/Flightplan.xls

Strictly as-is, use at own risk, public domain. Just let me know if you
have any corrections, ideas, or comments.

--
Roger Long

[Casey Wilson]

>
> I like putting in the distance, course data, etc. well ahead of time and
> then plugging in the weather information just before I go. Driving the
> Sporty's E6B through it all is just too much work now that I'm no longer a
> student and don't have to show my work to anyone. This spreadsheet should
> make it easier.

I'm not trying to throw cold water on your work but I guess I don't see
any advantage, Roger. Are you going to lug a laptop into the airplane to
work the spreadsheet? You mentioned paper folded onto a clipboard. After
you plug in the relevant info, how do you print it out -- copy by pencil?
So, I get this picture.... bags are loaded, preflight is done, now it's
time to call WXBRIEF. Uh oh, the winds at cruise altitude are 65 degrees off
the nose and blowing 22 knots. Later on, just past midway on my
cross-country, a check with flight watch reveals the winds have shifted
around to 20 or so degrees off the nose and picked up 5 knots.
In either of the above cases, a few movements of my whiz-wheel will
tell me: (1) the mag course to follow to correct for the cross-wind to hold
track, (2) the headwind(or tailwind) component and its affect on my ground
speed, and (3) the change in fuel consumption. By reverse logic, I can use
the whiz-wheel to estimate unknown wind directions and velocities
I do my planning on the "Flight Planner" sheets provided by AOPA Air
Safety Foundation. In addition to being handy for keeping all the
information organized, it is a great memory tickler for getting all the
information -- a flight planning checklist, so to speak.
I saw a favorably impressive demonstration of an electronic gizmo, like
Sporty's E6B. If it weren't for batteries and LCD screen, I'd probably have
one. For now, I use the calculator functions of the KLN-89B in the panel to
back up my whiz-wheel.
Do it the way it works best for you, Roger. What makes you warm and
fuzzy makes flying the best.

Regards,

Casey

[Roger Long]

Ah, I smell a philosophical difference. Since I'm not flying over trackless
wastes, have Loran, GPS, VOR's, finger on the sectional, etc., the plan is
just that, a plan. Like a battle plan, it starts to degrade at first
contact with reality.

The purpose of the spreadsheet is to give me the best prediction of fuel
burn, arrival times, and initial headings that can be generated a couple
hours before leaving for the airport. The probability that conditions will
change significantly is fairly low. Even lower is the probability that the
conditions I encounter will exactly match the forecasts. Although the plan
is a valuable guide to the flight and rough reality check on in-flight
calculations, it's really more of a "Pick me up at the airport at ____" tool
than a "where am I now" tool.

If I get a final briefing and find out that the winds are say 10% stronger
and have veered 30 degrees, I probably wouldn't rework the whole thing but
just make top of the head adjustments to the numbers. Initial headings are
just a convenience to help me settle down on the electric box's "Direct to"
pointer. Similarly, if I start running ahead or behind of my times to
waypoints, I'll just project ahead a similar approximate correction.

The spreadsheet is not a substitute for the Wiz Wheel or Electronic E6B. If
there is a significant change, say a 10 knot tailwind swinging around to a
25 knot headwind, I might sit down and rework the whole thing by hand with
the blank sheets I carry in my flight bag. More likely, in that case, I'll
be worried about the time, just make an overall correction, and interpolate
the rest as I go along. The plan, even though based on different wind
assumptions, still makes those gut estimates easier. Since I don't have a
$1000 headset or Oregon Aero seats, I don't fly very deep into my fuel
reserves anyway.

I have yet to find a reason to fiddle with the E6B in flight. There are too
many other ways to get the same answers while keeping eyes outside the
cockpit. Set your heading without wind correction, pick a landmark on the
horizon, then pick one closer. Crab until they stay in line, then hold that
course. Fly 10% of the distance to a waypoint and time it, now you know
your arrival ETA.

The most important VFR flight instrument is still the sectional on the lap
and the fingernail. When the GPS blips off, or the panel goes dark, that's
what will get you down safely.

--
Roger Long

[Roger Long]

There are still significant errors in ground speed. I'm trying to figure
out why.
--
Roger Long

[Brent Bigler]

You might take a look at how Excel defaults its degrees. I believe you may
have to convert to Radians or something, versus leaving everything in
regular ol' compass degrees.

--Brent

"Roger Long" m> wrote in
message ...
> There are still significant errors in ground speed. I'm trying to figure
> out why.
> --
> Roger Long
>
>
>

[Roger Long]

Got it! Damn parentheses. What a difference a ( ) makes.

The corrected spreadsheet is at the original link:

http://home.maine.rr.com/rlma/Flightplan.xls

--
Roger Long

[Casey Wilson]

"Roger Long" m> wrote in
message ...
> Ah, I smell a philosophical difference. Since I'm not flying over
trackless
> wastes, have Loran, GPS, VOR's, finger on the sectional, etc., the plan is
> just that, a plan. Like a battle plan, it starts to degrade at first
> contact with reality.
>
> The purpose of the spreadsheet is to give me the best prediction of fuel
> burn, arrival times, and initial headings that can be generated a couple
> hours before leaving for the airport. The probability that conditions
will
> change significantly is fairly low. Even lower is the probability that
the
..
..
We are on the same page, so to speak, even with minor philosophical
differences. I guess I'm seeing you doing the reinventing/replowing/(other
metaphors) thing. What's wrong with the free service from DUATS? It
doesn't look like an Excell page, but like the Ragu commercial says: "It's
all in there."
Perhaps the problem is I begrudge using my time that way. With that
aside, I volunteer to beta-test the spreadsheet should you ask.

Regards,

Casey

[Roger Halstead]

On Tue, 05 Aug 2003 20:14:25 GMT, "Brent Bigler" >
wrote:

>You might take a look at how Excel defaults its degrees. I believe you may
>have to convert to Radians or something, versus leaving everything in
>regular ol' compass degrees.

To quote Excel Help:

SIN(number)

Number is the angle in radians for which you want the sine.

Remark

If your argument is in degrees, multiply it by PI()/180 or use the
RADIANS function to convert it to radians.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)


>
>--Brent
>
>"Roger Long" m> wrote in
>message ...
>> There are still significant errors in ground speed. I'm trying to figure
>> out why.
>> --
>> Roger Long
>>
>>
>>
>

[D MANN]

Looks OK Roger, but how do I download it to my Excel?. I can use it
alright in explorer but cant save it to my own disk. ( was I meant to be
allowed to do that?) Explorer crashes in the process of trying.

And I figured the column headed CRS is the magnetic track, but what do the
letters CRS stand for ( sorry if its obvious - I'm an Aussie and my
American isnt as good as it should be).

Eventually figured out the pressure height also, when I realised what the
29.92 was. Cant help wondering whos got the job of changing all the
Cessna and Piper altimeter subsetting to mbars for us Aussies , or do they
do that at the factory in the States?
Dont know why we bother to be honest, if we can work in feet instead of
meters we should be able to handle the inches of mercury.

Regards

Terry



"Roger Long" m> wrote in
message ...
>
>
> Got it! Damn parentheses. What a difference a ( ) makes.
>
> The corrected spreadsheet is at the original link:
>
> http://home.maine.rr.com/rlma/Flightplan.xls
>
> --
> Roger Long
>
>

[L Smith]

Roger Long wrote:

>Got it! Damn parentheses. What a difference a ( ) makes.
>
>
For me, one of the biggest pains in programming, and the cause of more
bugs and
other problems than anything else, is trying to get my parentheses in
the right places.
I've recently had the "opportunity" to work with the Scheme programming
language.
What's one of the key structural elements of its syntax? Parentheses!

Talk about a user-unfriendly language.

Rich Lemert

[John Clonts]

"L Smith" > wrote in message
...
> Roger Long wrote:
>
> >Got it! Damn parentheses. What a difference a ( ) makes.
> >
> >
> For me, one of the biggest pains in programming, and the cause of more
> bugs and
> other problems than anything else, is trying to get my parentheses in
> the right places.
> I've recently had the "opportunity" to work with the Scheme programming
> language.
> What's one of the key structural elements of its syntax? Parentheses!
>
> Talk about a user-unfriendly language.
>

Yes, it is a big problem-- that is, until you're mind is sufficiently
expanded that you look at software in a whole new way and the parenthesis
"dissolve" into the background. It's almost a kind of a "magic-eye" sort of
thing, IYSWIM. Good luck, hope you eventually "get it" :)

Cheers,
John Clonts
Temple, Texas

[Drew Hamilton]

Paul Tomblin > wrote:
>If you use a modern user friendly editor like "vi", you can just hit "%"
>and it will take you to the matching paren, so you can see if they match
>up correctly.

Be careful, the only thing worse than the high wing-low wing debate is the
vi-emacs debate.

- awh

(vi forever!)

[leslie]

Drew Hamilton ) wrote:
: Paul Tomblin > wrote:
: >If you use a modern user friendly editor like "vi", you can just hit "%"
: >and it will take you to the matching paren, so you can see if they match
: >up correctly.
:
: Be careful, the only thing worse than the high wing-low wing debate is the
: vi-emacs debate.
:
: - awh
:
: (vi forever!)
:

Or vi vs. VMS' edt debate, or unix vs. VMS.

--Jerry Leslie (my opinions are strictly my own)
Note: is invalid for email

[Andrew Gideon]

John Clonts wrote:

>
> Yes, it is a big problem-- that is, until you're mind is sufficiently
> expanded that you look at software in a whole new way and the parenthesis
> "dissolve" into the background. It's almost a kind of a "magic-eye" sort
> of
> thing, IYSWIM. Good luck, hope you eventually "get it" :)

Indentation is your friend.

Actually, this is related to an aviation topic: CRM. Why do some pilots
highlight their route on a chart? Because this makes it far easier for the
human eye to locate the route when first looking (back at) the chart.
Absent this, various forms of mental processing are required. This takes
time and effort.

In programming, we've the same opportunity to do things in a way that
reduces the need to "think" over trivia. Indentation is one good example.
Whether you're programming in a C derivative (in which case you must match
braces), a LIST derivative (parens), a language with BEGINs and ENDs, or
anything else, doing this "matching" involves work. Proper indentation
makes this much easier, as a lexical block is made visually "obvious".

It's the equivilent of highlighting the route.

Most modern editors will indent automatically, and even using colors or
graphical markers to further enhance the display of the code. Using one of
these is like shifting to the use of a moving map GPS.

- Andrew

[Robert Perkins]

On Thu, 07 Aug 2003 12:53:25 GMT,
(leslie) wrote:

>: Be careful, the only thing worse than the high wing-low wing debate is the
>: vi-emacs debate.

MacWrite forever, man! Peace!

Rob

[Roger Halstead]

On Wed, 06 Aug 2003 22:05:32 -0400, L Smith >
wrote:

>Roger Long wrote:
>
>>Got it! Damn parentheses. What a difference a ( ) makes.

I forget those every once in a while. <:-)), at least in spreadsheets.

>>
>>
> For me, one of the biggest pains in programming, and the cause of more
>bugs and

There is so much math required to become a programmer, I'd think that
using parentheses would become second nature. Prefix, postfix, and
infix.

>other problems than anything else, is trying to get my parentheses in
>the right places.

You should try writing a compiler <:-))

>I've recently had the "opportunity" to work with the Scheme programming
>language.

I've not heard of that, but I've been out of the business for over 5
years now.

>What's one of the key structural elements of its syntax? Parentheses!

Parenthesis is pretty important in most programming languages and in
virtually all math that is done within the programs. It sets the
order in which operations are performed. True the operators such as
+, -, /, *, and ^ have their own precedence, but in the end they all
bow to the parenthesis.

In school we had a few exercises where we had to perform the same math
using prefix, postfix, and infix. Now that got *really* confusing. I
don't think I could do all of them now. Actually that's not true. I
know I couldn't do all of them now. <:-))
Post fix is, I believe the same as RPN and I've never successfully
managed to use a calculator that used RPN.

>
>Talk about a user-unfriendly language.

Try straight C using pointers and dynamic memory allocation. They
call it a write only language for a reason. <:-)) Straight C lets you
do virtually anything with almost no type checking. You can add an
integer to an address, to a pointer, to a piece of text and it won't
complain. More recent compilers let you turn on type checking, or
more correctly they are set up for ANSI C and will allow you to turn
the type checking off if you wish.

Still...Write something in straight C without internal documentation
and then go back six months later and try to follow what you wrote.

It's a relatively elegant language that lets you write very compact
code, unlike the visual counterparts which are very easy to use, but
generate "bloat code".

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)

>
>Rich Lemert

[Roger Halstead]

On Thu, 7 Aug 2003 02:06:11 +0000 (UTC), (Paul
Tomblin) wrote:

>In a previous article, L Smith > said:
>> For me, one of the biggest pains in programming, and the cause of more
>>bugs and
>>other problems than anything else, is trying to get my parentheses in
>>the right places.
>
>If you use a modern user friendly editor like "vi", you can just hit "%"
>and it will take you to the matching paren, so you can see if they match
>up correctly.

Actually any recent incarnation of Excel does that without having to
ask. You just have to watch what it's telling you.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)

[Roger Halstead]

On Thu, 7 Aug 2003 08:03:45 -0400, Drew Hamilton > wrote:

>Paul Tomblin > wrote:
>>If you use a modern user friendly editor like "vi", you can just hit "%"
>>and it will take you to the matching paren, so you can see if they match
>>up correctly.
>
>Be careful, the only thing worse than the high wing-low wing debate is the
>vi-emacs debate.
>
Not to me...I don't like either one of them.<:-)) and haven't had to
be concerned with them for over 5 years..er 6 years. I retired during
Osh, at Osh in 97...Took my last week of work on vacation...and they
still owed me for something like 90 days of vacation(give or take a
couple)

We weren't allowed to carry over more than 10 days from one year to
the next, but they made exceptions for those of us who lived with the
computers. I only had one day off in my first two years back after
college. All those years after I went back to work I carried a pager
even on vacation. They even had me paged over the PA system at
Oshkosh one year.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)

> - awh
>
>(vi forever!)

[Roger Halstead]

On Thu, 07 Aug 2003 23:15:45 -0000,
(journeyman) wrote:

>On Thu, 07 Aug 2003 20:33:53 GMT, Roger Halstead
> wrote:
>
>>>other problems than anything else, is trying to get my parentheses in
>>>the right places.
>>
>>You should try writing a compiler <:-))
>
>I have. It's really not that complicated. Just a bunch of basic data
>structures.
>
>
>>>I've recently had the "opportunity" to work with the Scheme programming
>>>language.
>>
>>I've not heard of that, but I've been out of the business for over 5
>>years now.
>
>Lisp dialect. Lots of Irritating Spurious Parentheses. Been around
>much longer than 5 years.
>
>
>>Post fix is, I believe the same as RPN and I've never successfully
>>managed to use a calculator that used RPN.
>
>I remember doing planning for a solo cross-country, using my HP
>calculator to crunch the numbers for W&B. My instructor's eyes glazed
>over.
>
>
>>>Talk about a user-unfriendly language.
>>
>>Try straight C using pointers and dynamic memory allocation. They
>>call it a write only language for a reason. <:-)) Straight C lets you
>
>C is a friendly language. It's just picky about whom it calls its
>friends.
>
It's Powerful, elegant, and relatively simple in its structure. It's
relatively easy for one who has studied it to write some very powerful
programs, but without thorough documentation I don't think I'd ever
call it friendly. <:-))

I've seen code that students turned in where it took more work to
decipher than it did to write it. Course I saw a few students who
could write Pascal that way too and it's almost a plain language when
it comes to source code.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)
>
>Morris

[Andrew Gideon]

Roger Halstead wrote:

> I've seen code that students turned in where it took more work to
> decipher than it did to write it. Course I saw a few students who
> could write Pascal that way too and it's almost a plain language when
> it comes to source code.

Please help.

You've the perfect opportunity to teach that code is almost universally read
more than it is written. More, the reader is typically unfamiliar with the
code being read - even if it's the author, but a few days or weeks or
months or years downstream.

This should motivate the writing of code designed not to be written quickly,
but read easily. Avoiding nested returns, keeping logic expressions
simple, commenting, writing short functions...

I taught in a "new hire" program for a number of years at a couple of
investment banks in NYC a while back. Too may (most?) of the people hired
regarded the concept of writing code to be written as foreign.

- Andrew

[Roger Halstead]

On Sun, 10 Aug 2003 10:53:16 -0400, Andrew Gideon
> wrote:

>Roger Halstead wrote:
>
>> I've seen code that students turned in where it took more work to
>> decipher than it did to write it. Course I saw a few students who
>> could write Pascal that way too and it's almost a plain language when
>> it comes to source code.
>
>Please help.

Shouldda had my old instructor in college. You turned in nothing with
out a flow chart (Nazzi Schinerdman?). Then pseudo code, then the
program with plenty of internal documentation.

You might have trouble understanding the code in a few months but with
the internal docs you at least knew what it was supposed to be doing.
<:-))
>
>You've the perfect opportunity to teach that code is almost universally read
>more than it is written. More, the reader is typically unfamiliar with the
>code being read - even if it's the author, but a few days or weeks or
>months or years downstream.
>
When I was working as a Sysadmin, Developmental analyst, and finally
as a project manager I spent a good deal of time rewriting many of the
programs used by our Laboratory Information Management System (LIMS).

One of our people at a different site was a great programmer, except
he would just write as much stuff as he could get on each line and no
documentation. It not only made it difficult to read, but oft times
the code would behave differently. We used a Pascal "like" language
called VGL. It was easy to work with and easy to use. Dynamic memory
allocation and pointers were transparent to the programmer so you
never had to remember "new" and clear". Then again you didn't create
any linked lists.

>This should motivate the writing of code designed not to be written quickly,
>but read easily. Avoiding nested returns, keeping logic expressions
>simple, commenting, writing short functions...

Pretty Printing.
Nested returns and logic need not be obscure. Flow charting *usually*
cures problems with nested returns and logic.

The big kicker is that like writing to make things easier for the
user, writing for readability with internal documentation takes extra
time. Time that can be saved many times over when modifying that
code later on. Unlike writing for ease of use, writing for
readability does not make the program more complicated. OTOH you will
never get some programmers to use structured programming with pretty
printing and internal documentation.

Then again, that extra time may grate on management. When they see a
programmer write code in a day that takes another two or three, they
see efficiency. They don't see the extra weeks work it takes to
decipher the quickly written stuff and modify it later on. With that
kind of code it's often easier to start from scratch.
>
>I taught in a "new hire" program for a number of years at a couple of
>investment banks in NYC a while back. Too may (most?) of the people hired
>regarded the concept of writing code to be written as foreign.

I hold one stance on that, if they aren't trained programmers they
shouldn't be writing code. Programming is "grunt work" and takes a
specific mind set and dedication.

Then you get into larger programs that require team work and
coordination. (I've been a project manager where both hardware and
software were concerned as well as modifying the way a corporation had
to do their networking with FDA validation) They have to write to a
given specification so each programmers part will work with all the
others which is far different than the environment where one person
writes some small programs or routines.

It's much like filing a flight plan. It has to be properly organized
to work in the system.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)

>
> - Andrew

[journeyman]

On Sun, 10 Aug 2003 21:37:58 GMT, Roger Halstead
> wrote:
>
>Shouldda had my old instructor in college. You turned in nothing with
>out a flow chart (Nazzi Schinerdman?). Then pseudo code, then the
>program with plenty of internal documentation.

NS diagrams ("structured flowcharts") never added anything to
structured code. For that matter, neither did conventional flow
charts. They may have had a use once before we settled on the control
structures in use today. IMHO, there's still a pedagogical use for
conventional flow charts to teach the student how the structures work
(i.e. that the condition in a while loop is only evaluated at the
beginning of each iteration).

IMHO, there's no substitute for good naming conventions and comments
that say *why* you're doing something. I can see what you're doing.
Best ever example is the Edison Design Group source code (compiler
front ends). They've turned it into an art form.

In general, reading good code really does help you a better programmer,
almost, but not completely, exactly unlike how talking about flying
makes you a better pilot.


Can we talk about aviation now?


Morris

[Tom S.]

"G.R. Patterson III" > wrote in message
...
>
>
> Roger Halstead wrote:
> >
> > OTOH you will
> > never get some programmers to use structured programming with pretty
> > printing and internal documentation.
>
> We used 100% code reviews by "peers" at my former employer. Those who
didn't
> use structured programming didn't stay long.
>
> > Then again, that extra time may grate on management. When they see a
> > programmer write code in a day that takes another two or three, they
> > see efficiency.

I've seen plenty of C programmers crank out 30KLOC of garbage that had to be
throw away.

>
> Since my former employer was not in the habit of handing the same
assignment
> to several programmers, this never happened. Number of lines of code was
> not a factor in evaluation; what mattered was whether you had completed
> assignments on time, the perceived complexity of those assignments, and
> the number of bugs turned up in testing.

Unfortunately for the IT field, KLOCs typically WERE the main point for
evaluation, particualrly by non-technical magagement.

> Both the number of lines of code
> *and* the number of comment lines *were* recorded, however.

Sad to say, non-objective measures have become the bean-counters standard
for measurement.