IGC File / Flight-track Analysis

[noel.wade]

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

[Tuno]

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

[johngalloway[_2_]]

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

[Dave Nadler]

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"

[Dave Nadler]

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"

[Bob Gibbons[_2_]]

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

[Eric Greenwell]

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

[noel.wade]

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

[Chris Reed[_2_]]

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).

[Andy[_10_]]

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

[Dave Nadler]

On Jan 21, 10:59*pm, Bob Gibbons > wrote:
> 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

Hi Bob - This is nice, but this script:

(1) is dependent on the optional fields in this particular
LX IGC file. A better tool would, for example, pick up the
optional track from wherever it is provided and synthesize
it if not provided. This requires parsing the 'I' record.

(2) does not put the file into a convenient C++ container
for use in analysis

Thanks though !
Best Regards, Dave "YO electric"

[Dave Nadler]

On Jan 22, 7:10*am, Andy > wrote:
> 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

Um, depending on what he's trying to do, the Kalman filters
in the GPS could make life very difficult. Adding another
Kalman filter in back of the filter already in the GPS engine
is not likely to help. And every brand of GPS (and potentially
every software revision of the same brand) may have different
filtering.

Here's an experiment conducted a few times, with a GPS
engine in a car:
Drive at high speed
Disable the antenna
Slow rapidly and turn 90 degrees
Speed up
Enable antenna

What do you think the GPS output shows ?

Hope that helps clarify the problem,
Best Regards, Dave "YO electric"

[Andy[_10_]]

On Jan 22, 5:49*am, Dave Nadler > wrote:
> On Jan 22, 7:10*am, Andy > wrote:
>
>
>
>
>
> > 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
>
> Um, depending on what he's trying to do, the Kalman filters
> in the GPS could make life very difficult. Adding another
> Kalman filter in back of the filter already in the GPS engine
> is not likely to help. And every brand of GPS (and potentially
> every software revision of the same brand) may have different
> filtering.
>
> Here's an experiment conducted a few times, with a GPS
> engine in a car:
> Drive at high speed
> Disable the antenna
> Slow rapidly and turn 90 degrees
> Speed up
> Enable antenna
>
> What do you think the GPS output shows ?
>
> Hope that helps clarify the problem,
> Best Regards, Dave "YO electric"

Dave - Depending on the gains on the filter and the breaking action on
the car I expect you would get some sort of position overshoot in the
original direction while the antenna was disconnected, followed by an
arc at the modeled maximum cornering G to try to close the position
and velocity vector errors. But I may not recall my optimal estimation
theory precisely enough.

Even better experiment - Do a loop in your glider and play it back in
SeeYou. You will see that they are using an estimation model that
doesn't allow for inverted flight - or maybe there just isn't enough
information in the igc file to get you to inverted. In any case, the
glider flops around and pivots on its vertical axis as I recall.

Back to Noel's problem - I was referring to how to estimate aircraft
attitudes, velocities and angular rates from the data in the igc file.
Whether that data already has been smoothed through some optimal
estimation technique before generating the igc file shouldn't have too
big an impact on your ability to accurately estimate all the other
states (i.e. Euler angles and rates, linear positions and velocities)
from the position data as long as you are assuming reasonably similar
system dynamics. I'm not exactly clear what Noel is trying to
accomplish from the abbreviated description provided, but I thought it
is to estimate the full aircraft state from a reduced data set. You
should be able to use a calculus of variations approach to generate an
estimate for most state variables from the flight path data only. I'm
not sure what other type of approach would work. But then again I may
have misunderstood Noel's goal.

More on the use of Kalman filters: http://en.wikipedia.org/wiki/Kalman_filter

That went nerdy fast eh?

9B

[jimboffin]

On 22 Jan, 17:04, Andy > wrote:
> On Jan 22, 5:49*am, Dave Nadler > wrote:
>
>
>
>
>
> > On Jan 22, 7:10*am, Andy > wrote:
>
> > > 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
>
> > Um, depending on what he's trying to do, the Kalman filters
> > in the GPS could make life very difficult. Adding another
> > Kalman filter in back of the filter already in the GPS engine
> > is not likely to help. And every brand of GPS (and potentially
> > every software revision of the same brand) may have different
> > filtering.
>
> > Here's an experiment conducted a few times, with a GPS
> > engine in a car:
> > Drive at high speed
> > Disable the antenna
> > Slow rapidly and turn 90 degrees
> > Speed up
> > Enable antenna
>
> > What do you think the GPS output shows ?
>
> > Hope that helps clarify the problem,
> > Best Regards, Dave "YO electric"
>
> Dave - Depending on the gains on the filter and the breaking action on
> the car I expect you would get some sort of position overshoot in the
> original direction while the antenna was disconnected, followed by an
> arc at the modeled maximum cornering G to try to close the position
> and velocity vector errors. But I may not recall my optimal estimation
> theory precisely enough.
>
> Even better experiment - Do a loop in your glider and play it back in
> SeeYou. You will see that they are using an estimation model that
> doesn't allow for inverted flight - or maybe there just isn't enough
> information in the igc file to get you to inverted. In any case, the
> glider flops around and pivots on its vertical axis as I recall.
>
> Back to Noel's problem - I was referring to how to estimate aircraft
> attitudes, velocities and angular rates from the data in the igc file.
> Whether that data already has been smoothed through some optimal
> estimation technique before generating the igc file shouldn't have too
> big an impact on your ability to accurately estimate all the other
> states (i.e. Euler angles and rates, linear positions and velocities)
> from the position data as long as you are assuming reasonably similar
> system dynamics. I'm not exactly clear what Noel is trying to
> accomplish from the abbreviated description provided, but I thought it
> is to estimate the full aircraft state from a reduced data set. You
> should be able to use a calculus of variations approach to generate an
> estimate for most state variables from the flight path data only. I'm
> not sure what other type of approach would work. But then again I may
> have misunderstood Noel's goal.
>
> More on the use of Kalman filters: *http://en.wikipedia.org/wiki/Kalman_filter
>
> That went nerdy fast eh?
>
> 9B- Hide quoted text -
>
> - Show quoted text -

This is interesting. Are you saying that if you disconnect the aerial
as you approach the turnpoint and turn early the gps will then give
overshoot positions and the logger log you in the turn even though you
are already on the way to the next one?

I must try that!!

Jim

[Wojciech Scigala]

Użytkownik jimboffin napisał:

> This is interesting. Are you saying that if you disconnect the aerial
> as you approach the turnpoint and turn early the gps will then give
> overshoot positions and the logger log you in the turn even though you
> are already on the way to the next one?
Certified IGC flight recorders have this "dead reckoning" feature
disabled. It's also very easy to spot during file analysis.

--
Wojtuś.net

[Dave Nadler]

On Jan 22, 12:04*pm, Andy > wrote:
> On Jan 22, 5:49*am, Dave Nadler > wrote:
>
>
>
> > On Jan 22, 7:10*am, Andy > wrote:
>
> > > 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
>
> > Um, depending on what he's trying to do, the Kalman filters
> > in the GPS could make life very difficult. Adding another
> > Kalman filter in back of the filter already in the GPS engine
> > is not likely to help. And every brand of GPS (and potentially
> > every software revision of the same brand) may have different
> > filtering.
>
> > Here's an experiment conducted a few times, with a GPS
> > engine in a car:
> > Drive at high speed
> > Disable the antenna
> > Slow rapidly and turn 90 degrees
> > Speed up
> > Enable antenna
>
> > What do you think the GPS output shows ?
>
> > Hope that helps clarify the problem,
> > Best Regards, Dave "YO electric"
>
> Dave - Depending on the gains on the filter and the breaking action on
> the car I expect you would get some sort of position overshoot in the
> original direction while the antenna was disconnected, followed by an
> arc at the modeled maximum cornering G to try to close the position
> and velocity vector errors. But I may not recall my optimal estimation
> theory precisely enough.

You get plus one point. Depending on the implementation you may
see very interesting discontinuities in the output ;-)

> Even better experiment - Do a loop in your glider and play it back in
> SeeYou. You will see that they are using an estimation model that
> doesn't allow for inverted flight - or maybe there just isn't enough
> information in the igc file to get you to inverted. In any case, the
> glider flops around and pivots on its vertical axis as I recall.

I've found Reverse Cuban Eights really bother StrePla ;-)

> Back to Noel's problem - I was referring to how to estimate aircraft
> attitudes, velocities and angular rates from the data in the igc file.
> Whether that data already has been smoothed through some optimal
> estimation technique before generating the igc file shouldn't have too
> big an impact on your ability to accurately estimate all the other
> states (i.e. Euler angles and rates, linear positions and velocities)
> from the position data as long as you are assuming reasonably similar
> system dynamics. I'm not exactly clear what Noel is trying to
> accomplish from the abbreviated description provided, but I thought it
> is to estimate the full aircraft state from a reduced data set. You
> should be able to use a calculus of variations approach to generate an
> estimate for most state variables from the flight path data only. I'm
> not sure what other type of approach would work. But then again I may
> have misunderstood Noel's goal.

Noel has not specified his goal adequately enough to
really answer his question (he gets minus 2 points).

> More on the use of Kalman filters: *http://en.wikipedia.org/wiki/Kalman_filter
>
> That went nerdy fast eh?
>
> 9B

[Dave Nadler]

On Jan 22, 12:59*pm, Wojciech Scigala > wrote:
> Certified IGC flight recorders have this "dead reckoning" feature
> disabled.

Whanna Bet ?

> It's also very easy to spot during file analysis.

True. Is anybody looking ?

[Wojciech Scigala]

Użytkownik Dave Nadler napisał:

>> Certified IGC flight recorders have this "dead reckoning" feature
>> disabled.
> Whanna Bet ?
OK, should have ;D
It's covered at 2.7.5.1 in the GNSS FR specification.

>> It's also very easy to spot during file analysis.
> True. Is anybody looking ?
I always take a zoomed look at flight trace in turn areas.

--
Wojtuś.net