Determination of bank angle from speed and heading change per time period

On Wed, 10 Jan 2007 18:31:29 +1100, in ,
d&tm wrote:
The bank angle is in what ever units you want. it is the angle
expressed as degrees or radians that gives a tangent of 2*PI*v /( g*t)
(sorry I should have put in the brackets) check your equation with a
standard rate 1 turn. At 100kts a rate 1 turn will have t =120 seconds
and give a bank angle of 15.4 degrees.

I tried it both ways today and pretty much figured that it needed the
parentheses around the "g*t"... The atan function was returning things in
radians, so that's what gave me the brain fart...

I'm getting approximately 15.175 degrees for a bank angle, but that's
probably because I'm using a more accurate measurement for pi and g... Not
that it is likely to really matter since when I graph it, putting it to
the nearest degree will probably be accurate enough... Haven't decided if
I want to redraw the gauge each time or have a set of predrawn images that
I shift around indexed by the bank angle...

Thanks for the help...

--
Mike Shelley
N581 -- AA5A -- AXH

"Grumman-581" wrote in message
news
On Wed, 10 Jan 2007 18:31:29 +1100, in ,
d&tm wrote:
The bank angle is in what ever units you want. it is the angle
expressed as degrees or radians that gives a tangent of 2*PI*v /( g*t)
(sorry I should have put in the brackets) check your equation with a
standard rate 1 turn. At 100kts a rate 1 turn will have t =120 seconds
and give a bank angle of 15.4 degrees.

I tried it both ways today and pretty much figured that it needed the
parentheses around the "g*t"... The atan function was returning things in
radians, so that's what gave me the brain fart...

I'm getting approximately 15.175 degrees for a bank angle, but that's
probably because I'm using a more accurate measurement for pi and g... Not
that it is likely to really matter since when I graph it, putting it to
the nearest degree will probably be accurate enough... Haven't decided if
I want to redraw the gauge each time or have a set of predrawn images that
I shift around indexed by the bank angle...

Its close but is it close enough at greater angles.? what are you using for
the conversion of speed.? I used g =9.8 Pi as 3.14159 and v = kts
*1852/3600 m/s
terry

On Thu, 11 Jan 2007 00:05:44 +1100, in ,
d&tm wrote:
Its close but is it close enough at greater angles.? what are you using
for the conversion of speed.? I used g =9.8 Pi as 3.14159 and v =
kts *1852/3600 m/s

For conversion of speed, I'm using 6076 ft per nm, 3.14159265358979 for
pi, 9.80665 m/s^2 or 32.17398421 ft/sec^2 for g...

Interestingly on g, I'ver seen sources that quite it as being defined as
9.80665 *exactly* and others that quote it at 32.1740486... Not sure about
the later figure though since it is not exactly correct at least from a
conversion standpoint of the 9.80665 figure using the value of 39.37
inches per meter that I remembered... A quick lookup on the net and I find
that my memory was not correct and the 39.37 was not an *exact* figure...
Plugging in 39.37007874015748 instead and the values agree... For some
reason, I had thought that the 39.37 had been defined as an *exact*
value... Of course this also means that my memory is faulty on the 2.54
cm/in value also...

With regards to higher velocities and decreased values of time for the 360
degree circle, even with a 1 second 360 degree circle and 500 kts, the
values match to more digits than I really need (i.e. 88.26219913 and
88.26219912 degrees respectively for SI and US measurement units)... Yeah,
I would like to have an exact match, but there's probably some conversion
factor that I'm not using enough significant digits with...

"Grumman-581" wrote in message
news
On Thu, 11 Jan 2007 00:05:44 +1100, in ,
d&tm wrote:
snip

Plugging in 39.37007874015748 instead and the values agree... For some
reason, I had thought that the 39.37 had been defined as an *exact*
value... Of course this also means that my memory is faulty on the 2.54
cm/in value also...

My understanding is an inch is EXACTLY 2.54 cm.

Danny Deger

On Thu, 11 Jan 2007 14:33:45 -0600, in
, Danny Deger wrote:
My understanding is an inch is EXACTLY 2.54 cm.

Yeah, well I thought that a meter was defined as EXACTLY 39.37 inches
also, so I was leaving myself an out, just in case yet another previoiusly
held belief turned out to be wrong... According to
http://www.pmel.org/Handbook/HBConversion.htm, it appears that 2.54 is an
exact figure... Damn, that's a surprise...

Grumman-581 wrote:
For conversion of speed, I'm using 6076 ft per nm, 3.14159265358979 for
pi, 9.80665 m/s^2 or 32.17398421 ft/sec^2 for g...

Whoever is selling you your floats, doubles, and long doubles must be
making a killing.

Interestingly on g, I'ver seen sources that quite it as being defined
as 9.80665 *exactly* and others that quote it at 32.1740486...

http://en.wikipedia.org/wiki/Gravity_%28Earth%29 has the definition of
9.80665 m/(s^2). It does vary with where you are on the planet as well
as how far you are above it.
http://en.wikipedia.org/wiki/Acceler...due_to_gravity has a few more
details.

For some reason, I had thought that the 39.37 had been defined as an
*exact* value...

http://en.wikipedia.org/wiki/Inch#International_inch says that the yard
is defined as 0.9144 m. 0.9144 is exactly 36 * 2.54, so the correct
statement may be that an inch is exactly 2.54 cm. 36/0.9144 is
39.370079 according to the calculator; rounding off to 39.37 is a
whopping 0.0002% error.

Standard disclaimers about using Wikipedia as a reference apply.

With regards to higher velocities and decreased values of time for the
360 degree circle, even with a 1 second 360 degree circle and 500 kts,
the values match to more digits than I really need (i.e. 88.26219913
and 88.26219912 degrees respectively for SI and US measurement units)...

Your protractor salesman must also be living quite well.

Matt Roberds

On Thu, 11 Jan 2007 22:43:13 +0000, in ,
mroberds wrote:
Whoever is selling you your floats, doubles, and long doubles must be
making a killing.

I get a discount on them at TWORD-Depot... grin

Better to have the accuracy and choose to not use it than to need it and
not have it... If performance becomes an issue, you can always decrease
the bytes allocated for your variables...