Calculating G Forces from IGC file?

I thought it would be an interesting experiment to take an IGC trace
and figure out rates of climb. That much was pretty easy. I took
consecutive IGC file B-records and with just a little math I was able
to determine the ft/min or meters/min climb rates*.

I then thought it would be a good experiment to determine the G forces
as I pull up (decelerate) from cruise to lift or push over
(accelerate) from lift to cruise. Are there any physicists in the
house that can come up with a SIMPLE formula to calculate what a G
meter would have read based on the information I have?

Thanks, John

--------------------------------------------------------------

* The many individual b-records in an IGC file contains lots of good
information.

B1101355206343N00006198WA0158701558

110135: time tracklog entry was recorded at 11:01:35 i.e. just
after 11am (GMT)
5206343N: latitude i.e. 52 degrees 06.343 minutes North
00006198W: longitude i.e. 000 degrees 06.198 minutes West
A: altitude valid flag confirming this record has a valid
altitude value
01587: altitude in meters from pressure sensor
01558: altitude in meters from GPS

Rate of Climb per minute (m/sec) =
(Altitude #2 - Altitude #1) / (Time-Seconds #2 - Time-
Seconds #1) X 60 seconds

Rate of Climb per minute (ft/sec) = Rate of Climb per minute (m/sec) X
3.28084

On Tuesday, March 5, 2013 9:42:45 AM UTC-6, JohnDeRosa wrote:
I thought it would be an interesting experiment to take an IGC trace

and figure out rates of climb. That much was pretty easy. I took

consecutive IGC file B-records and with just a little math I was able

to determine the ft/min or meters/min climb rates*.



I then thought it would be a good experiment to determine the G forces

as I pull up (decelerate) from cruise to lift or push over

(accelerate) from lift to cruise. Are there any physicists in the

house that can come up with a SIMPLE formula to calculate what a G

meter would have read based on the information I have?



Thanks, John



--------------------------------------------------------------



* The many individual b-records in an IGC file contains lots of good

information.



B1101355206343N00006198WA0158701558



110135: time tracklog entry was recorded at 11:01:35 i.e. just

after 11am (GMT)

5206343N: latitude i.e. 52 degrees 06.343 minutes North

00006198W: longitude i.e. 000 degrees 06.198 minutes West

A: altitude valid flag confirming this record has a valid

altitude value

01587: altitude in meters from pressure sensor

01558: altitude in meters from GPS



Rate of Climb per minute (m/sec) =

(Altitude #2 - Altitude #1) / (Time-Seconds #2 - Time-

Seconds #1) X 60 seconds



Rate of Climb per minute (ft/sec) = Rate of Climb per minute (m/sec) X

3.28084

acceleration = delta V / delta t (vector)
Interesting to see if it works.
John Cochrane

I've been on the same lane.

You miss gravity, which gives you one extra. And in case of curving you miss the G-force from turning - the 60 deg used in narrow thermals give you one further.

At http://da.wikipedia.org/wiki/Bruger:...Logfil-analyse I've started some deductions - I actually reached the point where the nett G-force is calculated (last formula). Wiki was choosen, because it has an easily accessible formula tool ... in my oppinion at least.

For those interested I can add, that the explaining text is in danish, but readers with flair for math should be able to follow the formulas; first I move into an metric vector space (ti, xi, yi, zi); then I look at three consecutive observations and treat x, y and z as parables in time, and hence calculate acceleration (a) and velocity (v) in each of the three dimensions. Adding gravity and combining it by pythagoras gives the nett G-force.

My further intention was to split the logfile into phases of climb and glide; climb can be identified in the xy-plane by the acceleration (ax, yx) beeing perpendicular to the velocity (vx, vy). This offcourse requires at least three logs per full turn, so logfiles whith more than five seconds between logs are poor for analytical purposes.

When the climb-phases are identified, wind can be deduced. The simplest way is to subtract the two vectors representing max and min speed within a limitted span of logs. More complete could be to assume constant turn-rate and do a OLS-model with sin and cos-components. An advanced version would allow for increasing wind-speed with altitude.

With wind known, the thermal can be projected down to the 'hot spot' on the ground feeding it. The z-values calculated from the logs might need some calibration, but that can be done from the QFE of the takeoff/landing airfield.

The net strength of the termal is somewhat more complicated to guess. Total energy is simple enough - we know the changes in speed. But the sink of the glider will depend on the G-load (as above) multiplied by a loadfactor (some assumptions are needed - on good days the hotshots bring lots of water) run through a polar (aircraft known from the header, if the pilot did declare his task) and somehow compensated for dirt on the wings (increasing with time) and unintended sideslipping (more with narrow turns, I think). Reasonable assumptions can be made and a fair guess on the nett value of the termal - including strength by altitude - could come out.

I suspect there are some hot spots offering lift in different possitions with varying wind-directions. With data from multiple fligths it would be possible to identyfy them by strength and wind direction. (An I havn't completely forgiven olc not answering my request to have access to som IGC-files.)

With the gaggles we see during competitions it might as well be possible to make an 3d image of a thermal. I've allways dreamt of making a emperical based visualisation of a thermal.

Yours,
/Poul

JohnDeRosa:
I thought it would be an interesting experiment to take an IGC trace

and figure out rates of climb. That much was pretty easy. I took

consecutive IGC file B-records and with just a little math I was able

to determine the ft/min or meters/min climb rates*.



I then thought it would be a good experiment to determine the G forces

as I pull up (decelerate) from cruise to lift or push over

(accelerate) from lift to cruise. Are there any physicists in the

house that can come up with a SIMPLE formula to calculate what a G

meter would have read based on the information I have?



Thanks, John



--------------------------------------------------------------



* The many individual b-records in an IGC file contains lots of good

information.



B1101355206343N00006198WA0158701558



110135: time tracklog entry was recorded at 11:01:35 i.e. just

after 11am (GMT)

5206343N: latitude i.e. 52 degrees 06.343 minutes North

00006198W: longitude i.e. 000 degrees 06.198 minutes West

A: altitude valid flag confirming this record has a valid

altitude value

01587: altitude in meters from pressure sensor

01558: altitude in meters from GPS



Rate of Climb per minute (m/sec) =

(Altitude #2 - Altitude #1) / (Time-Seconds #2 - Time-

Seconds #1) X 60 seconds



Rate of Climb per minute (ft/sec) = Rate of Climb per minute (m/sec) X

3.28084

Poul - Wow. That was intense. I agree that this isn't just an
exercise in the vertical component.
John - I think you are pointing me in the right direction.

I came up with this math for just the vertical component. Does this
math seem correct?

===================

RateofClimb (vertical speed) m/s = (BRecord_Altitude_N meters -
BRecord_Altitude_N+1 meters) / BRecord_interval*

G force = (RateofClimb_N m/sec - RateofClimb_N+1 m/sec) /
(BRecord_interval*) / (9.80665 m/sec2)

===================
* Typical IGC log file interval has B record entries every 4 seconds.
Yours may be different. And in the C302 if you hit the event button,
the interval always goes to 1 second.

At first glance the second division by the BRecord_Interval seems
wrong, but the BRecord_Altitude's are spaced by the BRecord_interval
AND the RateofClimb's are also spaced by the BRecord_interval.

I looked at a flight in which I remembered the vario going to +17
knots (whoop!). I calculated the G force at 8.4. Seems about right.
This gives a four second averaging so no telling what instantaneous
rates are. So for those flying a ridge where they are getting bounced
up/down repeatedly, this 4 second calculation wouldn't say much about
what you are experiencing. Makes me want to change my log rate to 1
second! Or buy a G meter!

If my math is correct (big IF) then I will publish my calculations so
anyone can plug in their B records and calculate/graph the results.

- John

FYI - When you hit the event button on the Cambridge 302 via remote
switch required (and the Cambridge 302A via the front panel PEV
switch?) it will record 15 fixes at 1 second intervals.

This is useful when you are only going to touch a turnpoint cylinder
and don't want to wait around for X seconds (your standard recording
interval) to make sure you get a valid fix. I have heard of people
that missed a turnpoint due to this.

Do other flight recorders also have this feature?

- John

Buy the G-meter to get the actual data because the logic you have used is
not accurate.

First, you need a real time data recorder for the method you have chosen to
sample the event. Within 4 seconds you could load and unload G without the
event being recorded on the logger. Even with 1 second you would not
capture all of the data accuately.

Furthermore, I doubt the positional data being recorded is accurate enough
for what you are doing. There is a tolerance on the GPS signal. It is my
understanding that height position is a lot worse than Lat/Long.

In addition, I don't beleive your formula is taking into account the
deceleration caused by the G loading. High G's decelerate a glider. Looked
like your formula was straight line.

Finally, I doubt 8.4 G's is correct because this is a lot. A recreational
pilot would black out well before you reach this amount. Also, only the
high end aerobatic gliders could with stand over 8 Gs. A typical xcountry
glider is not rated for 8 G's.

As you said, buy a G meter.

Andrew


At 15:42 13 March 2013, JohnDeRosa wrote:
Poul - Wow. That was intense. I agree that this isn't just an
exercise in the vertical component.
John - I think you are pointing me in the right direction.

I came up with this math for just the vertical component. Does this
math seem correct?

===================

RateofClimb (vertical speed) m/s = (BRecord_Altitude_N meters -
BRecord_Altitude_N+1 meters) / BRecord_interval*

G force = (RateofClimb_N m/sec - RateofClimb_N+1 m/sec) /
(BRecord_interval*) / (9.80665 m/sec2)

===================
* Typical IGC log file interval has B record entries every 4 seconds.
Yours may be different. And in the C302 if you hit the event button,
the interval always goes to 1 second.

At first glance the second division by the BRecord_Interval seems
wrong, but the BRecord_Altitude's are spaced by the BRecord_interval
AND the RateofClimb's are also spaced by the BRecord_interval.

I looked at a flight in which I remembered the vario going to +17
knots (whoop!). I calculated the G force at 8.4. Seems about right.
This gives a four second averaging so no telling what instantaneous
rates are. So for those flying a ridge where they are getting bounced
up/down repeatedly, this 4 second calculation wouldn't say much about
what you are experiencing. Makes me want to change my log rate to 1
second! Or buy a G meter!

If my math is correct (big IF) then I will publish my calculations so
anyone can plug in their B records and calculate/graph the results.

- John

8 Gs seems like a lot. And position error will indeed maginfy second derivatives. I'd first fit a smoothed flight path through 10 points or so, then take second derivatives of the smoothed function. Just run a regression with a quadratic function for the x y and z coordinates separately +/- say 5 points, and use the coefficient on the quadratic term to get local acceleration.
John Cochrane

On Thursday, March 14, 2013 3:47:30 PM UTC-7, wrote:
8 Gs seems like a lot. And position error will indeed maginfy second derivatives. I'd first fit a smoothed flight path through 10 points or so, then take second derivatives of the smoothed function. Just run a regression with a quadratic function for the x y and z coordinates separately +/- say 5 points, and use the coefficient on the quadratic term to get local acceleration.

John Cochrane

I think 4 second intervals is pretty tough for trying to generate a view of acceleration in the vertical plane. You need three points to fit a quadratic which is what you need to measure acceleration. 3x4 =12 seconds. Take a look at this to see what happens when you pull just 3 Gs for 12 seconds.

http://www.youtube.com/watch?v=9aDJLDQ-5QU

I think you need a higher sample rate to come up with anything for normal maneuvering. Certainly measuring a circle will give you horizontal centripetal acceleration, but circling gives you a fair number of data points without getting inverted.

9B

I have a little toy app on my iPhone called "Roller Coaster Physics" that is essentially a g-meter recorder that was free if I recall right.

I don't know how accurate the meters in an iPhone are, but you could try recording some maneuvers and using it as a sanity check for your calcs. I think I downloaded it for use in the plane and pretty much forgot about it for 3 years until I saw this thread.

Morgan

On Thursday, March 14, 2013 7:08:35 PM UTC-7, wrote:
On Thursday, March 14, 2013 3:47:30 PM UTC-7, wrote:

8 Gs seems like a lot. And position error will indeed maginfy second derivatives. I'd first fit a smoothed flight path through 10 points or so, then take second derivatives of the smoothed function. Just run a regression with a quadratic function for the x y and z coordinates separately +/- say 5 points, and use the coefficient on the quadratic term to get local acceleration.



John Cochrane



I think 4 second intervals is pretty tough for trying to generate a view of acceleration in the vertical plane. You need three points to fit a quadratic which is what you need to measure acceleration. 3x4 =12 seconds. Take a look at this to see what happens when you pull just 3 Gs for 12 seconds..



http://www.youtube.com/watch?v=9aDJLDQ-5QU



I think you need a higher sample rate to come up with anything for normal maneuvering. Certainly measuring a circle will give you horizontal centripetal acceleration, but circling gives you a fair number of data points without getting inverted.



9B