IGC File / Flight-track Analysis

Hi All,

I'm working on a project that I can't talk about much, but I was
hoping to prevail upon some experts here. I need to analyze some IGC
files in my project, and try to use the data to determine the behavior
of the glider.

As I understand it, the bulk of the IGC file is just a series of time-
stamped position & altitude fixes. So to determine an aircraft's
heading (ground-track to be more precise, since we're referencing GPS
coordinates), I have to use pairs of position-fixes to come up with a
direction & velocity vector... Yes?

OK, now here's where it gets a little tricky: How to I make the leap
from those raw vectors to determining behavior? For example, you can
signal your release from tow by executing a sharp 360-degree turn.
Its easy enough to look at a few vectors in a row and as long as they
keep angling off to the same side (relative to the previous vector)
then I can consider the glider in a continuous turn. As long as the
continuous turn takes us past 360 degrees from the ground-track/
heading at the beginning of the turn, we're OK - right? But what
happens if the glider catches a gust of wind that slews the tail
momentarily or causes the glider to slip? What is my "fudge factor"
for these things and how do I reasonably account for them?

There are some other oddities that I'm unsure how to account for (or
if I even need to) - like: How do I deal with a wind-drift that's
causing the glider's absolute position to be offset?

I'm a programmer & IT person by day, but my work is keeping me
terribly busy and I've never had to do much in terms of pathing or
vector analysis - so this stuff is harder for me than it should be
right now. :-P Any help would be much appreciated!

Thanks, take care,

--Noel

Tim I thought the PEV was only activated by the pilot during flight? I
don't think this will help Noel.

Noel: the technique I've used is to track heading (as well as airspeed
(if provided), ground speed and both altitudes) and it's easy enough
to use that to tell when a 360 degree turn has been completed (thus
assuming start of a thermal).

If you're using C++, the exercise is a lot easier if you use STL
containers!

ted/2NO

On Jan 21, 1:32*pm, Tuno wrote:
Tim I thought the PEV was only activated by the pilot during flight? I
don't think this will help Noel.

Noel: the technique I've used is to track heading (as well as airspeed
(if provided), ground speed and both altitudes) and it's easy enough
to use that to tell when a 360 degree turn has been completed (thus
assuming start of a thermal).

If you're using C++, the exercise is a lot easier if you use STL
containers!

ted/2NO

Noel,

Sounds like collision warning device predictive path software??

I know nothing about programming but I think that gusts swinging the
tail of a glider is a negligible factor in the context of predicting
the path of a glider from log traces

John

On Jan 21, 3:56*am, "noel.wade" wrote:
Hi All,

I'm working on a project that I can't talk about much, but I was
hoping to prevail upon some experts here. *I need to analyze some IGC
files in my project, and try to use the data to determine the behavior
of the glider.

As I understand it, the bulk of the IGC file is just a series of time-
stamped position & altitude fixes. *So to determine an aircraft's
heading (ground-track to be more precise, since we're referencing GPS
coordinates), I have to use pairs of position-fixes to come up with a
direction & velocity vector... Yes?

Some flight recorders include the track information in the
IGC file via optional additions to the B records.
ILEC SN10 does this.

In any case, beware that the position and track as reported by
the GPS are the output of smoothing Kalman filters. Also, there
will be occasional discontinuities so take care to look for and
ignore these or your code will blow up. I have example log
files where time goes backwards, and positions jumping from
Montana into the North Atlantic. You'll see a "bad fix" count
in any of the analysis programs...

Be sure your intended use of the data can tolerate its
"features"...

OK, now here's where it gets a little tricky: *How to I make the leap
from those raw vectors to determining behavior? *For example, you can
signal your release from tow by executing a sharp 360-degree turn.
Its easy enough to look at a few vectors in a row and as long as they
keep angling off to the same side (relative to the previous vector)
then I can consider the glider in a continuous turn. *As long as the
continuous turn takes us past 360 degrees from the ground-track/
heading at the beginning of the turn, we're OK - right? *But what
happens if the glider catches a gust of wind that slews the tail
momentarily or causes the glider to slip? *What is my "fudge factor"
for these things and how do I reasonably account for them?

There are some other oddities that I'm unsure how to account for (or
if I even need to) - like: *How do I deal with a wind-drift that's
causing the glider's absolute position to be offset?

You could just calculate the wind.
That's what we do in the ILEC SN10 ;-)

I'm a programmer & IT person by day, but my work is keeping me
terribly busy and I've never had to do much in terms of pathing or
vector analysis - so this stuff is harder for me than it should be
right now. :-P *Any help would be much appreciated!

Sounds like you need to hit the books ;-)

Thanks, take care,

--Noel

Hope this helps !
Best Regards, Dave "YO electric"

On Jan 21, 8:32*am, Tuno wrote:
If you're using C++, the exercise is a lot easier if you use STL
containers!

ted/2NO

Anybody got a decent open-source IGC-format parser
that reads a flight log file into a nice container ?

Mine is highly specific to SN10 features and wouldn't be
helpful here...

Best Regards, Dave "YO electric"

On Thu, 21 Jan 2010 06:01:40 -0800 (PST), Dave Nadler
wrote:

.... text deleted ...
Anybody got a decent open-source IGC-format parser
that reads a flight log file into a nice container ?

Mine is highly specific to SN10 features and wouldn't be
helpful here...

Best Regards, Dave "YO electric"

Pretty simple to use an awk script to parse through the IGC file.

See,
http://www.gnu.org/manual/gawk/gawk.html

Here's a simple script I have used to extract the IGC data in a more
user friendly format.

# Awk routine to filter out igc file
# Filename: igctest3.awk
substr($1,1,1) ~ /B/ {
time=substr($1,2,6);
Lat=substr($1,8,8);
Long=substr($1,16,9);
Press_Alt=substr($1,26,5);
GPS_Alt=substr($1,31,5)
TrueAS=substr($1,42,5)
GroundSpeed=substr($1,47,5)
TrueTrack=substr($1,52,3)
Netto=substr($1,55,5)
# Convert Airspeeds from km/hr to knots
print
time,Lat,Long,Press_Alt,GPS_Alt,TrueAS*(0.5399568)/100,GroundSpeed*(0.5399568)/100,TrueTrack,Netto
}

This script prints out a series of text lines, space separated, with
the following values.

Time, Lat, Long, Press_Alt, GPS_Alt, TrueAirspeed,GroundSpeed, Track
Direction, and Netto

Note that this particular example uses some IGC data extensions
particular to the LX8000, defined by the IGC header lines near the top
of the data file;
I063638FXA3941ENL4246TAS4751GSP5254TRT5559VAT
J020810WDI1115WVE

As an example of the script usage, the following command,

awk -f igctest3.awk 91VLJAL2.igc

operating on the following igc file (extracteding only the first few
lines;

ALXNJALFLIGHT:2
HFDTE310109
HFFXA035
HFPLTPILOT:
HFGTYGLIDERTYPE:Hph304s
HFGIDGLIDERID:N304AB
HFDTM100GPSDATUM:WGS-1984
HFRFWFIRMWAREVERSION:1.0
HFRHWHARDWAREVERSION:1
HFFTYFRTYPE:LXNAVIGATION,LX8000
HFGPS:uBLOX LEA-4P,16,max9000m
HFPRSPRESSALTSENSOR:INTERSEMA,MS5534A,max10000m
HFCIDCOMPETITIONID:AB
HFCCLCOMPETITIONCLASS:18-meter
HFTZNTIMEZONE:0
I063638FXA3941ENL4246TAS4751GSP5254TRT5559VAT
J020810WDI1115WVE
C310109173251310109000002
C0000000N00000000E
C3219463N09639711W10 ENNIS
C3136677N09713831WWACO
C3218123N09701055W25 MYPRL
C3222910N09700620W65 TSFns
C0000000N00000000E
LLXNOZ=1,Style=1,R1=1609m,A1=180,R2=0m,A2=0,A12=27 9.5,Maxa=0m,Autonext=1
LLXNTSK,TaskTime=7200s
B1732513222953N09700715WA0011400194036004018050000 116600005
B1732523222953N09700715WA0011400194036004018390000 116600000
B1732533222953N09700715WA0011400194036004018360000 316600000
B1732543222953N09700715WA0011400194036004017490000 316600000
B1732553222953N09700715WA0011400194036004016470000 216600000
B1732563222953N09700715WA0011400194036004016190000 416200005
B1732573222953N09700715WA0011400194036004016160000 116200003
B1732583222953N09700715WA0011400194036004016410000 216200002
B1732593222953N09700715WA0011400194036004016060000 316200003
B1733003222953N09700715WA0011400194036004016640000 116200001
B1733013222953N09700715WA0011400194036004017170000 2162-0002
B1733023222953N09700715WA0011400194036004017620002 9162-0001
B1733033222953N09700715WA0011500194036004018200017 916300000
B1733043222953N09700715WA0011400194036004019440040 118000004
B1733053222952N09700715WA0011400194036004021690072 018000000
..
..
..

The output (partial) of the script is,

173251 3222953N 09700715W 00114 00194 9.74622 0.00539957 166 00005
173252 3222953N 09700715W 00114 00194 9.92981 0.00539957 166 00000
173253 3222953N 09700715W 00114 00194 9.91361 0.0161987 166 00000
173254 3222953N 09700715W 00114 00194 9.44384 0.0161987 166 00000
173255 3222953N 09700715W 00114 00194 8.89309 0.0107991 166 00000
173256 3222953N 09700715W 00114 00194 8.7419 0.0215983 162 00005
173257 3222953N 09700715W 00114 00194 8.7257 0.00539957 162 00003
173258 3222953N 09700715W 00114 00194 8.86069 0.0107991 162 00002
173259 3222953N 09700715W 00114 00194 8.67171 0.0161987 162 00003
173300 3222953N 09700715W 00114 00194 8.98488 0.00539957 162 00001
173301 3222953N 09700715W 00114 00194 9.27106 0.0107991 162 -0002
173302 3222953N 09700715W 00114 00194 9.51404 0.156587 162 -0001
173303 3222953N 09700715W 00115 00194 9.82721 0.966523 163 00000
173304 3222953N 09700715W 00114 00194 10.4968 2.16523 180 00004
173305 3222952N 09700715W 00114 00194 11.7117 3.88769 180 00000
173306 3222950N 09700715W 00114 00194 13.6177 7.20842 181 00015
173307 3222948N 09700715W 00114 00194 15.8531 12.3812 181 00043
173308 3222943N 09700716W 00114 00194 19.1901 17.5486 181 00071
173309 3222938N 09700716W 00114 00194 24.0065 21.8521 181 00117
173310 3222931N 09700716W 00113 00194 29.6544 26.7657 181 00174
173311 3222922N 09700716W 00114 00194 34.5464 30.9611 181 00237
173312 3222913N 09700717W 00112 00194 38.3099 34.8812 184 00256
173313 3222902N 09700718W 00112 00193 44.1577 39.1469 184 00304
173314 3222891N 09700719W 00111 00193 49.1955 42.7052 184 00395
173315 3222878N 09700721W 00112 00193 51.7657 46.3985 185 00426
173316 3222864N 09700722W 00112 00193 55.108 49.2387 184 00409

This data file can be pulled into Excel or any other program desired
for futher analysis.

Awk is a very powerful tool, as is it's more sophisticated cousin,
Perl.

Bob

noel.wade wrote:
Hi All,

I'm working on a project that I can't talk about much, but I was
hoping to prevail upon some experts here. I need to analyze some IGC
files in my project, and try to use the data to determine the behavior
of the glider.
There are a number of programs that do this, such as SeeYou, simulator
software (Condor?), even commercial programs that reconstruct a flight
from gps data for accident and other investigations. T2T (track to
thermal) picks out thermals from the data. Have you investigated
acquiring one of these programs, or getting them to slice of a piece of
it for your purposes?

--
Eric Greenwell - Washington State, USA
* Change "netto" to "net" to email me directly

* "A Guide to Self-launching Sailplane Operation" at www.motorglider.org

On Jan 21, 8:00*pm, Eric Greenwell wrote:

There are a number of programs that do this, such as SeeYou, simulator
software (Condor?), even commercial programs that reconstruct a flight
from gps data for accident and other investigations. T2T (track to

Eric -

Yes I have. The catch is that this project isn't mine; I'm
volunteering my time for it. And the people I'm working with don't
want the end-result to be tied to any licensing fees or restrictions
on use of the code.
*sigh* *shrug*

Thanks all,

--Noel

noel.wade wrote:
On Jan 21, 8:00 pm, Eric Greenwell wrote:

There are a number of programs that do this, such as SeeYou, simulator
software (Condor?), even commercial programs that reconstruct a flight
from gps data for accident and other investigations. T2T (track to

Eric -

Yes I have. The catch is that this project isn't mine; I'm
volunteering my time for it. And the people I'm working with don't
want the end-result to be tied to any licensing fees or restrictions
on use of the code.
*sigh* *shrug*

Thanks all,

--Noel

XC Soar is Open Source, which might work if the GPL restrictions
wouldn't affect the exploitation of the project (this would require you
to make any modified XC Soar code modules available under the GPS terms,
but not interfacing modules which would stay proprietary).

On Jan 22, 3:05*am, Chris Reed wrote:
noel.wade wrote:
On Jan 21, 8:00 pm, Eric Greenwell wrote:

There are a number of programs that do this, such as SeeYou, simulator
software (Condor?), even commercial programs that reconstruct a flight
from gps data for accident and other investigations. T2T (track to

Eric -

Yes I have. *The catch is that this project isn't mine; I'm
volunteering my time for it. *And the people I'm working with don't
want the end-result to be tied to any licensing fees or restrictions
on use of the code.
*sigh* *shrug*

Thanks all,

--Noel

XC Soar is Open Source, which might work if the GPL restrictions
wouldn't affect the exploitation of the project (this would require you
to make any modified XC Soar code modules available under the GPS terms,
but not *interfacing modules which would stay proprietary).

I'd contact the Aerospace Engineering department at a university near
you. Most graduate programs and some undergraduate ones have analytic
tools they use to do optimal estimation for a state-space
representation of aircraft. To do some of the things you are asking
about I suspect you'd need a full 6 degree of freedom model. Depending
on what the inputs are, you may not be able to fully estimate the
aircraft state - there would be too many unknowns. For instance,
because you don't have attitude information (none of the Euler
angles), you wouldn't be able to cleanly distinguish between gusts
displacing the aircraft and control inputs. You would likely need to
assume coordinated flight and no wind gusts. Some simple Kalman
filters should help, as Dave says.

9B