FlightGear wiki - User contributions [en]

Soaring

2009-04-29T14:26:19Z

B21: /* Gliders */

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:User |User portal]] >> Soaring

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism|developers page on Improving Glider Realism]].

== Gliders ==

{{Gallery|
[[Airwave Xtreme 150]]|AirwaveXtreme150.jpg|
[[Dragonfly|Moyes Dragonfly]]|Dragonfly-towing.jpg|
[[Paraglider]]|Paraglider.jpg|
[[Schweizer 2-33]]|Sgs233.jpg|
[[ASW-20 sailplane|Schleicher ASW-20]]|Asw20.jpg|
[[Glaser-Dirks DG-300|Glaser-Dirks DG-300]]|DG-300.jpg|
[[SZD-9bis_Bocian-1E|Bocian]]|SZD-9bis_Bocian-1E.jpg
}}

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Soaring

2009-04-29T14:21:59Z

B21: updated link text

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:User |User portal]] >> Soaring

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism|developers page on Improving Glider Realism]].

== Gliders ==

{{Gallery|
[[Airwave Xtreme 150]]|AirwaveXtreme150.jpg|
[[Dragonfly|Moyes Dragonfly]]|Dragonfly-towing.jpg|
[[Paraglider]]|Paraglider.jpg|
[[Schweizer 2-33]]|Sgs233.jpg|
[[ASW-20 sailplane|Schleicher ASW-20]]|Asw20.jpg|
[[Glaser-Dirks DG-300|Glaser-Dirks DG-300]]|DG-300.jpg
}}

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Improving Glider Realism

2009-04-29T14:06:14Z

B21: /* Glider cockpit 3D models */ added screenshot of FSX Aerosoft Discus

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:Developer |Development portal]] >> Improving Glider Realism

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The current (April 2009) panels are displayed below - functional but a bit sparse compared to real gliders:

==== ASK 21 Panel ====
[[Image:Ask 21 cockpit.jpg]]

==== DG300 Panel ====
[[Image:DG-300-Cockpit.jpg]]

==== FSX Comparison ====

The (upcoming) Aerosoft Discus sets the high ground for glider cockpit and panel modelling. To see how high the bar has been raised [http://www.specific-3d-design.de/resources/Discus%20Panel.jpg see here]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated / time
** = (change in kinetic energy / (mass x G))/t
** = ((0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)) / t
** = (v2^2 - v1^2) / 2Gt where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / (19.62*t)'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].
This is now implemented in CVS. Ridge lift is enabled by default but may be disabled by using
--prop:/environment/ridge-lift/enabled=0
on the command line or by setting this property at runtime.

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-29T14:01:11Z

B21: /* Glider cockpit 3D models */ added screenshot of DG300 panel

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:Developer |Development portal]] >> Improving Glider Realism

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

==== ASK 21 Panel ====
[[Image:Ask 21 cockpit.jpg]]

==== DG300 Panel ====
[[Image:DG-300-Cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated / time
** = (change in kinetic energy / (mass x G))/t
** = ((0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)) / t
** = (v2^2 - v1^2) / 2Gt where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / (19.62*t)'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].
This is now implemented in CVS. Ridge lift is enabled by default but may be disabled by using
--prop:/environment/ridge-lift/enabled=0
on the command line or by setting this property at runtime.

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Soaring

2009-04-29T13:58:09Z

B21: added breadcrumbs

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:User |User portal]] >> Soaring

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism|developers page]].

== Gliders ==

{{Gallery|
[[Airwave Xtreme 150]]|AirwaveXtreme150.jpg|
[[Dragonfly|Moyes Dragonfly]]|Dragonfly-towing.jpg|
[[Paraglider]]|Paraglider.jpg|
[[Schweizer 2-33]]|Sgs233.jpg|
[[ASW-20 sailplane|Schleicher ASW-20]]|Asw20.jpg|
[[Glaser-Dirks DG-300|Glaser-Dirks DG-300]]|DG-300.jpg
}}

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Soaring

2009-04-29T13:56:21Z

B21: added 'gliders' section

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism|developers page]].

== Gliders ==

{{Gallery|
[[Airwave Xtreme 150]]|AirwaveXtreme150.jpg|
[[Dragonfly|Moyes Dragonfly]]|Dragonfly-towing.jpg|
[[Paraglider]]|Paraglider.jpg|
[[Schweizer 2-33]]|Sgs233.jpg|
[[ASW-20 sailplane|Schleicher ASW-20]]|Asw20.jpg|
[[Glaser-Dirks DG-300|Glaser-Dirks DG-300]]|DG-300.jpg
}}

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

YASim

2009-04-28T19:50:53Z

B21: /* XML Elements */ corrected formatting error of top few sections

'''Coordinate system notes:'''
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.

=== [[XML]] Elements ===
==== airplane ====
The top-level element for the file. It contains only one attribute:
*'''mass:''' The empty (no fuel) weight, in pounds.
==== approach ====
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.
*'''speed:''' The approach airspeed, in knots TAS.
*'''aoa:''' The approach angle of attack, in degrees
*'''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.
==== cruise ====
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!
*'''speed:''' The cruise speed, in knots TAS.
*'''alt:''' The cruise altitude, in feet MSL.
*'''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.
==== cockpit ====
The location of the cockpit (pilot eyepoint).
*'''x,y,z:''' eyepoint location (see coordinates note)

==== fuselage ====
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.
*'''ax,ay,az:''' One end of the tube (typically the front)
*'''bx,by,bz:''' The other ("back") end.
*'''width:''' The width of the tube, in metres.
*'''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.
*'''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.
*'''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.
*'''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times them width you can define cy=2 and (due to the doubled front surface) cx=2.

==== wing ====
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.
*'''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.
*'''length:''' The length from the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.
*'''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).
*'''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).
*'''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).
*'''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.
*'''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero.
*'''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.
*'''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.
*'''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.
==== hstab ====
These defines the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.
==== vstab ====
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.
==== mstab ==== A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.
==== stall ==== A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.
*'''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).
*'''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).
*'''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.
==== flap0, flap1, slat, spoiler ====
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.
*'''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.
*'''end:''' The position where the surface ends, as above.
*'''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.
*'''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.
*'''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.

==== Engine ====
===== Thruster =====
*'''thruster:''' A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...
*'''thrust:''' Maximum thrust in pounds
*'''x,y,z:''' The point on the airframe where thrust will be applied.
*'''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.

===== Jet =====
*'''jet:''' A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.
*'''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.
*'''mass:''' The mass of the engine, in pounds.
*'''thrust:''' The maximum sea-level thrust, in pounds.
*'''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].
*'''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].
*'''n1-idle:''' Idling low pressure core / fan speed [55].
*'''n1-max:''' Maximum low pressure core / fan speed [102].
*'''n2-idle:''' Idling high pressure core speed [73].
*'''n2-max:''' Maximum high pressure core speed [103].
*'''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.
*'''egt:''' Exhaust gas temperature at takeoff [1050].
*'''epr:''' Engine pressure ratio at takeoff [3.0].
*'''exhaust-speed:''' The maximum exhaust speed in knots [~1555].
*'''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.

===== Propeller =====
*'''propeller:''' A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.
*'''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.
*'''mass:''' The mass of the engine/propeller, in pounds.
*'''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in metres) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.
*'''radius:''' The radius, in metres, or the propeller.
*'''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.
*'''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.
*'''cruise-power:''' The power sunk by the prop at cruise, in horsepower.
*'''cruise-alt:''' The reference cruise altitude in feet.
*'''takeoff-power:''' The takeoff power required by the propeller...
*'''takeoff-rpm:''' ...at the given takeoff RPM.
*'''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.
*'''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.
*'''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).
*'''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.
*'''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).
*'''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.
*'''piston-engine:''' A piston engine definition. This must be a subelement of an enclosing <propeller> tag.
*'''eng-power:''' Maximum BHP of the engine at sea level.
*'''eng-rpm:''' The engine RPM at which eng-power is developed
*'''displacement:''' The engine displacement in cubic inches.
*'''compression:''' The engine compression ratio.

==== Gear ====
*'''gear:''' Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground).
*'''x,y,z:''' The location of the fully-extended gear tip.
*'''compression:''' The distance in metres along the "up" axis that the gear will compress.
*'''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)
*'''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".
*'''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.
*'''dfric:''' Dynamic friction. Defaults to 0.7.
*'''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.
*'''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.
*'''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"
*'''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"
*'''speed-planing:'''
*'''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.
*'''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"
*'''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.

===== Launchbar =====
*'''launchbar:''' Defines a catapult launchbar or strop.
*'''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.
*'''length:''' The length of the launch bar from mount point to tip
*'''down-angle:''' The max angle below the horizontal the launchbar can achieve.
*'''up-angle:''' The max angle above the horizontal the launchbar can achieve.
*'''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.
*'''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.

==== Fuel ====
*'''tank:''' A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank.
*'''x,y,z:''' The location of the tank.
*'''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.
*'''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.

====Ballast====
*'''ballast:''' This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft.
*'''x,y,z:''' The location of the ballast.
*'''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.

=====Weight=====
*'''weight:''' This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)
*'''x,y,z:''' The location of the weight.
*'''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.
*'''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).
*'''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.
*'''idx:''' Index of the weight in the file (starting with zero). weight: Weight setting in pounds.
*'''control-input:''' This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.
*'''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".
*'''control:''' Which control axis to set on the objects. It can have the following values:
**THROTTLE - The throttle on a jet or propeller.
**MIXTURE - The mixture on a propeller.
**REHEAT - The afterburner on a jet
**PROP - The propeller advance
**BRAKE - The brake on a gear.
**STEER - The steering angle on a gear.
**INCIDENCE - The incidence angle of a wing.
**FLAP0 - The flap0 deflection of a wing.
**FLAP1 - The flap1 deflection of a wing.
**SLAT - The slat extension of a wing.
**SPOILER - The spoiler extension for a wing.
**CYCLICAIL - The "aileron" cyclic input of a rotor
**CYCLICELE - The "elevator" cyclic input of a rotor
**COLLECTIVE - The collective input of a rotor
**ROTORENGINEON - If not equal zero the rotor is rotating
**WINCHRELSPEED - The relative winch speed
**{... and many more, see FGFDM.cpp ...}
*'''invert:''' Negate the value of the property before setting on the object.
*'''split:''' Applicable to wing control surfaces. Sets the normal value on the left wing, and a negated value on the right wing.
*'''square:''' Squares the value before setting. Useful for controls like steering that need a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1].
*'''src0/src1/dst0/dst1:''' If present, these defined a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.
*'''control-output:''' This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.
*'''control:''' Name of the control axis. See above.
*'''prop:''' Property node to receive the value.
*'''side:''' Optional, for split controls. Either "right" or "left"
*'''min/max:''' Clamping applied to output value.
*'''control-speed:''' Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.
*'''control:''' Name of the control axis. See above.
*'''transition-time:''' Time in seconds to slew through input range.
*'''control-setting:''' This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...
*'''axis:''' Name of the control input (i.e. a property name)
*'''value:''' Value of the control axis.

====Winch and Aerotow====
*'''hitch:''' A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircrafts) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).
*'''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.
*'''x,y,z:''' The position of the hitch
*'''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircrafts to "0". It's intended, that this is done automatically in the future.
*'''tow:''' The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.
*'''length:''' upstretched length in metres
*'''weight-per-meter:''' in kg/metre
*'''elastic-constant:''' lower values give higher elasticity
*'''break-force:''' in N
*'''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider
*'''winch:''' The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.
*'''max-tow-length:''' in m
*'''min-tow-length''': in m
*'''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature
*'''max-winch-speed:''' in m/s
*'''power:''' in kW
*'''max-force:''' in N

{{FDM}}

Improving Glider Realism

2009-04-28T18:34:43Z

B21: /* Variometer */ error in TE adjustment formula

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:Developer |Development portal]] >> Improving Glider Realism

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated / time
** = (change in kinetic energy / (mass x G))/t
** = ((0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)) / t
** = (v2^2 - v1^2) / 2Gt where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / (19.62*t)'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].
This is now implemented in CVS. Ridge lift is enabled by default but may be disabled by using
--prop:/environment/ridge-lift/enabled=0
on the command line or by setting this property at runtime.

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Property Tree Intro

2009-04-27T12:35:53Z

B21: trial breadcrumb

{{Stub}}

[http://www.flightgear.org FG Home] >> [[Portal:Developer|Developer Portal]] >> [[Property Tree]] >> Intro

(Inspired by and somewhat based on [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21190.html])

Note: If you find anything particularly unclear, missing or just hard to understand please feel free to ask specific questions on this article's talk page, this will help improve this introduction.

== !! Work in Progress !! ==
This needs more work, namely:
* terminology
* examples
* screenshots
* usage scenarios (telnet, property browser, XML files, nasal ...)
* wikipedia links to more technical descriptions
* links to source/implementation code
* links to example source code to interface with the props interface
* we might want to convert something like this into some sort of presentation or PDF handout?
* topics to cover:
** history of the property tree

== Intro ==
The so called "Property Tree" in FlightGear is generally considered FlightGear's "central nervous system" and one of FlightGear greatest assets, if not even its greatest asset of all!

This is because the Property Tree system can be used to provide access to lowlevel runtime state variables via a very intuitive tree-like hierarchy, so that FlightGear behavior can be easily controlled and modified/customized at runtime.

So the FlightGear Property Tree is the common denominator for crucial runtime state and also the interface to these internal state variables.

However, getting to grips with the concepts and mechanisms behind the "Property Tree" may not be easy for FlightGear beginners. This page is meant to help newcomers familiarize themselves with the FlightGear property tree.

== An abstract View ==
The Property Tree System in FlightGear is generally spoken, used by pretty much all FlightGear subsystems that are basically tied together by it, in other words: it is the property tree that is the enabling mechanism to "share" important runtime data between different components of FlightGear.

While this doesn't necessarily apply to all FlightGear data structures, it does mostly apply to those variables that may need to be modified at runtime, be it for customization purposes or other uses. In addition, it is made very straightforward to publish/expose new variables from C++ space to the property tree.

But the Property Tree is also used by other FlightGear-related software (such as Atlas), where the Property Tree's purpose is extended to being that of an network-based "Inter Process Communications (IPC)"-mechanism/enabler, so that other software (open source or or not) can easily interface with and "look into" FlightGear, and inspect/modify runtime state variables (in a peek/poke manner).

This makes it for example possible, to basically "remote control" FlightGear, but also to modify environmental settings easily at runtime, from a different process, computer, network or even continent!

Access to the Property Tree is provided via well-defined means, such as C++ APIs, network protocols, XML files and scripting interfaces (via Nasal).

Furthermore, the Property Tree has been designed to directly map to XML files, specifically to "PropertyList-encoded" XML files, these follow a key/value structure that can be directly translated to the hierarchy used in the Property Tree.

In fact, most of the contents of the FlightGear Property Tree that you get to see at runtime is dynamically composed from such PropertyList-encoded XML files, that are directly loaded into the property tree.

== Property Tree: Step by Step ==

=== A dump space for your data ===
For starters, it's probably sufficient to imagine the property tree as a very powerful global (process-wide) "dump space" for simple variables, such as numbers and strings.

=== Key/Value pairs ===
The property tree stores variables as "key/value" pairs, so that you can easily refer to a variable by using its "key" (such as for example "altitude") and query the property tree for the value that it has stored for this key (variable).

=== Hierarchical Storage / where the tree part comes in ===
To provide support for hierarchically/logically grouped variable storage, the property tree is implemented as a tree-like structure of nested key/value pairs, this can be imagined pretty much like a virtual file system where you have folders (locations) and files (data).

=== Categories for your data ===
This approach is powerful because it supports the concept of "categories" for data storage, so that you can place -by convention- certain "data" in a specific place (think "drawer"), pretty much like storing work-related stuff in a "work" folder on your computer, or storing your media files (video/audio) in a distinct "media" folder, too.

So, this system allows for logical groups or "categories" of data items, so that you know where to search for certain data. On the other hand, this is based purely on conventions - there's nothing that enforces things to be placed in a certain location.

== Property Tree Paths ==
In fact, the file system analogy previously used pretty much also applies to accessing (writing/reading) values: Values (or data items) in the property tree can be referred to via a "path" which acts as the "key" to the data, this path pretty much looks like a conventional file system path, for example something like "/private/settings/foo" could be an imaginary path/key to access a property tree variable stored at that place.
So, from a syntactic point of view this is pretty much similar to file system paths, like they are used on Linux/Unix computers (i.e. no drive letters or backslashes are used).

=== Naming Properties ===
In addition, some naming restrictions apply as well: in general, you should only use lower-case, alphanumeric ASCII characters in these paths, and only use the hyphen to separate words or append a suffix. These conventions simplify working with properties and make them more intuitive.

=== Naming Conventions ===
To ensure that keys (paths) to variables are not simply named arbitrarily, some naming conventions apply, these can be mostly deduced from existing properties, such as for example appending a suffix to make properties more self-explanatory by indicating what unit the properties is provided in (e.g. "deg", "rad", "hz", "ft", "nm").

=== Identically named properties ===

== Typing ==
In general, the property tree is pretty much untyped, that is it can easily work with untyped properties (stored as strings) that can be dynamically converted to different representations (such as numbers like int, float, double or boolean values) at runtime.

However, when creating your own properties, it is generally considered good practice to also chose the most suitable data type, as well.

It is important to keep in mind that storing a property without its type (i.e. untyped), will inevitably result in a conversion being performed to convert the data to a non-string representation.

So, to avoid unnecessary performance penalties it's always a good idea to also define valid types for your properties.
Likewise, using the proper access means to avoid unnecessary conversions, is also important.

Property tree

2009-04-27T12:34:15Z

B21: trial breadcrumb

{{Stub}}
{{Cleanup}}

[http://www.flightgear.org FG Home] >> [[Portal:Developer|Developer Portal]] >> Property Tree

== Property Tree Introduction ==
A simple technical introduction about the FlightGear property tree can be found at [[Property Tree Intro]].

== Property Server ==

For instance, start FlightGear with the following option:

--httpd=5400

You can pick any port number, but 5400 will probably work just fine.

Now on the same machine, fire up a web browser and open up the following url:

http://localhost:5400/

Now you can browse the entire FG property tree "live" and even change values if you like. You can configure autopilot modes and even set control inputs so you can literally fly the airplane from your web browser, although it's not the most convenient interface for doing that. ;-)

There is a similar interface minus the html wrappings that you can enable with the following option:

--props=5401

Note that you can setup as many of these as you want ... for instance, just to be obscene you could do:

--httpd=5400
--httpd=5401
--httpd=5402
--props=5403
--props=5404
--props=5405

Now you have 6 different network interfaces running that you can access from anywhere. We can't find a wiki named Note.

If you have a 'props' inteface configured you can now "telnet localhost 5401" and interact with the property system (again live) and set and examine values using a 'command line' style interface.

The cool thing is that you can easily write scripts to access this --props=<port#> interface.

Take a look at:

FlightGear/source/scripts/perl/examples/

Note that there is no requirement that you do this with perl. You could just as easily interact with FlightGear this way using perl, C, C++, java, probably even <ack> visual basic or anything else that can do tcpip network communication ... matlab? netcat?

Also note that the downside to this interface is that you can't blast a lot of data across it. It's fine if you want to monitor location and speed every second or 1/4 second and occasionally set some values (such as dump in a new weather configuration, reset the aircraft location, or read a set of values, etc.)

But if you need to track 100 different variables at 60hz, this isn't the interface for you.

== Property Tree ==
A detailed list of all nodes within the property tree and their purpose, as well as possible values

==== accelerations/ ====
==== ai/ ====
==== autopilot/ ====
==== command/ ====
==== consumables/ ====

* fuel/
** tank/
** tank[1]/
** tank[2]/
** tank[3]/
** total-fuel-gals
** total-fuel-lbs
** total-fuel-norm

Note: The number of tanks will vary between aircraft. Please take this into account when you are designing your script

==== controls/ ====

* APU
** fire-switch
** off-start-run

==== devices/ ====
==== engines/ ====
==== environment/ ====
==== fdm/ ====
==== gear/ ====
==== input/ ====
==== instrumentation/ ====
==== logging/ ====
==== models/ ====
==== nasal/ ====
==== orientation/ ====
The set of properties in orientation/ detail the orientation of the aircraft (pitch, yaw and roll).

* alpha-deg
* heading-deg
* heading-magnetic-deg
* pitch-deg
* pitch-rate-degps
* roll-deg
* roll-rate-degps
* side-slip-deg
* side-slip-rad
* yaw-deg
* yaw-rate-degps

==== position/ ====
The set of properties in position/ track the lat/lon location of the user's aircraft, as well as altitude and ground elevation immediately below the aircraft.

* longitude-deg -- Current longitude of the aircraft in degrees.
* latitude-deg -- Current latitude of the aircraft in degrees.
* altitude-ft -- Current altitude of the aircraft above mean sea level.
* ground-elev-m -- elevation of the ground below the aircraft, in meters. Note that for this property, ground structures are considered part of the ground. Thus, flying over any ground structure (a building, a sign, a radio tower, whatever) will raise the value of this property for as long as the aircraft is over the structure.
* altitude-agl-ft -- Current altitude of the aircraft above ground/ground structures below.

==== sim/ ====
* aero --
* ai
* ai-traffic
* aircraft --
* aircraft-dir --
* aircraft-min-status --
* alarms --
* allow-toggle-cockpit --
* ATC
* atc
* author --
* auto-coordination -- boolean (true/false) flag indicating whether auto-coordination is on or off.
* chase-distance-m --
* control-mode --
* current-view
* description --
* flight-model --
* frame-rate --
* freeze
* hud
* input
* instrumentation
* instrument-options
* intl
* logging
* model-hz --
* multiplay
* panel
* presets
* rendering
* sound
* speed-up --
* startup/
** fullscreen
** game-mode
** intro-music
** options/
*** airport
*** heading-deg
*** latitude-deg
*** longitude-deg
*** runway
** path-cache/
** save-on-exit
** season
** splash-alpha
** splash-progress
** splash-progress-text
** splash-screen
** splash-texture
** splash-title
** stderr-to-terminal
** stdout-to-terminal
** terminal-ansi-colors
** time-offset
** time-offset-type
** units
** xsize
** ysize
* status --
* time
* view-mode --
* menubar/
* model/
* mouse/
* navdb/
* number-views = '6' (int)
* replay/
* sceneryloaded = 'true' (bool)
* submodels/
* systems/
* temp/
* tower/
* traffic-manager/
* user/
* view/
* view[1]/
* view[2]/
* view[3]/
* view[4]/
* view[5]/
* virtual-cockpit = 'false' (bool)

==== surface-positions/ ====
==== systems/ ====
==== velocities/ ====
<nowiki>
</nowiki>
[http://www.beispiel.de Link-Text]
[[Media:Beispiel.mp3]]
[[Image:Beispiel.jpg]]
fgfs --aircraft=(beispiel-737)

[[Category:List]]

Improving Glider Realism

2009-04-27T09:35:17Z

B21: added some trial breadcrumbs...

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:Developer |Development portal]] >> Improving Glider Realism

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-27T09:32:19Z

B21: /* Gliders */

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> Dev portal >> Improving Glider Realism

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-22T20:53:13Z

B21: /* Ridgelift */ added link to forum thread

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-22T16:48:57Z

B21: /* Gauges */ flight computer

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

File:Glider flight computer.jpg

2009-04-22T16:43:04Z

B21: screenshot of a simulated SDI C4 on the panel of the Aerosoft Discus

screenshot of a simulated SDI C4 on the panel of the Aerosoft Discus

Improving Glider Realism

2009-04-22T16:34:23Z

B21: /* Variometer */ typo

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-22T16:32:56Z

B21: /* Gauges */ added functional detail on each type of vario

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external.jpg]]

[[Image:Ask21 external2.jpg]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The ASK21 panel is displayed below - functional but a bit sparse compared to real gliders:

[[Image:Ask 21 cockpit.jpg]]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated
** = (change in kinetic energy / (mass x G))
** = (0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)
** = (v2^2 - v1^2) / 2G where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer ''but'' and even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-22T16:13:51Z

B21: /* Glider cockpit 3D models */ added screenshot of ASK21 panel

Improving Glider Realism

2009-04-22T16:11:14Z

B21: /* Glider external 3D models */ another ask21 external view

File:Ask21 external2.jpg

2009-04-22T16:09:35Z

B21: screenshot of ASK21 external view

screenshot of ASK21 external view

File:Ask 21 cockpit.jpg

2009-04-22T16:08:12Z

B21: screenshot of ASK21 interior panel view

screenshot of ASK21 interior panel view

Improving Glider Realism

2009-04-22T15:56:27Z

B21: /* Glider external 3D models */ ASK21 image

File:Ask21 external.jpg

2009-04-22T15:54:53Z

B21: thumbnail external image of the ASK21 glider from the aircraft package

thumbnail external image of the ASK21 glider from the aircraft package

Improving Glider Realism

2009-04-20T22:54:29Z

B21: /* Variometer */ gave formula for TE reading

Improving Glider Realism

2009-04-20T11:44:00Z

B21: /* IGC file logger */ everytrail.com and gpsvisualizer.com links

Improving Glider Realism

2009-04-20T11:41:03Z

B21: /* Improving Glider Realism */ removed duplicate header

Improving Glider Realism

2009-04-19T20:58:26Z

B21: /* Variometer */

= Improving Glider Realism =

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too.

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear).

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-19T20:53:44Z

B21: /* Variometer */

= Improving Glider Realism =

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too.

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear).

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

==== Variometer ====
[[Image:http://upload.wikimedia.org/wikipedia/en/e/ed/Cair-Xk10-vario.jpg]]

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-19T20:52:11Z

B21: /* Gauges */

Improving Glider Realism

2009-04-19T20:26:50Z

B21: /* Glider cockpit 3D models */

Improving Glider Realism

2009-04-19T20:19:51Z

B21: /* Glider external 3D models */

Improving Glider Realism

2009-04-19T20:18:42Z

B21: /* Flight Model */

Improving Glider Realism

2009-04-19T19:09:28Z

B21: /* IGC file logger */ - sample file

Soaring

2009-04-19T18:56:06Z

B21:

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism|developers page]].

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Soaring

2009-04-19T18:55:35Z

B21: link to Improving_Glider_Realism

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.) See also the [[Improving_Glider_Realism developers page]].

== Winch Launches ==

Winch launches are currently available with the [[SZD-9bis Bocian-1E|Bocian]] and [[Schleicher ASK 21|ASK21]]. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==
[[Image:Pinzgauer.jpg|thumb|right| [[Schleicher ASK 21]] gliding in the [[Pinzgauer Spaziergang]] thermals scenario]]

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Improving Glider Realism

2009-04-19T18:52:08Z

B21: link to Soaring page

Improving Glider Realism

2009-04-19T18:50:06Z

B21: /* Ridgelift */

= Improving Glider Realism =

This section lists the areas that have a significant impact on soaring realism.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

=== Glider external 3D models ===

=== Glider cockpit 3D models ===

=== Gauges ===

==== Variometer ====

==== IGC file logger ====

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

Improving Glider Realism

2009-04-19T18:44:36Z

B21:

= Improving Glider Realism =

This section lists the areas that have a significant impact on soaring realism.

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

=== Glider external 3D models ===

=== Glider cockpit 3D models ===

=== Gauges ===

==== Variometer ====

==== IGC file logger ====

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.