FlightGear wiki - User contributions [en]

Earthview

2019-08-02T11:10:11Z

Chris blues: note-box - finally!

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{Note|1=You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files via torrent with this magnet link:
magnet:?xt=urn:btih:ffd18abf3bd98ee761babc09d7c901ea1ce0c78f&dn=EarthView%20-%20Complete

Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.

Earthview

2019-08-02T10:59:13Z

Chris blues: Try to get this %?$§# note-box working... :-/

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{note|You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files via torrent with this magnet link:
magnet:?xt=urn:btih:ffd18abf3bd98ee761babc09d7c901ea1ce0c78f&dn=EarthView%20-%20Complete
Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview
}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.

Earthview

2019-08-02T10:57:05Z

Chris blues: Remove links to musicchris.de and add torrent/magnet link

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{note|You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files via torrent with this magnet link:
magnet:?xt=urn:btih:ffd18abf3bd98ee761babc09d7c901ea1ce0c78f&dn=EarthView%20-%20Complete
Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.

Cessna 550 Citation II

2017-07-04T08:15:41Z

Chris blues: /* Overview */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists and tutorials
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
{{#tag:syntaxhighlight |
$ {{fgaddon co|Citation|post=Citation}}
$ svn up
| lang="bash"
}}

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
==== will be released with 2017.2 ====
* Tutorials have been added.
* A new menu item is in place. The '''Citation II config''' dialog is available under menu -> Citation II -> Citation II config. It contains options for saving through sessions, some display options and several shortcuts for easy access to tutorials, help and more.
* New support for [[State_Overlay_System|state overlays]]. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 MHz with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

FlightGear Newsletter April 2017

2017-05-29T12:25:31Z

Chris blues:

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>

{{Newsletter-cover-header|In the hangar}}<br>
[[#Updates to the Citation II|Updates to the Citation II]]<br>
[[#Updates to the ERCO Ercoupe|Updates to the ERCO Ercoupe]]
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or <code>menu -> help -> tutorials</code>.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* '''parking''' ( cold and dark, all systems off) (same as without --state=$state )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

=== Updates to the ERCO Ercoupe ===
[[File:Ercoupe-cockpit.jpg|thumb|right|The improved ERCO Ercoupe cockpit]]
After the discussion in the mailing list about possibly adding the [[Ercoupe 415-C|Ercoupe]] as a second default aircraft for the novice users the Ercoupe has had a considerable upgrade:
* The FDM has been improved
* Reflection effects are added to the fuselage
* Reflection and shadow effects are added to the cockpit
* Cockpit panel and instruments have been improved
* Textures have been improved
* A number of new liveries were added
* Functional navigation lights were added

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].

|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
FlightGear's Screenshot of the Month April 2016 is ''Early Morning Coffee'' by {{usr|Icecode|Icecode GL}}
[[File:777 over Malaga.jpg|900px|center|Early Morning Coffee]]

If you want to participate in the screenshot contest of May 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=32163 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=32163#p310086 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of May 2017.

[[Category:FlightGear Newsletter|2017 04]]
[[Category:Changes after 2017.1]]

[[De:FlightGear Newsletter April 2017]]

FlightGear Newsletter April 2017

2017-05-22T14:40:49Z

Chris blues: remove mapgear from index also

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>

{{Newsletter-cover-header|In the hangar}}<br>
<small>[[#Updates to the Citation II|Updates to the Citation II]]</small><br>
<small>[[#Updates to the ERCO Ercoupe|Updates to the ERCO Ercoupe]]</small>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* '''parking''' ( cold and dark, all systems off) (same as without --state=$state )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

=== Updates to the ERCO Ercoupe ===
[[File:Ercoupe-cockpit.jpg|thumb|right|The improved ERCO Ercoupe cockpit]]
After the discussion in the mailing list about possibly adding the [[Ercoupe 415-C|Ercoupe]] as a second default aircraft for the novice users the Ercoupe has had a considerable upgrade:
* The FDM has been improved
* Reflection effects are added to the fuselage
* Reflection and shadow effects are added to the cockpit
* Cockpit panel and instruments have been improved
* Textures have been improved
* A number of new liveries were added
* Functional navigation lights were added

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].

|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
FlightGear's Screenshot of the Month May 2016 is ''Early Morning Coffee'' by {{usr|Icecode|Icecode GL}}
[[File:777 over Malaga.jpg|900px|center|Early Morning Coffee]]

If you want to participate in the screenshot contest of May 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=32163 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=32163#p310086 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of May 2017.

[[Category:FlightGear Newsletter|2017 04]]
[[Category:Changes after 2017.1]]

FlightGear Newsletter April 2017

2017-05-22T06:37:37Z

Chris blues: add mapgear is out to index, and change bold heading font to actual heading

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>
<small>[[#MapGear is out!|MapGear is out!]]</small><br>
{{Newsletter-cover-header|In the hangar}}<br>
<small>[[#Updates to the Citation II|Updates to the Citation II]]</small><br>
<small>[[#Updates to the ERCO Ercoupe|Updates to the ERCO Ercoupe]]</small>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

===MapGear is out!===

MapGear.py is a mapping tool for FlightGear that saves the flight path as an animated .GIF.

The aim is to create a nice map projection/animation for any log file submitted. For this to happen a
good degree of numerical tunning is required so the more feedback the project has from users the better.
Feedback would be greatly appreciated!

So far, the program seems to be stable enough so it is worth of publishing here in the FlightGear Newsletter.

It consists of a small python script and a few Geo information data files taken from NaturalEarth.

Stay tuned via the announcement page:
https://forum.flightgear.org/viewtopic.php?f=6&t=31741

Screenshot:
[img]http://i.imgur.com/cUuza9l.gif[/img]

Licensed under the GPLv2+

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* '''parking''' ( cold and dark, all systems off) (same as without --state=$state )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

=== Updates to the ERCO Ercoupe ===
[[File:Ercoupe-cockpit.jpg|thumb|right|The improved ERCO Ercoupe cockpit]]
After the discussion in the mailing list about possibly adding the Ercoupe as a second default aircraft for the novice users the Ercoupe has had a considerable upgrade:
* The FDM has been improved
* Reflection effects are added to the fuselage
* Reflection and shadow effects are added to the cockpit
* Cockpit panel and instruments have been improved
* Textures have been improved
* A number of new liveries were added
* Functional navigation lights were added

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].

|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
FlightGear's Screenshot of the Month May 2016 is ''Early Morning Coffee'' by {{usr|Icecode|Icecode GL}}
[[File:777 over Malaga.jpg|900px|center|Early Morning Coffee]]

If you want to participate in the screenshot contest of May 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=32163 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=32163#p310086 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of May 2017.

[[Category:FlightGear Newsletter|2017 04]]
[[Category:Changes after 2017.1]]

FlightGear Newsletter April 2017

2017-05-22T06:33:39Z

Chris blues: Add aircraft updates to the index (Citation + Ercoupe)

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>
{{Newsletter-cover-header|In the hangar}}<br>
<small>[[#Updates to the Citation II|Updates to the Citation II]]</small><br>
<small>[[#Updates to the ERCO Ercoupe|Updates to the ERCO Ercoupe]]</small>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

'''MapGear is out!'''

MapGear.py is a mapping tool for FlightGear that saves the flight path as an animated .GIF.

The aim is to create a nice map projection/animation for any log file submitted. For this to happen a
good degree of numerical tunning is required so the more feedback the project has from users the better.
Feedback would be greatly appreciated!

So far, the program seems to be stable enough so it is worth of publishing here in the FlightGear Newsletter.

It consists of a small python script and a few Geo information data files taken from NaturalEarth.

Stay tuned via the announcement page:
https://forum.flightgear.org/viewtopic.php?f=6&t=31741

Screenshot:
[img]http://i.imgur.com/cUuza9l.gif[/img]

Licensed under the GPLv2+

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* '''parking''' ( cold and dark, all systems off) (same as without --state=$state )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

=== Updates to the ERCO Ercoupe ===
[[File:Ercoupe-cockpit.jpg|thumb|right|The improved ERCO Ercoupe cockpit]]
After the discussion in the mailing list about possibly adding the Ercoupe as a second default aircraft for the novice users the Ercoupe has had a considerable upgrade:
* The FDM has been improved
* Reflection effects are added to the fuselage
* Reflection and shadow effects are added to the cockpit
* Cockpit panel and instruments have been improved
* Textures have been improved
* A number of new liveries were added
* Functional navigation lights were added

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].

|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
FlightGear's Screenshot of the Month May 2016 is ''Early Morning Coffee'' by {{usr|Icecode|Icecode GL}}
[[File:777 over Malaga.jpg|900px|center|Early Morning Coffee]]

If you want to participate in the screenshot contest of May 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=32163 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=32163#p310086 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of May 2017.

[[Category:FlightGear Newsletter|2017 04]]
[[Category:Changes after 2017.1]]

FlightGear Newsletter April 2017

2017-04-04T17:40:04Z

Chris blues: /* state overlays */ formatting

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>
{{Newsletter-cover-header|In the hangar}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* '''parking''' ( cold and dark, all systems off) (same as without --state=$state )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [ this]  forum topic. Be sure to see the [ first post]  for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page. -->

FlightGear Newsletter April 2017

2017-04-04T17:37:58Z

Chris blues: /* In the hangar */ formatting

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>
{{Newsletter-cover-header|In the hangar}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* parking ( cold and dark, all systems off) (same as without --state=$state )
* taxi ( engines and all systems running - ready to taxi )
* take-off ( flaps and AP set - just throttle up and go )
* cruise ( flying at FL360 on AP )
* approach ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [ this]  forum topic. Be sure to see the [ first post]  for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page. -->

FlightGear Newsletter April 2017

2017-04-04T17:31:20Z

Chris blues: /* In the hangar */ Add new features of Citation II

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter March 2017]].}} 

{{Newsletter-header|April 2017}} 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>
{{Newsletter-cover-header|In the hangar}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

== In the hangar ==
=== Updates to the Citation II ===
During March 2017 the [[Cessna_550_Citation_II|Citation II]] has received a number of updates:
==== Citation II config dialog ====
One of the more prominent ones is the new Citation config dialog. It allows for settings, such as, what group of items you want to be stored throughout sessions. Also, for convenience, it provides some shortcuts to most used dialogs and a button to reset all circuit-breakers at once.

Check it out in sim via <code>menu -> Citation II -> Citation II config</code>.

==== tutorials ====
Also 2 [[Tutorials|tutorials]] have been added in the [[Boeing_707-420|707]] style - with markers, view zoom and explicit messages. See the Citation II config dialog or menu -> help -> tutorials.

==== state overlays ====
It is now possible to start the Citation II in some assorted [[State_Overlay_System|states]]. You could start FG on a parking space and add <code>--state=parking</code> to startup the Citation cold and dark. This would be a good place to start the startup tutorial from the config dialog.

Or you could start on the runway and add <code>--state=take-off</code> to your launcher. All you need to do is throttle up and go! Or take the tutorial "take-off" from the config dialog, which will guide you savely to cruise altitude, according to official checklists.

All possible states are:
* parking ( cold and dark, all systems off) (same as without --state=$state )
* taxi ( engines and all systems running - ready to taxi )
* take-off ( flaps and AP set - just throttle up and go )
* cruise ( flying at FL360 on AP )
* approach ( !experimental! )
For details see: [[Cessna_550_Citation_II#will_be_released_with_2017.2|Citation II]]

==== new splash screen system ====
James has added a new splash screen scheme, as well as a new preview feature for the [[FlightGear_Qt_launcher|QT launcher]]. The Citation II now complies with that scheme and provides a new logo and some brand-new splash screens.

== Scenery corner ==

== Community news ==

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [ this]  forum topic. Be sure to see the [ first post]  for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page. -->

Howto:Implement wing flex

2017-03-25T06:58:52Z

Chris blues: Add Citation II to the list of implementations

[[File:747-400_wing_flex.jpg|thumb|270px|Wing flex as seen on the [[Boeing 747-400]].]]

'''Wing flex''' is the flexing of wings on [[aircraft]], due to lift and fuselage load. [[FlightGear]] is able to show realistic wing flex. Currently the [[Boeing 787]], [[Airbus A330-200|A330-200]], [[Boeing 747-400|747-400]], [[Cessna_550_Citation_II|Citation II]] and [[Bombardier CRJ-900|CRJ-900]] are equipped with flexing wings.

This article describes a simple approach to model static wing flex. Using this approach, the wing will bend realistically under load, but it will not oscillate after load changes, e.g., on hard touchdown. For a more sophisticated model for dynamic wing flex, please see the [[Wingflexer|Wingflexer article]].

== Model ==
A few edits have to be made to the aircraft model. Each wing has to be cut into multiple sections. The more sections, the smoother the wing flex. Be carefull that you do not cut through flaps or engines. Naming our wing sections, from fuselage to wing tip: wing.1, wing.2 and wing.3.

Measure the coordinates of the start of each new wing section, you will need them to animate the wings.

== Animation ==
The following lines have to be added to the aircraft model .xml file. These lines are used with three wing sections, and a [[JSBSim]] [[FDM]].

<syntaxhighlight lang="xml">
<animation>
<type>rotate</type>
<object-name>LeftWing.1</object-name>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-4.00</y-m>
<z-m>-1.70</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-8.00</y-m>
<z-m>-1.50</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-12.25</y-m>
<z-m> -1.25</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>
</syntaxhighlight>

You probably need to add a lot more objects to each section (like engines, flaps, ailerons etc.) and also change the ''center'' coordinates according to your aircraft. For the right wing, just change the sign of the center <y-m> coordinate and the factor value.

=== JSBSim ===
[[JSBSim]] calculates the lift force of the aircraft. The lift reacts on the G-forces, the velocity and turbulences. The respective property is: <tt>fdm/jsbsim/aero/coefficient/CLalpha</tt>

=== YASim ===
[[YASim]] does not calculate wingflex as nice as JSBSim, but a pretty realistic effect can be reached by using the <tt>accelerations/pilot-g[0]</tt> property instead.

== Related content ==
* [[Wingflexer]] – A newer way to add wing flex, though it still need to be animated much like here

[[es:Howto: Implement wing flex]]
[[Category:Aircraft enhancement|Implement wing flex]]
[[Category:Howto|Implement wing flex]]

Cessna 550 Citation II

2017-03-22T14:55:49Z

Chris blues: /* Recently updated */ new additions to the changelog: tutorials and config dialog

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
{{#tag:syntaxhighlight |
$ {{fgaddon co|Citation|post=Citation}}
$ svn up
| lang="bash"
}}

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
==== will be released with 2017.2 ====
* Tutorials have been added.
* A new menu item is in place. The '''Citation II config''' dialog is available under menu -> Citation II -> Citation II config. It contains options for saving through sessions, some display options and several shortcuts for easy access to tutorials, help and more.
* New support for [[State_Overlay_System|state overlays]]. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 MHz with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Autopilot configuration reference

2017-03-19T13:26:40Z

Chris blues: /* Adding an autopilot configuration */

{{Systems_Modeling_Disclaimer}}

[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]

{{forum|46|Autopilot & Route Manager}}
{{Autoflight Navigation}}

: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''

The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.

This page serves as a reference for the elements of [[FlightGear]] XML [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.

For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).

== Autopilot vs. property-rule configurations ==
The main difference between XML based autopilot and property-rule systems is the update rate:

* Autopilot configurations run at [[FDM]] rate
* Property-rule configurations run at frame rate

=== Performance considerations ===
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.

It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.

For example would a fly-by-wire flight control system element augmenting an unstable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.

== Adding a configuration to an aircraft ==
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code><Aircraft>-set.xml</code> file.

=== Adding an autopilot configuration ===
Autopilot configuration files are added to the aircraft by adding

<syntaxhighlight lang="xml">
<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</syntaxhighlight>

to the

<syntaxhighlight lang="xml">
<sim>
<systems>

<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</systems>
</sim>
</syntaxhighlight>

node of your <code>aircraft-set.xml</code> file. Note, that more than one <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <syntaxhighlight lang="xml" inline><systems></syntaxhighlight>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.

{{note|While the above seems to be the recommended standard, it has occasionally lead to trouble, not to index additional autopilot configurations. Anyway, it shouldn't hurt to do so.<br>
FG first loads generic configs, which get indexed atomatically as they appear. Then you override these generic configs with your own, which may lead to strange behaviour, if you for example overwrite the weather rules with an autopilot-helper configuration. Not only will you have no weather anymore, but also 2 systems that will most likely overwrite each others results all the time. Check the property-tree at /sim/systems/autopilot[*]
}}

=== Adding a property-rule configuration ===
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)

To achieve this load your filters configuration by adding:

<syntaxhighlight lang="xml">
<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</syntaxhighlight>
(Do NOT use the filename "propertyrules.xml")

to the :

<syntaxhighlight lang="xml">
<sim>
<systems>

<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</systems>
</sim>
</syntaxhighlight>

node of your <code><aircraft>-set.xml</code> file. Note that you can add multiple <syntaxhighlight lang="xml" inline><property-rule></syntaxhighlight> elements, similar to the <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> as described above.

{{tip|Configurations can be enabled and disabled through the boolean properties <code>/sim/systems/autopilot[''n'']/serviceable</code> and <code>/sim/systems/property-rule[''n'']/serviceable</code>, where''n'' is the index for a configuration}}

== Structure of a configuration file ==
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <syntaxhighlight lang="xml" inline><PropertyList></syntaxhighlight> node as a root element. A basic skeleton file looks like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params include="MyParams.xml"> 
<controls>
<aileron>controls/flight/aileron</aileron>
<rudder>controls/flight/rudder</rudder>
<elevator>controls/flight/elevator</elevator>
</controls>
</params>



</PropertyList>
</syntaxhighlight>

The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.

{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.

For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}

{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}

== Available elements ==
All elements may contain the attributes "include" and "alias".
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <syntaxhighlight lang="xml" inline><foo alias="/params/bar/baz"/></syntaxhighlight>. Use the colon to move through the document tree, similar to file system paths like <syntaxhighlight lang="xml" inline><foo alias="../../bar/baz"/></syntaxhighlight>.

Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:
* <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><filter></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><predict-simple></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><logic></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><flipflop></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><state-machine></syntaxhighlight>

== Common elements used by all elements ==

=== Name of filter and controller <name> ===
The <syntaxhighlight lang="xml" inline><name></syntaxhighlight> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.

<syntaxhighlight lang="xml">
<name>NAV hold</name>
</syntaxhighlight>

=== Feedback <feedback-if-disabled> ===
The <syntaxhighlight lang="xml" inline><feedback-if-disabled></syntaxhighlight> element advises the controller to feed back the output property value to the active input property if the condition defined in the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight> within this element results in feedback disabled.

<syntaxhighlight lang="xml">
<feedback-if-disabled>true</feedback-if-disabled>
</syntaxhighlight>

=== Printing debug output <debug> ===
If the <syntaxhighlight lang="xml" inline><debug></syntaxhighlight> element is present and if it contains the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight>, the containing controller prints out some diagnostic information on the console for each processing loop.

<syntaxhighlight lang="xml">
<debug>true</debug>
</syntaxhighlight>

=== Input and reference properties or values <input> and <reference> ===
Each controller has two input "lines", denoted by the tags <syntaxhighlight lang="xml" inline><input></syntaxhighlight> and <syntaxhighlight lang="xml" inline><reference></syntaxhighlight>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.

Example for a simple differential amplifier, computing output = (input-reference)*2

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>1.0</gain>
<input>/some/input</input>
<reference>/some/output</reference>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Output property <output> ===
The <syntaxhighlight lang="xml" inline><output></syntaxhighlight> element names the properties, the computed value should be written to. More than one <syntaxhighlight lang="xml" inline><output></syntaxhighlight> may be present, each named property will be assigned the computed value.

<syntaxhighlight lang="xml">
<output>controls/flight/elevator</output>
</syntaxhighlight>

=== Enabling and disabling a filter <enable> ===
Controllers can be enabled or disabled using property values. This element <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> may contain a <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> and a <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element to the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> element. This <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> follows the same syntactical rules as the one used in model animations and can model complex expression trees.
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition

<syntaxhighlight lang="xml">
<enable>
<condition>
<less-than>
<property>orientation/bank-angle-deg</property>
<value>30.0</value>
</less-than>
<greater-than>
<property>orientation/bank-angle-deg</property>
<value>-30.0</value>
</greater-than>
</condition>
</enable>
</syntaxhighlight>

=== Input values ===
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element as an example but it may be substituted by any other input element like <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>, <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> etc. Input values will be interpreted as double values.

==== A constant value <value> or <reference> ====
A constant value is defined by just adding the value as text to the input element:

<syntaxhighlight lang="xml">
<reference>
<value>3.5</value>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:

<syntaxhighlight lang="xml">
<reference>3.5</reference>
</syntaxhighlight>

If the text can be parsed by <code>strtod()</code> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)

==== A property value ====
To evaluate the value of a property, place the name of the property into the text element:

<syntaxhighlight lang="xml">
<reference>
<property>/my/property</property>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:
<syntaxhighlight lang="xml">
<reference>/my/property</reference>
</syntaxhighlight>

{{note|The shortcut syntax is only valid, if neither <syntaxhighlight lang="xml" inline><property></syntaxhighlight> nor <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exists.
If both <syntaxhighlight lang="xml" inline><property></syntaxhighlight> '''and''' <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exist, the property will be initialized with the given value with scale and offset applied correctly.
Properties don't have to exist, the will be created as needed.}}

{{note|For backward compatibility, the notation <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> instead of <syntaxhighlight lang="xml" inline><property></syntaxhighlight> is also valid but considered deprecated and might go away in future releases.}}

==== Linear transformation of the input value <offset> ====
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt>
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
</reference>
</syntaxhighlight>

==== Periodical transformation of the input value <period> ====
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.

<syntaxhighlight lang="xml">
<reference>
<property>/orientation/heading-deg</property>
<period>
<min>-180.0</min>
<max>180.0</max>
</period>
</reference>
</syntaxhighlight>

==== Input clamping <min> and <max> ====
To clamp the input to a minimum value, maximum value or both, the tags <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.

The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
<min>60</min>
<max>80</max>
</reference>
</syntaxhighlight>

==== Absolute values <abs> ====
To use the absolute (unsigned) value of the input, add <syntaxhighlight lang="xml" inline><abs type="bool">true</abs></syntaxhighlight>.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<abs type="bool">true</abs>
</reference>
</syntaxhighlight>

==== Recursive definition ====
The elements <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<scale>2.0</scale>
<offset>
<property>orientation/bank-angle-deg</property>
<scale>
<property>some/property
<min>-1.5</min>
<max>1.5</max>
</scale>
</offset>
</reference>
</syntaxhighlight>

==== Conditional input values <condition> ====
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.

<syntaxhighlight lang="xml">
<reference>
<condition>
<property>/autopilot/coupled-to-gps</property>
</condition>
<property>instrumentation/gps/desired-track-deg</property>
</reference>
<reference>
<condition>
<property>/autopilot/coupled-to-nav2</property>
</condition>
<property>instrumentation/nav[1]/radials/selected-deg</property>
</reference>
<reference>instrumentation/nav[0]/radials/selected-deg</reference>
</syntaxhighlight>

Note the unconditional last <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.

The <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements of input values itself currently don't support input value lists.

==== Expressions <expression> ====
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <syntaxhighlight lang="xml" inline><expression></syntaxhighlight> tag.

=== Output values ===
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <syntaxhighlight lang="xml" inline><period></syntaxhighlight> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value.

{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}

The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:

{| class="prettytable"
! computed !! written
|-
| -350 || 10
|-
| -270 || 30
|-
| -90 || -30
|-
| -29 || -29
|-
| 29 || 29
|-
| 90 || 30
|-
| 350 || -10
|}

<syntaxhighlight lang="xml">
<output>/some/property</output>
<period>
<min>-180</min>
<max>180</max>
</period>
<min>-30</min>
<max>30</max>
</syntaxhighlight>

This example shows how to use a table to vary an output with height. At sea level, the output is 0.045, at 22400 the output is 0.1196, and at 56000 ft the output is 0.7

<syntaxhighlight lang="xml">
<filter>
<name>GAy</name>
<debug>false</debug>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/instrumentation/altimeter/indicated-altitude-ft</property>
<entry><ind>0.0</ind><dep>0.045</dep></entry>
<entry><ind>22400</ind><dep>0.1196</dep></entry>
<entry><ind>56000</ind><dep>0.7</dep></entry>
</table>
</expression>
</input>
<output>
<property>/autopilot/gain/GAy</property>
</output>
</filter>
</syntaxhighlight>

== Logic controller <logic> ==
The logic controller provides a simple way of creating property values from the result of the condition expression in the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <syntaxhighlight lang="xml" inline><inverted></syntaxhighlight> element inverts the logic. The default is "not inverted".

Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )

<syntaxhighlight lang="xml">
<logic>
<inverted>true</inverted>
<input>
<property>a</property>
<or>
<greater-than>
<property>b</property>
<property>c</property>
</greater-than>
<property>d</property>
</or>
</input>
<output>output</output>
</logic>
</syntaxhighlight>

== Flip flop logic <flipflop> ==
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.
All input lines, including the clock line, are encoded as condition constructs.
If negative logic for the input line is required, wrap the condition into a <syntaxhighlight lang="xml" inline><not></syntaxhighlight> tag to invert the logic.

{{note|The type, for example '''RS''', is case sensitive.}}
{{note|Using <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> tags will break the logic.}}

=== RS flip flop <RS> ===
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<syntaxhighlight lang="xml" inline><type>RS</type></syntaxhighlight>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<syntaxhighlight lang="xml" inline><type>SR</type></syntaxhighlight>) has a dominant set line and the output gets set if set and reset line are set.

Example: simple RS flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>RS</type> 
<S>
<property>/myflipflop/set</property>
</S>
<R>
<property>/myflipflop/reset</property>
</R>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== JK flip flop <JK> ===
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occur immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.
If no clock signal is provided, the frame rate serves as the clock input.

Example: simple JK flip flop with negative edge clock

<syntaxhighlight lang="xml">
<flipflop>
<type>JK</type>
<J>
<property>/myflipflop/set</property>
</J>
<K>
<property>/myflipflop/reset</property>
</K>
<clock>
<not>
<property>/myflipflop/clock</property>
</not>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== D flip flop <D> ===
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple D flip flop with inverted output

<syntaxhighlight lang="xml">
<flipflop>
<type>D</type>
<D>
<property>/myflipflop/data</property>
</D>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
<inverted type="bool">true</inverted>
</flipflop>
</syntaxhighlight>

=== T flip flop <T> ===
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple T flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>T</type>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== Monostable flip flop <monostable> ===
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory.

The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <syntaxhighlight lang="xml" inline><time></syntaxhighlight> element.

{{note|The optional <syntaxhighlight lang="xml" inline><R></syntaxhighlight> and <syntaxhighlight lang="xml" inline><K></syntaxhighlight> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<time>
<property>/myflipflop/pulsetime-sec</property>
<value>10</value>
</time>
<S><property>/myflipflop/s</property></S>
<J><property>/myflipflop/j</property></J>
<clock><property>/myflipflop/clock</property></clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<inverted type="bool">true</inverted>
<S>
<not>
<property>/myflipflop/s</property>
</not>
</S>
<time>
<value>10.0</value>
</time>
<output>
<property>/myflipflop/output</property>
</output>
</flipflop>
</syntaxhighlight>

In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.

== Filters <filter> ==

=== Pure gain filter <gain> ===
A gain filter multiplies the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> value by a given factor or gain <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> and returns the output to <syntaxhighlight lang="xml" inline><output></syntaxhighlight>. More than one <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> evaluating as true the first <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> will define the used gain.

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>6.28</gain>
<input>radius</input>
<output>circumfence</output>
</filter>
</syntaxhighlight>

=== First order low pass filter <exponential> ===
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic Euler number and the associated mathematical function exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).

Example: a 1Hz first order low pass filter

<syntaxhighlight lang="xml">
<filter>
<type>exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Second order low pass filter <double-exponential> ===
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter.

The configuration is the same for exponential and double-exponential filters, just the type entry differs.

<syntaxhighlight lang="xml">
<filter>
<type>double-exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/<output>
</filter>
</syntaxhighlight>

=== First order high pass filter <high-pass> ===
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter

Example: a 1Hz first order high pass filter

<syntaxhighlight lang="xml">
<filter>
<type>high-pass</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Lead-Lag filter <lead-lag> ===
The lead-lag filter is a typical [https://en.wikipedia.org/wiki/Lead%E2%80%93lag_compensator] lead lag filter. As the name implies it is a combination of a lead (high-pass) filter and a lag (low-pass) filter.

Example: a lead lag filter k(s+a)/s+b).
The gain is k, filter-time-a is a, and filter-time-b is b.

In an autopilot is is often used to sharpen up the response to an input.

<syntaxhighlight lang="xml">
<filter>
<name>loc-deg leadlag</name>
<debug>false</debug>
<type>lead-lag</type>
<gain>5</gain>
<filter-time-a>5.0</filter-time-a>
<filter-time-b>1.0</filter-time-b>
<input>
<property>/autopilot/internal/loc-deg</property>
</input>
<output>
<property>/autopilot/internal/loc-deg-leadlag</property>
</output>
</filter>
</syntaxhighlight>

=== Integrator filter <lead-lag> ===
The integrator filter provides integration with time.

Example: an integrator filter k(1/s).

In this example, the normal input (<syntaxhighlight lang="xml" inline><property>/autopilot/internal/p-deg_sec</property></syntaxhighlight>)is disconnected and replaved by (output x 10) input when relay Rb is closed. This has the effect of rapidly ramping the integrator output to zero.

<syntaxhighlight lang="xml">
<filter>
<name>synthetic bank from roll rate</name>
<debug>false</debug>
<type>integrator</type>
<gain>1.0</gain>
<input>
<condition>
<property>/autopilot/internal/Rb</property>
</condition>
<property>/autopilot/internal/p-deg_sec</property>
</input>
<input> 
<expression>
<product>
<value>-10.0</value>
<property>/autopilot/internal/phi-deg_synth</property>
</product>
</expression>
</input>
<output>
<property>/autopilot/internal/phi-deg_synth</property>
</output>
<u_min>-180</u_min>
<u_max>180</u_max>
</filter>
</syntaxhighlight>

=== Moving average filter <moving-average> ===
Calculates average of specified number of values.

Currently the average length can only be given as number of samples and not time.

<syntaxhighlight lang="xml">
<filter>
<type>moving-average</type>
<samples>120</samples>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Rate limit filter <noise-spike> ===
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <syntaxhighlight lang="xml" inline><max-rate-of-change></syntaxhighlight> setting the maximum rate of change of the output property per second.

Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.

<syntaxhighlight lang="xml">
<filter>
<type>noise-spike</type>
<max-rate-of-change>0.5</max-rate-of-change>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Reciprocal filter <reciprocal> ===
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element may be used to scale the value. Output computes as gain divided by input.

Example: compute the flight time per pound of burned fuel from the fuel flow

<syntaxhighlight lang="xml">
<filter>
<type>reciprocal</type>
<gain>1.0</gain>
<input>/engines/engine[0]/fuel-flow-pph</input>
<output>/engines/engine[0]/fuel-flow-hpp</output>
</filter>
</syntaxhighlight>

=== Derivative filter <derivative> ===
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> acts as gain and must be given because it has default 0.

Example: compute derivative of static port pressure

<syntaxhighlight lang="xml">
<filter>
<type>derivative</type>
<input>systems/static[0]/pressure-inhg</input>
<output>autopilot/internal/pressure-rate</output>
<filter-time>1.0</filter-time>
</filter>
</syntaxhighlight>

== PID controller <pid-controller> ==
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <syntaxhighlight lang="xml" inline><max></syntaxhighlight> and <syntaxhighlight lang="xml" inline><min></syntaxhighlight> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.

The xml element creating a pid controller is <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| The overall gain for the proportional, integral and derivative part
|-
! <syntaxhighlight lang="xml" inline><Ti></syntaxhighlight>
| Integrator time
|-
! <syntaxhighlight lang="xml" inline><Td></syntaxhighlight>
| Derivator time
|-
! <syntaxhighlight lang="xml" inline><Ts></syntaxhighlight>
| Sampling interval (default: sample at frame rate)
|-
! <syntaxhighlight lang="xml" inline><alpha></syntaxhighlight>
| Scaling factor for Td (defaults to 0.1)
|-
! <syntaxhighlight lang="xml" inline><beta></syntaxhighlight>
| Reference weighing factor for the proportional component (defaults to 1.0)
|-
! <syntaxhighlight lang="xml" inline><gamma></syntaxhighlight>
| Reference weighing factor for the derivate component (defaults to 0.0)
|}

== PI controller <pi-simple-controller> ==
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements are present.
The xml element creating a PI controller is <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| Gain of the proportional component
|-
! <syntaxhighlight lang="xml" inline><Ki></syntaxhighlight>
| Gain of the integrator component
|}

== Predictor <predict-simple> ==
Estimates the future value for a given property based on its current (or averaged) rate of change.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><seconds></syntaxhighlight>
| The time to be estimated ahead
|-
! <syntaxhighlight lang="xml" inline><filter-gain></syntaxhighlight>
| Smoothing factor (0.0-1.0, 1.0=no smoothing)
|}

Example: compute estimated speed 5 seconds ahead

<syntaxhighlight lang="xml">
<predict-simple>
<name>predicted air speed 5 seconds ahead</name>
<debug>false</debug>
<input>velocities/airspeed-kt</input>
<output>autopilot/internal/airspeed-5-sec-ahead</output>
<seconds>5.0</seconds>
<filter-gain>0.1</filter-gain>
</predict-simple>
</syntaxhighlight>

== State Machine <state-machine> ==
For a description of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].

{{note|Current behaviour with enter, exit and update tags differs from this documentation. Refer to the developer mailing list [https://sourceforge.net/p/flightgear/mailman/message/35557652/] before implementing bindings in state machines.}}

<syntaxhighlight lang="xml">
<state-machine>
<branch>/my-statemachine</branch>
<state>
<name>init</name>
<enter>
<binding></binding>
<binding></binding>
</enter>
<exit>
<binding></binding>
</exit>
<update>
<binding></binding>
</update>
</state>
<state>
<name>finished</name>
<enter>Zero to many bindings, fired upon state enter</enter>
<exit>Zero to many bindings, fired upon state exit</exit>
<update>Zero to many bindings, fired upon every state change</update>
</state>
<transition>
<name>ready</name>
<source>init</source>
<target>finished</target>
<exclude-target type="bool">true</exclude-target>
<condition>
<greater-than>
<property>/sim/time/elapsed-sec</property>
<value>30</value>
</greater-than>
</condition>
<binding>Zero to many bindings, fired upon state change</binding>
</transition>
</state-machine>
</syntaxhighlight>

Legal elements for the state machine are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><branch></syntaxhighlight>
| A path to a property node where the internal states of the machine gets written to. Can be empty.
|-
! <syntaxhighlight lang="xml" inline><state></syntaxhighlight>
| Two ore more state elements are required for a minimal state machine
|-
! <syntaxhighlight lang="xml" inline><transition></syntaxhighlight>
| Any number of transition elements. Describes how to change from one state to another.
|}

Legal elements for the state element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the state a name for reference
|-
! <syntaxhighlight lang="xml" inline><enter></syntaxhighlight>
| Optional, zero to many enter elements containing a SGBinding to fire upon state enter
|-
! <syntaxhighlight lang="xml" inline><exit></syntaxhighlight>
| Optional, zero to many exit elements containing a SGBinding to fire upon state exit
|-
! <syntaxhighlight lang="xml" inline><update></syntaxhighlight>
| Optional, zero to many update elements containing a SGBinding to fire upon state change
|}

Legal elements for the transition element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the transition a name for reference
|-
! <syntaxhighlight lang="xml" inline><source></syntaxhighlight>
| Optional, zero to many source elements containing the name of a source state. If no source state is definied, this transition applies to all states.
|-
! <syntaxhighlight lang="xml" inline><target></syntaxhighlight>
| Required, exactly one target element defining the target state
|-
! <syntaxhighlight lang="xml" inline><condition></syntaxhighlight>
| Required, contains a SGCondition when this state change occours
|-
! <syntaxhighlight lang="xml" inline><exclude-target></syntaxhighlight>
| Optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target
|-
! <syntaxhighlight lang="xml" inline><binding></syntaxhighlight>
| Optional, zero to many binding elements containing a SGBinding to fire when this transition triggers
|}

== Proposed extensions ==
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.

=== Expose to Nasal ===
Given that Nasal is a widely-known bottleneck, people should not use it for implement FDM/AP or route-manager functionality in scripting space. However, for the time being, the underlying C++ code is not exposed to scripting space, so that aircraft developers tend to reinvent the wheel. Thus, it would make sense to expose the AP/property-rule/state machine subsystems to scripting space using the [[Nasal/CppBind]] framework, to ensure that existing C++ code can be used for such purposes:

{{FGCquote
|1= I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=149376#p149376
| title = <nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
| author = <nowiki>Torsten</nowiki>
| date = Feb 2nd, 2012
}}
}}

== Related content ==
=== Wiki articles ===
* [[Autopilot PID controller tuning resources]]
* [[Howto:Design an autopilot]]
* [[Howto:Implement a Fly-By-Wire System for Airliners]]

=== Readme file ===
* {{readme file|digitalfilters}}

=== Source code ===
* {{flightgear source|src/Autopilot/digitalfilter.hxx}}
* {{flightgear source|src/Autopilot/autopilot.cxx}}

[[Category:Aircraft enhancement]]

Autopilot configuration reference

2017-03-19T13:25:35Z

Chris blues: /* Adding a configuration to an aircraft */ Add note why some autopilot configs have certain indices, and some not.

{{Systems_Modeling_Disclaimer}}

[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]

{{forum|46|Autopilot & Route Manager}}
{{Autoflight Navigation}}

: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''

The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.

This page serves as a reference for the elements of [[FlightGear]] XML [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.

For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).

== Autopilot vs. property-rule configurations ==
The main difference between XML based autopilot and property-rule systems is the update rate:

* Autopilot configurations run at [[FDM]] rate
* Property-rule configurations run at frame rate

=== Performance considerations ===
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.

It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.

For example would a fly-by-wire flight control system element augmenting an unstable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.

== Adding a configuration to an aircraft ==
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code><Aircraft>-set.xml</code> file.

=== Adding an autopilot configuration ===
Autopilot configuration files are added to the aircraft by adding

<syntaxhighlight lang="xml">
<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</syntaxhighlight>

to the

<syntaxhighlight lang="xml">
<sim>
<systems>

<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</systems>
</sim>
</syntaxhighlight>

node of your <code>aircraft-set.xml</code> file. Note, that more than one <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <syntaxhighlight lang="xml" inline><systems></syntaxhighlight>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.

{{note|While the above seems to be the recommended standard, it has occasionally lead to trouble, not to index additional autopilot configurations. Anyway, it shouldn't hurt to do so.<br>
FG first loads generic configs, which get indexed atomatically as they appear. Then you override these generic configs with your own, which may lead to strange behaviour, if you for example overwrite the weather rules with an autopilot-helper configuration. Not only will you have no weather anymore, but also 2 systems that will most likely overwrite each others results all the time. Check the property-tree at <code>/sim/systems/autopilot[*]<code>}}

=== Adding a property-rule configuration ===
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)

To achieve this load your filters configuration by adding:

<syntaxhighlight lang="xml">
<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</syntaxhighlight>
(Do NOT use the filename "propertyrules.xml")

to the :

<syntaxhighlight lang="xml">
<sim>
<systems>

<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</systems>
</sim>
</syntaxhighlight>

node of your <code><aircraft>-set.xml</code> file. Note that you can add multiple <syntaxhighlight lang="xml" inline><property-rule></syntaxhighlight> elements, similar to the <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> as described above.

{{tip|Configurations can be enabled and disabled through the boolean properties <code>/sim/systems/autopilot[''n'']/serviceable</code> and <code>/sim/systems/property-rule[''n'']/serviceable</code>, where''n'' is the index for a configuration}}

== Structure of a configuration file ==
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <syntaxhighlight lang="xml" inline><PropertyList></syntaxhighlight> node as a root element. A basic skeleton file looks like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params include="MyParams.xml"> 
<controls>
<aileron>controls/flight/aileron</aileron>
<rudder>controls/flight/rudder</rudder>
<elevator>controls/flight/elevator</elevator>
</controls>
</params>



</PropertyList>
</syntaxhighlight>

The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.

{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.

For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}

{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}

== Available elements ==
All elements may contain the attributes "include" and "alias".
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <syntaxhighlight lang="xml" inline><foo alias="/params/bar/baz"/></syntaxhighlight>. Use the colon to move through the document tree, similar to file system paths like <syntaxhighlight lang="xml" inline><foo alias="../../bar/baz"/></syntaxhighlight>.

Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:
* <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><filter></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><predict-simple></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><logic></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><flipflop></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><state-machine></syntaxhighlight>

== Common elements used by all elements ==

=== Name of filter and controller <name> ===
The <syntaxhighlight lang="xml" inline><name></syntaxhighlight> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.

<syntaxhighlight lang="xml">
<name>NAV hold</name>
</syntaxhighlight>

=== Feedback <feedback-if-disabled> ===
The <syntaxhighlight lang="xml" inline><feedback-if-disabled></syntaxhighlight> element advises the controller to feed back the output property value to the active input property if the condition defined in the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight> within this element results in feedback disabled.

<syntaxhighlight lang="xml">
<feedback-if-disabled>true</feedback-if-disabled>
</syntaxhighlight>

=== Printing debug output <debug> ===
If the <syntaxhighlight lang="xml" inline><debug></syntaxhighlight> element is present and if it contains the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight>, the containing controller prints out some diagnostic information on the console for each processing loop.

<syntaxhighlight lang="xml">
<debug>true</debug>
</syntaxhighlight>

=== Input and reference properties or values <input> and <reference> ===
Each controller has two input "lines", denoted by the tags <syntaxhighlight lang="xml" inline><input></syntaxhighlight> and <syntaxhighlight lang="xml" inline><reference></syntaxhighlight>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.

Example for a simple differential amplifier, computing output = (input-reference)*2

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>1.0</gain>
<input>/some/input</input>
<reference>/some/output</reference>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Output property <output> ===
The <syntaxhighlight lang="xml" inline><output></syntaxhighlight> element names the properties, the computed value should be written to. More than one <syntaxhighlight lang="xml" inline><output></syntaxhighlight> may be present, each named property will be assigned the computed value.

<syntaxhighlight lang="xml">
<output>controls/flight/elevator</output>
</syntaxhighlight>

=== Enabling and disabling a filter <enable> ===
Controllers can be enabled or disabled using property values. This element <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> may contain a <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> and a <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element to the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> element. This <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> follows the same syntactical rules as the one used in model animations and can model complex expression trees.
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition

<syntaxhighlight lang="xml">
<enable>
<condition>
<less-than>
<property>orientation/bank-angle-deg</property>
<value>30.0</value>
</less-than>
<greater-than>
<property>orientation/bank-angle-deg</property>
<value>-30.0</value>
</greater-than>
</condition>
</enable>
</syntaxhighlight>

=== Input values ===
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element as an example but it may be substituted by any other input element like <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>, <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> etc. Input values will be interpreted as double values.

==== A constant value <value> or <reference> ====
A constant value is defined by just adding the value as text to the input element:

<syntaxhighlight lang="xml">
<reference>
<value>3.5</value>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:

<syntaxhighlight lang="xml">
<reference>3.5</reference>
</syntaxhighlight>

If the text can be parsed by <code>strtod()</code> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)

==== A property value ====
To evaluate the value of a property, place the name of the property into the text element:

<syntaxhighlight lang="xml">
<reference>
<property>/my/property</property>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:
<syntaxhighlight lang="xml">
<reference>/my/property</reference>
</syntaxhighlight>

{{note|The shortcut syntax is only valid, if neither <syntaxhighlight lang="xml" inline><property></syntaxhighlight> nor <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exists.
If both <syntaxhighlight lang="xml" inline><property></syntaxhighlight> '''and''' <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exist, the property will be initialized with the given value with scale and offset applied correctly.
Properties don't have to exist, the will be created as needed.}}

{{note|For backward compatibility, the notation <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> instead of <syntaxhighlight lang="xml" inline><property></syntaxhighlight> is also valid but considered deprecated and might go away in future releases.}}

==== Linear transformation of the input value <offset> ====
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt>
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
</reference>
</syntaxhighlight>

==== Periodical transformation of the input value <period> ====
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.

<syntaxhighlight lang="xml">
<reference>
<property>/orientation/heading-deg</property>
<period>
<min>-180.0</min>
<max>180.0</max>
</period>
</reference>
</syntaxhighlight>

==== Input clamping <min> and <max> ====
To clamp the input to a minimum value, maximum value or both, the tags <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.

The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
<min>60</min>
<max>80</max>
</reference>
</syntaxhighlight>

==== Absolute values <abs> ====
To use the absolute (unsigned) value of the input, add <syntaxhighlight lang="xml" inline><abs type="bool">true</abs></syntaxhighlight>.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<abs type="bool">true</abs>
</reference>
</syntaxhighlight>

==== Recursive definition ====
The elements <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<scale>2.0</scale>
<offset>
<property>orientation/bank-angle-deg</property>
<scale>
<property>some/property
<min>-1.5</min>
<max>1.5</max>
</scale>
</offset>
</reference>
</syntaxhighlight>

==== Conditional input values <condition> ====
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.

<syntaxhighlight lang="xml">
<reference>
<condition>
<property>/autopilot/coupled-to-gps</property>
</condition>
<property>instrumentation/gps/desired-track-deg</property>
</reference>
<reference>
<condition>
<property>/autopilot/coupled-to-nav2</property>
</condition>
<property>instrumentation/nav[1]/radials/selected-deg</property>
</reference>
<reference>instrumentation/nav[0]/radials/selected-deg</reference>
</syntaxhighlight>

Note the unconditional last <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.

The <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements of input values itself currently don't support input value lists.

==== Expressions <expression> ====
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <syntaxhighlight lang="xml" inline><expression></syntaxhighlight> tag.

=== Output values ===
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <syntaxhighlight lang="xml" inline><period></syntaxhighlight> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value.

{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}

The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:

{| class="prettytable"
! computed !! written
|-
| -350 || 10
|-
| -270 || 30
|-
| -90 || -30
|-
| -29 || -29
|-
| 29 || 29
|-
| 90 || 30
|-
| 350 || -10
|}

<syntaxhighlight lang="xml">
<output>/some/property</output>
<period>
<min>-180</min>
<max>180</max>
</period>
<min>-30</min>
<max>30</max>
</syntaxhighlight>

This example shows how to use a table to vary an output with height. At sea level, the output is 0.045, at 22400 the output is 0.1196, and at 56000 ft the output is 0.7

<syntaxhighlight lang="xml">
<filter>
<name>GAy</name>
<debug>false</debug>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/instrumentation/altimeter/indicated-altitude-ft</property>
<entry><ind>0.0</ind><dep>0.045</dep></entry>
<entry><ind>22400</ind><dep>0.1196</dep></entry>
<entry><ind>56000</ind><dep>0.7</dep></entry>
</table>
</expression>
</input>
<output>
<property>/autopilot/gain/GAy</property>
</output>
</filter>
</syntaxhighlight>

== Logic controller <logic> ==
The logic controller provides a simple way of creating property values from the result of the condition expression in the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <syntaxhighlight lang="xml" inline><inverted></syntaxhighlight> element inverts the logic. The default is "not inverted".

Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )

<syntaxhighlight lang="xml">
<logic>
<inverted>true</inverted>
<input>
<property>a</property>
<or>
<greater-than>
<property>b</property>
<property>c</property>
</greater-than>
<property>d</property>
</or>
</input>
<output>output</output>
</logic>
</syntaxhighlight>

== Flip flop logic <flipflop> ==
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.
All input lines, including the clock line, are encoded as condition constructs.
If negative logic for the input line is required, wrap the condition into a <syntaxhighlight lang="xml" inline><not></syntaxhighlight> tag to invert the logic.

{{note|The type, for example '''RS''', is case sensitive.}}
{{note|Using <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> tags will break the logic.}}

=== RS flip flop <RS> ===
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<syntaxhighlight lang="xml" inline><type>RS</type></syntaxhighlight>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<syntaxhighlight lang="xml" inline><type>SR</type></syntaxhighlight>) has a dominant set line and the output gets set if set and reset line are set.

Example: simple RS flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>RS</type> 
<S>
<property>/myflipflop/set</property>
</S>
<R>
<property>/myflipflop/reset</property>
</R>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== JK flip flop <JK> ===
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occur immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.
If no clock signal is provided, the frame rate serves as the clock input.

Example: simple JK flip flop with negative edge clock

<syntaxhighlight lang="xml">
<flipflop>
<type>JK</type>
<J>
<property>/myflipflop/set</property>
</J>
<K>
<property>/myflipflop/reset</property>
</K>
<clock>
<not>
<property>/myflipflop/clock</property>
</not>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== D flip flop <D> ===
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple D flip flop with inverted output

<syntaxhighlight lang="xml">
<flipflop>
<type>D</type>
<D>
<property>/myflipflop/data</property>
</D>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
<inverted type="bool">true</inverted>
</flipflop>
</syntaxhighlight>

=== T flip flop <T> ===
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple T flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>T</type>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== Monostable flip flop <monostable> ===
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory.

The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <syntaxhighlight lang="xml" inline><time></syntaxhighlight> element.

{{note|The optional <syntaxhighlight lang="xml" inline><R></syntaxhighlight> and <syntaxhighlight lang="xml" inline><K></syntaxhighlight> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<time>
<property>/myflipflop/pulsetime-sec</property>
<value>10</value>
</time>
<S><property>/myflipflop/s</property></S>
<J><property>/myflipflop/j</property></J>
<clock><property>/myflipflop/clock</property></clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<inverted type="bool">true</inverted>
<S>
<not>
<property>/myflipflop/s</property>
</not>
</S>
<time>
<value>10.0</value>
</time>
<output>
<property>/myflipflop/output</property>
</output>
</flipflop>
</syntaxhighlight>

In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.

== Filters <filter> ==

=== Pure gain filter <gain> ===
A gain filter multiplies the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> value by a given factor or gain <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> and returns the output to <syntaxhighlight lang="xml" inline><output></syntaxhighlight>. More than one <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> evaluating as true the first <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> will define the used gain.

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>6.28</gain>
<input>radius</input>
<output>circumfence</output>
</filter>
</syntaxhighlight>

=== First order low pass filter <exponential> ===
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic Euler number and the associated mathematical function exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).

Example: a 1Hz first order low pass filter

<syntaxhighlight lang="xml">
<filter>
<type>exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Second order low pass filter <double-exponential> ===
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter.

The configuration is the same for exponential and double-exponential filters, just the type entry differs.

<syntaxhighlight lang="xml">
<filter>
<type>double-exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/<output>
</filter>
</syntaxhighlight>

=== First order high pass filter <high-pass> ===
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter

Example: a 1Hz first order high pass filter

<syntaxhighlight lang="xml">
<filter>
<type>high-pass</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Lead-Lag filter <lead-lag> ===
The lead-lag filter is a typical [https://en.wikipedia.org/wiki/Lead%E2%80%93lag_compensator] lead lag filter. As the name implies it is a combination of a lead (high-pass) filter and a lag (low-pass) filter.

Example: a lead lag filter k(s+a)/s+b).
The gain is k, filter-time-a is a, and filter-time-b is b.

In an autopilot is is often used to sharpen up the response to an input.

<syntaxhighlight lang="xml">
<filter>
<name>loc-deg leadlag</name>
<debug>false</debug>
<type>lead-lag</type>
<gain>5</gain>
<filter-time-a>5.0</filter-time-a>
<filter-time-b>1.0</filter-time-b>
<input>
<property>/autopilot/internal/loc-deg</property>
</input>
<output>
<property>/autopilot/internal/loc-deg-leadlag</property>
</output>
</filter>
</syntaxhighlight>

=== Integrator filter <lead-lag> ===
The integrator filter provides integration with time.

Example: an integrator filter k(1/s).

In this example, the normal input (<syntaxhighlight lang="xml" inline><property>/autopilot/internal/p-deg_sec</property></syntaxhighlight>)is disconnected and replaved by (output x 10) input when relay Rb is closed. This has the effect of rapidly ramping the integrator output to zero.

<syntaxhighlight lang="xml">
<filter>
<name>synthetic bank from roll rate</name>
<debug>false</debug>
<type>integrator</type>
<gain>1.0</gain>
<input>
<condition>
<property>/autopilot/internal/Rb</property>
</condition>
<property>/autopilot/internal/p-deg_sec</property>
</input>
<input> 
<expression>
<product>
<value>-10.0</value>
<property>/autopilot/internal/phi-deg_synth</property>
</product>
</expression>
</input>
<output>
<property>/autopilot/internal/phi-deg_synth</property>
</output>
<u_min>-180</u_min>
<u_max>180</u_max>
</filter>
</syntaxhighlight>

=== Moving average filter <moving-average> ===
Calculates average of specified number of values.

Currently the average length can only be given as number of samples and not time.

<syntaxhighlight lang="xml">
<filter>
<type>moving-average</type>
<samples>120</samples>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Rate limit filter <noise-spike> ===
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <syntaxhighlight lang="xml" inline><max-rate-of-change></syntaxhighlight> setting the maximum rate of change of the output property per second.

Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.

<syntaxhighlight lang="xml">
<filter>
<type>noise-spike</type>
<max-rate-of-change>0.5</max-rate-of-change>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Reciprocal filter <reciprocal> ===
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element may be used to scale the value. Output computes as gain divided by input.

Example: compute the flight time per pound of burned fuel from the fuel flow

<syntaxhighlight lang="xml">
<filter>
<type>reciprocal</type>
<gain>1.0</gain>
<input>/engines/engine[0]/fuel-flow-pph</input>
<output>/engines/engine[0]/fuel-flow-hpp</output>
</filter>
</syntaxhighlight>

=== Derivative filter <derivative> ===
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> acts as gain and must be given because it has default 0.

Example: compute derivative of static port pressure

<syntaxhighlight lang="xml">
<filter>
<type>derivative</type>
<input>systems/static[0]/pressure-inhg</input>
<output>autopilot/internal/pressure-rate</output>
<filter-time>1.0</filter-time>
</filter>
</syntaxhighlight>

== PID controller <pid-controller> ==
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <syntaxhighlight lang="xml" inline><max></syntaxhighlight> and <syntaxhighlight lang="xml" inline><min></syntaxhighlight> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.

The xml element creating a pid controller is <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| The overall gain for the proportional, integral and derivative part
|-
! <syntaxhighlight lang="xml" inline><Ti></syntaxhighlight>
| Integrator time
|-
! <syntaxhighlight lang="xml" inline><Td></syntaxhighlight>
| Derivator time
|-
! <syntaxhighlight lang="xml" inline><Ts></syntaxhighlight>
| Sampling interval (default: sample at frame rate)
|-
! <syntaxhighlight lang="xml" inline><alpha></syntaxhighlight>
| Scaling factor for Td (defaults to 0.1)
|-
! <syntaxhighlight lang="xml" inline><beta></syntaxhighlight>
| Reference weighing factor for the proportional component (defaults to 1.0)
|-
! <syntaxhighlight lang="xml" inline><gamma></syntaxhighlight>
| Reference weighing factor for the derivate component (defaults to 0.0)
|}

== PI controller <pi-simple-controller> ==
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements are present.
The xml element creating a PI controller is <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| Gain of the proportional component
|-
! <syntaxhighlight lang="xml" inline><Ki></syntaxhighlight>
| Gain of the integrator component
|}

== Predictor <predict-simple> ==
Estimates the future value for a given property based on its current (or averaged) rate of change.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><seconds></syntaxhighlight>
| The time to be estimated ahead
|-
! <syntaxhighlight lang="xml" inline><filter-gain></syntaxhighlight>
| Smoothing factor (0.0-1.0, 1.0=no smoothing)
|}

Example: compute estimated speed 5 seconds ahead

<syntaxhighlight lang="xml">
<predict-simple>
<name>predicted air speed 5 seconds ahead</name>
<debug>false</debug>
<input>velocities/airspeed-kt</input>
<output>autopilot/internal/airspeed-5-sec-ahead</output>
<seconds>5.0</seconds>
<filter-gain>0.1</filter-gain>
</predict-simple>
</syntaxhighlight>

== State Machine <state-machine> ==
For a description of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].

{{note|Current behaviour with enter, exit and update tags differs from this documentation. Refer to the developer mailing list [https://sourceforge.net/p/flightgear/mailman/message/35557652/] before implementing bindings in state machines.}}

<syntaxhighlight lang="xml">
<state-machine>
<branch>/my-statemachine</branch>
<state>
<name>init</name>
<enter>
<binding></binding>
<binding></binding>
</enter>
<exit>
<binding></binding>
</exit>
<update>
<binding></binding>
</update>
</state>
<state>
<name>finished</name>
<enter>Zero to many bindings, fired upon state enter</enter>
<exit>Zero to many bindings, fired upon state exit</exit>
<update>Zero to many bindings, fired upon every state change</update>
</state>
<transition>
<name>ready</name>
<source>init</source>
<target>finished</target>
<exclude-target type="bool">true</exclude-target>
<condition>
<greater-than>
<property>/sim/time/elapsed-sec</property>
<value>30</value>
</greater-than>
</condition>
<binding>Zero to many bindings, fired upon state change</binding>
</transition>
</state-machine>
</syntaxhighlight>

Legal elements for the state machine are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><branch></syntaxhighlight>
| A path to a property node where the internal states of the machine gets written to. Can be empty.
|-
! <syntaxhighlight lang="xml" inline><state></syntaxhighlight>
| Two ore more state elements are required for a minimal state machine
|-
! <syntaxhighlight lang="xml" inline><transition></syntaxhighlight>
| Any number of transition elements. Describes how to change from one state to another.
|}

Legal elements for the state element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the state a name for reference
|-
! <syntaxhighlight lang="xml" inline><enter></syntaxhighlight>
| Optional, zero to many enter elements containing a SGBinding to fire upon state enter
|-
! <syntaxhighlight lang="xml" inline><exit></syntaxhighlight>
| Optional, zero to many exit elements containing a SGBinding to fire upon state exit
|-
! <syntaxhighlight lang="xml" inline><update></syntaxhighlight>
| Optional, zero to many update elements containing a SGBinding to fire upon state change
|}

Legal elements for the transition element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the transition a name for reference
|-
! <syntaxhighlight lang="xml" inline><source></syntaxhighlight>
| Optional, zero to many source elements containing the name of a source state. If no source state is definied, this transition applies to all states.
|-
! <syntaxhighlight lang="xml" inline><target></syntaxhighlight>
| Required, exactly one target element defining the target state
|-
! <syntaxhighlight lang="xml" inline><condition></syntaxhighlight>
| Required, contains a SGCondition when this state change occours
|-
! <syntaxhighlight lang="xml" inline><exclude-target></syntaxhighlight>
| Optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target
|-
! <syntaxhighlight lang="xml" inline><binding></syntaxhighlight>
| Optional, zero to many binding elements containing a SGBinding to fire when this transition triggers
|}

== Proposed extensions ==
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.

=== Expose to Nasal ===
Given that Nasal is a widely-known bottleneck, people should not use it for implement FDM/AP or route-manager functionality in scripting space. However, for the time being, the underlying C++ code is not exposed to scripting space, so that aircraft developers tend to reinvent the wheel. Thus, it would make sense to expose the AP/property-rule/state machine subsystems to scripting space using the [[Nasal/CppBind]] framework, to ensure that existing C++ code can be used for such purposes:

{{FGCquote
|1= I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=149376#p149376
| title = <nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
| author = <nowiki>Torsten</nowiki>
| date = Feb 2nd, 2012
}}
}}

== Related content ==
=== Wiki articles ===
* [[Autopilot PID controller tuning resources]]
* [[Howto:Design an autopilot]]
* [[Howto:Implement a Fly-By-Wire System for Airliners]]

=== Readme file ===
* {{readme file|digitalfilters}}

=== Source code ===
* {{flightgear source|src/Autopilot/digitalfilter.hxx}}
* {{flightgear source|src/Autopilot/autopilot.cxx}}

[[Category:Aircraft enhancement]]

Autopilot configuration reference

2017-03-18T21:16:25Z

Chris blues: /* Adding an autopilot configuration */

{{Systems_Modeling_Disclaimer}}

[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]

{{forum|46|Autopilot & Route Manager}}
{{Autoflight Navigation}}

: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''

The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.

This page serves as a reference for the elements of [[FlightGear]] XML [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.

For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).

== Autopilot vs. property-rule configurations ==
The main difference between XML based autopilot and property-rule systems is the update rate:

* Autopilot configurations run at [[FDM]] rate
* Property-rule configurations run at frame rate

=== Performance considerations ===
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.

It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.

For example would a fly-by-wire flight control system element augmenting an unstable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.

== Adding a configuration to an aircraft ==
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code><Aircraft>-set.xml</code> file.

=== Adding an autopilot configuration ===
Autopilot configuration files are added to the aircraft by adding

<syntaxhighlight lang="xml">
<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</syntaxhighlight>

to the

<syntaxhighlight lang="xml">
<sim>
<systems>

<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</systems>
</sim>
</syntaxhighlight>

node of your <code>aircraft-set.xml</code> file. Note, that more than one <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <syntaxhighlight lang="xml" inline><systems></syntaxhighlight>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.

{{note|While the above seems to be the recommended standard, it has occasionally lead to trouble, not to index the autopilot configurations. Anyway, it shouldn't hurt to do so.}}

=== Adding a property-rule configuration ===
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)

To achieve this load your filters configuration by adding:

<syntaxhighlight lang="xml">
<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</syntaxhighlight>
(Do NOT use the filename "propertyrules.xml")

to the :

<syntaxhighlight lang="xml">
<sim>
<systems>

<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</systems>
</sim>
</syntaxhighlight>

node of your <code><aircraft>-set.xml</code> file. Note that you can add multiple <syntaxhighlight lang="xml" inline><property-rule></syntaxhighlight> elements, similar to the <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> as described above.

{{tip|Configurations can be enabled and disabled through the boolean properties <code>/sim/systems/autopilot[''n'']/serviceable</code> and <code>/sim/systems/property-rule[''n'']/serviceable</code>, where''n'' is the index for a configuration}}

== Structure of a configuration file ==
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <syntaxhighlight lang="xml" inline><PropertyList></syntaxhighlight> node as a root element. A basic skeleton file looks like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params include="MyParams.xml"> 
<controls>
<aileron>controls/flight/aileron</aileron>
<rudder>controls/flight/rudder</rudder>
<elevator>controls/flight/elevator</elevator>
</controls>
</params>



</PropertyList>
</syntaxhighlight>

The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.

{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.

For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}

{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}

== Available elements ==
All elements may contain the attributes "include" and "alias".
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <syntaxhighlight lang="xml" inline><foo alias="/params/bar/baz"/></syntaxhighlight>. Use the colon to move through the document tree, similar to file system paths like <syntaxhighlight lang="xml" inline><foo alias="../../bar/baz"/></syntaxhighlight>.

Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:
* <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><filter></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><predict-simple></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><logic></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><flipflop></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><state-machine></syntaxhighlight>

== Common elements used by all elements ==

=== Name of filter and controller <name> ===
The <syntaxhighlight lang="xml" inline><name></syntaxhighlight> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.

<syntaxhighlight lang="xml">
<name>NAV hold</name>
</syntaxhighlight>

=== Feedback <feedback-if-disabled> ===
The <syntaxhighlight lang="xml" inline><feedback-if-disabled></syntaxhighlight> element advises the controller to feed back the output property value to the active input property if the condition defined in the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight> within this element results in feedback disabled.

<syntaxhighlight lang="xml">
<feedback-if-disabled>true</feedback-if-disabled>
</syntaxhighlight>

=== Printing debug output <debug> ===
If the <syntaxhighlight lang="xml" inline><debug></syntaxhighlight> element is present and if it contains the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight>, the containing controller prints out some diagnostic information on the console for each processing loop.

<syntaxhighlight lang="xml">
<debug>true</debug>
</syntaxhighlight>

=== Input and reference properties or values <input> and <reference> ===
Each controller has two input "lines", denoted by the tags <syntaxhighlight lang="xml" inline><input></syntaxhighlight> and <syntaxhighlight lang="xml" inline><reference></syntaxhighlight>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.

Example for a simple differential amplifier, computing output = (input-reference)*2

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>1.0</gain>
<input>/some/input</input>
<reference>/some/output</reference>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Output property <output> ===
The <syntaxhighlight lang="xml" inline><output></syntaxhighlight> element names the properties, the computed value should be written to. More than one <syntaxhighlight lang="xml" inline><output></syntaxhighlight> may be present, each named property will be assigned the computed value.

<syntaxhighlight lang="xml">
<output>controls/flight/elevator</output>
</syntaxhighlight>

=== Enabling and disabling a filter <enable> ===
Controllers can be enabled or disabled using property values. This element <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> may contain a <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> and a <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element to the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> element. This <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> follows the same syntactical rules as the one used in model animations and can model complex expression trees.
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition

<syntaxhighlight lang="xml">
<enable>
<condition>
<less-than>
<property>orientation/bank-angle-deg</property>
<value>30.0</value>
</less-than>
<greater-than>
<property>orientation/bank-angle-deg</property>
<value>-30.0</value>
</greater-than>
</condition>
</enable>
</syntaxhighlight>

=== Input values ===
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element as an example but it may be substituted by any other input element like <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>, <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> etc. Input values will be interpreted as double values.

==== A constant value <value> or <reference> ====
A constant value is defined by just adding the value as text to the input element:

<syntaxhighlight lang="xml">
<reference>
<value>3.5</value>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:

<syntaxhighlight lang="xml">
<reference>3.5</reference>
</syntaxhighlight>

If the text can be parsed by <code>strtod()</code> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)

==== A property value ====
To evaluate the value of a property, place the name of the property into the text element:

<syntaxhighlight lang="xml">
<reference>
<property>/my/property</property>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:
<syntaxhighlight lang="xml">
<reference>/my/property</reference>
</syntaxhighlight>

{{note|The shortcut syntax is only valid, if neither <syntaxhighlight lang="xml" inline><property></syntaxhighlight> nor <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exists.
If both <syntaxhighlight lang="xml" inline><property></syntaxhighlight> '''and''' <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exist, the property will be initialized with the given value with scale and offset applied correctly.
Properties don't have to exist, the will be created as needed.}}

{{note|For backward compatibility, the notation <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> instead of <syntaxhighlight lang="xml" inline><property></syntaxhighlight> is also valid but considered deprecated and might go away in future releases.}}

==== Linear transformation of the input value <offset> ====
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt>
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
</reference>
</syntaxhighlight>

==== Periodical transformation of the input value <period> ====
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.

<syntaxhighlight lang="xml">
<reference>
<property>/orientation/heading-deg</property>
<period>
<min>-180.0</min>
<max>180.0</max>
</period>
</reference>
</syntaxhighlight>

==== Input clamping <min> and <max> ====
To clamp the input to a minimum value, maximum value or both, the tags <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.

The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
<min>60</min>
<max>80</max>
</reference>
</syntaxhighlight>

==== Absolute values <abs> ====
To use the absolute (unsigned) value of the input, add <syntaxhighlight lang="xml" inline><abs type="bool">true</abs></syntaxhighlight>.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<abs type="bool">true</abs>
</reference>
</syntaxhighlight>

==== Recursive definition ====
The elements <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<scale>2.0</scale>
<offset>
<property>orientation/bank-angle-deg</property>
<scale>
<property>some/property
<min>-1.5</min>
<max>1.5</max>
</scale>
</offset>
</reference>
</syntaxhighlight>

==== Conditional input values <condition> ====
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.

<syntaxhighlight lang="xml">
<reference>
<condition>
<property>/autopilot/coupled-to-gps</property>
</condition>
<property>instrumentation/gps/desired-track-deg</property>
</reference>
<reference>
<condition>
<property>/autopilot/coupled-to-nav2</property>
</condition>
<property>instrumentation/nav[1]/radials/selected-deg</property>
</reference>
<reference>instrumentation/nav[0]/radials/selected-deg</reference>
</syntaxhighlight>

Note the unconditional last <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.

The <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements of input values itself currently don't support input value lists.

==== Expressions <expression> ====
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <syntaxhighlight lang="xml" inline><expression></syntaxhighlight> tag.

=== Output values ===
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <syntaxhighlight lang="xml" inline><period></syntaxhighlight> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value.

{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}

The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:

{| class="prettytable"
! computed !! written
|-
| -350 || 10
|-
| -270 || 30
|-
| -90 || -30
|-
| -29 || -29
|-
| 29 || 29
|-
| 90 || 30
|-
| 350 || -10
|}

<syntaxhighlight lang="xml">
<output>/some/property</output>
<period>
<min>-180</min>
<max>180</max>
</period>
<min>-30</min>
<max>30</max>
</syntaxhighlight>

This example shows how to use a table to vary an output with height. At sea level, the output is 0.045, at 22400 the output is 0.1196, and at 56000 ft the output is 0.7

<syntaxhighlight lang="xml">
<filter>
<name>GAy</name>
<debug>false</debug>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/instrumentation/altimeter/indicated-altitude-ft</property>
<entry><ind>0.0</ind><dep>0.045</dep></entry>
<entry><ind>22400</ind><dep>0.1196</dep></entry>
<entry><ind>56000</ind><dep>0.7</dep></entry>
</table>
</expression>
</input>
<output>
<property>/autopilot/gain/GAy</property>
</output>
</filter>
</syntaxhighlight>

== Logic controller <logic> ==
The logic controller provides a simple way of creating property values from the result of the condition expression in the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <syntaxhighlight lang="xml" inline><inverted></syntaxhighlight> element inverts the logic. The default is "not inverted".

Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )

<syntaxhighlight lang="xml">
<logic>
<inverted>true</inverted>
<input>
<property>a</property>
<or>
<greater-than>
<property>b</property>
<property>c</property>
</greater-than>
<property>d</property>
</or>
</input>
<output>output</output>
</logic>
</syntaxhighlight>

== Flip flop logic <flipflop> ==
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.
All input lines, including the clock line, are encoded as condition constructs.
If negative logic for the input line is required, wrap the condition into a <syntaxhighlight lang="xml" inline><not></syntaxhighlight> tag to invert the logic.

{{note|The type, for example '''RS''', is case sensitive.}}
{{note|Using <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> tags will break the logic.}}

=== RS flip flop <RS> ===
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<syntaxhighlight lang="xml" inline><type>RS</type></syntaxhighlight>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<syntaxhighlight lang="xml" inline><type>SR</type></syntaxhighlight>) has a dominant set line and the output gets set if set and reset line are set.

Example: simple RS flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>RS</type> 
<S>
<property>/myflipflop/set</property>
</S>
<R>
<property>/myflipflop/reset</property>
</R>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== JK flip flop <JK> ===
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occur immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.
If no clock signal is provided, the frame rate serves as the clock input.

Example: simple JK flip flop with negative edge clock

<syntaxhighlight lang="xml">
<flipflop>
<type>JK</type>
<J>
<property>/myflipflop/set</property>
</J>
<K>
<property>/myflipflop/reset</property>
</K>
<clock>
<not>
<property>/myflipflop/clock</property>
</not>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== D flip flop <D> ===
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple D flip flop with inverted output

<syntaxhighlight lang="xml">
<flipflop>
<type>D</type>
<D>
<property>/myflipflop/data</property>
</D>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
<inverted type="bool">true</inverted>
</flipflop>
</syntaxhighlight>

=== T flip flop <T> ===
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple T flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>T</type>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== Monostable flip flop <monostable> ===
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory.

The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <syntaxhighlight lang="xml" inline><time></syntaxhighlight> element.

{{note|The optional <syntaxhighlight lang="xml" inline><R></syntaxhighlight> and <syntaxhighlight lang="xml" inline><K></syntaxhighlight> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<time>
<property>/myflipflop/pulsetime-sec</property>
<value>10</value>
</time>
<S><property>/myflipflop/s</property></S>
<J><property>/myflipflop/j</property></J>
<clock><property>/myflipflop/clock</property></clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<inverted type="bool">true</inverted>
<S>
<not>
<property>/myflipflop/s</property>
</not>
</S>
<time>
<value>10.0</value>
</time>
<output>
<property>/myflipflop/output</property>
</output>
</flipflop>
</syntaxhighlight>

In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.

== Filters <filter> ==

=== Pure gain filter <gain> ===
A gain filter multiplies the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> value by a given factor or gain <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> and returns the output to <syntaxhighlight lang="xml" inline><output></syntaxhighlight>. More than one <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> evaluating as true the first <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> will define the used gain.

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>6.28</gain>
<input>radius</input>
<output>circumfence</output>
</filter>
</syntaxhighlight>

=== First order low pass filter <exponential> ===
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic Euler number and the associated mathematical function exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).

Example: a 1Hz first order low pass filter

<syntaxhighlight lang="xml">
<filter>
<type>exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Second order low pass filter <double-exponential> ===
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter.

The configuration is the same for exponential and double-exponential filters, just the type entry differs.

<syntaxhighlight lang="xml">
<filter>
<type>double-exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/<output>
</filter>
</syntaxhighlight>

=== First order high pass filter <high-pass> ===
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter

Example: a 1Hz first order high pass filter

<syntaxhighlight lang="xml">
<filter>
<type>high-pass</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Lead-Lag filter <lead-lag> ===
The lead-lag filter is a typical [https://en.wikipedia.org/wiki/Lead%E2%80%93lag_compensator] lead lag filter. As the name implies it is a combination of a lead (high-pass) filter and a lag (low-pass) filter.

Example: a lead lag filter k(s+a)/s+b).
The gain is k, filter-time-a is a, and filter-time-b is b.

In an autopilot is is often used to sharpen up the response to an input.

<syntaxhighlight lang="xml">
<filter>
<name>loc-deg leadlag</name>
<debug>false</debug>
<type>lead-lag</type>
<gain>5</gain>
<filter-time-a>5.0</filter-time-a>
<filter-time-b>1.0</filter-time-b>
<input>
<property>/autopilot/internal/loc-deg</property>
</input>
<output>
<property>/autopilot/internal/loc-deg-leadlag</property>
</output>
</filter>
</syntaxhighlight>

=== Integrator filter <lead-lag> ===
The integrator filter provides integration with time.

Example: an integrator filter k(1/s).

In this example, the normal input (<syntaxhighlight lang="xml" inline><property>/autopilot/internal/p-deg_sec</property></syntaxhighlight>)is disconnected and replaved by (output x 10) input when relay Rb is closed. This has the effect of rapidly ramping the integrator output to zero.

<syntaxhighlight lang="xml">
<filter>
<name>synthetic bank from roll rate</name>
<debug>false</debug>
<type>integrator</type>
<gain>1.0</gain>
<input>
<condition>
<property>/autopilot/internal/Rb</property>
</condition>
<property>/autopilot/internal/p-deg_sec</property>
</input>
<input> 
<expression>
<product>
<value>-10.0</value>
<property>/autopilot/internal/phi-deg_synth</property>
</product>
</expression>
</input>
<output>
<property>/autopilot/internal/phi-deg_synth</property>
</output>
<u_min>-180</u_min>
<u_max>180</u_max>
</filter>
</syntaxhighlight>

=== Moving average filter <moving-average> ===
Calculates average of specified number of values.

Currently the average length can only be given as number of samples and not time.

<syntaxhighlight lang="xml">
<filter>
<type>moving-average</type>
<samples>120</samples>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Rate limit filter <noise-spike> ===
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <syntaxhighlight lang="xml" inline><max-rate-of-change></syntaxhighlight> setting the maximum rate of change of the output property per second.

Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.

<syntaxhighlight lang="xml">
<filter>
<type>noise-spike</type>
<max-rate-of-change>0.5</max-rate-of-change>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Reciprocal filter <reciprocal> ===
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element may be used to scale the value. Output computes as gain divided by input.

Example: compute the flight time per pound of burned fuel from the fuel flow

<syntaxhighlight lang="xml">
<filter>
<type>reciprocal</type>
<gain>1.0</gain>
<input>/engines/engine[0]/fuel-flow-pph</input>
<output>/engines/engine[0]/fuel-flow-hpp</output>
</filter>
</syntaxhighlight>

=== Derivative filter <derivative> ===
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> acts as gain and must be given because it has default 0.

Example: compute derivative of static port pressure

<syntaxhighlight lang="xml">
<filter>
<type>derivative</type>
<input>systems/static[0]/pressure-inhg</input>
<output>autopilot/internal/pressure-rate</output>
<filter-time>1.0</filter-time>
</filter>
</syntaxhighlight>

== PID controller <pid-controller> ==
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <syntaxhighlight lang="xml" inline><max></syntaxhighlight> and <syntaxhighlight lang="xml" inline><min></syntaxhighlight> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.

The xml element creating a pid controller is <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| The overall gain for the proportional, integral and derivative part
|-
! <syntaxhighlight lang="xml" inline><Ti></syntaxhighlight>
| Integrator time
|-
! <syntaxhighlight lang="xml" inline><Td></syntaxhighlight>
| Derivator time
|-
! <syntaxhighlight lang="xml" inline><Ts></syntaxhighlight>
| Sampling interval (default: sample at frame rate)
|-
! <syntaxhighlight lang="xml" inline><alpha></syntaxhighlight>
| Scaling factor for Td (defaults to 0.1)
|-
! <syntaxhighlight lang="xml" inline><beta></syntaxhighlight>
| Reference weighing factor for the proportional component (defaults to 1.0)
|-
! <syntaxhighlight lang="xml" inline><gamma></syntaxhighlight>
| Reference weighing factor for the derivate component (defaults to 0.0)
|}

== PI controller <pi-simple-controller> ==
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements are present.
The xml element creating a PI controller is <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| Gain of the proportional component
|-
! <syntaxhighlight lang="xml" inline><Ki></syntaxhighlight>
| Gain of the integrator component
|}

== Predictor <predict-simple> ==
Estimates the future value for a given property based on its current (or averaged) rate of change.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><seconds></syntaxhighlight>
| The time to be estimated ahead
|-
! <syntaxhighlight lang="xml" inline><filter-gain></syntaxhighlight>
| Smoothing factor (0.0-1.0, 1.0=no smoothing)
|}

Example: compute estimated speed 5 seconds ahead

<syntaxhighlight lang="xml">
<predict-simple>
<name>predicted air speed 5 seconds ahead</name>
<debug>false</debug>
<input>velocities/airspeed-kt</input>
<output>autopilot/internal/airspeed-5-sec-ahead</output>
<seconds>5.0</seconds>
<filter-gain>0.1</filter-gain>
</predict-simple>
</syntaxhighlight>

== State Machine <state-machine> ==
For a description of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].

{{note|Current behaviour with enter, exit and update tags differs from this documentation. Refer to the developer mailing list [https://sourceforge.net/p/flightgear/mailman/message/35557652/] before implementing bindings in state machines.}}

<syntaxhighlight lang="xml">
<state-machine>
<branch>/my-statemachine</branch>
<state>
<name>init</name>
<enter>
<binding></binding>
<binding></binding>
</enter>
<exit>
<binding></binding>
</exit>
<update>
<binding></binding>
</update>
</state>
<state>
<name>finished</name>
<enter>Zero to many bindings, fired upon state enter</enter>
<exit>Zero to many bindings, fired upon state exit</exit>
<update>Zero to many bindings, fired upon every state change</update>
</state>
<transition>
<name>ready</name>
<source>init</source>
<target>finished</target>
<exclude-target type="bool">true</exclude-target>
<condition>
<greater-than>
<property>/sim/time/elapsed-sec</property>
<value>30</value>
</greater-than>
</condition>
<binding>Zero to many bindings, fired upon state change</binding>
</transition>
</state-machine>
</syntaxhighlight>

Legal elements for the state machine are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><branch></syntaxhighlight>
| A path to a property node where the internal states of the machine gets written to. Can be empty.
|-
! <syntaxhighlight lang="xml" inline><state></syntaxhighlight>
| Two ore more state elements are required for a minimal state machine
|-
! <syntaxhighlight lang="xml" inline><transition></syntaxhighlight>
| Any number of transition elements. Describes how to change from one state to another.
|}

Legal elements for the state element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the state a name for reference
|-
! <syntaxhighlight lang="xml" inline><enter></syntaxhighlight>
| Optional, zero to many enter elements containing a SGBinding to fire upon state enter
|-
! <syntaxhighlight lang="xml" inline><exit></syntaxhighlight>
| Optional, zero to many exit elements containing a SGBinding to fire upon state exit
|-
! <syntaxhighlight lang="xml" inline><update></syntaxhighlight>
| Optional, zero to many update elements containing a SGBinding to fire upon state change
|}

Legal elements for the transition element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the transition a name for reference
|-
! <syntaxhighlight lang="xml" inline><source></syntaxhighlight>
| Optional, zero to many source elements containing the name of a source state. If no source state is definied, this transition applies to all states.
|-
! <syntaxhighlight lang="xml" inline><target></syntaxhighlight>
| Required, exactly one target element defining the target state
|-
! <syntaxhighlight lang="xml" inline><condition></syntaxhighlight>
| Required, contains a SGCondition when this state change occours
|-
! <syntaxhighlight lang="xml" inline><exclude-target></syntaxhighlight>
| Optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target
|-
! <syntaxhighlight lang="xml" inline><binding></syntaxhighlight>
| Optional, zero to many binding elements containing a SGBinding to fire when this transition triggers
|}

== Proposed extensions ==
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.

=== Expose to Nasal ===
Given that Nasal is a widely-known bottleneck, people should not use it for implement FDM/AP or route-manager functionality in scripting space. However, for the time being, the underlying C++ code is not exposed to scripting space, so that aircraft developers tend to reinvent the wheel. Thus, it would make sense to expose the AP/property-rule/state machine subsystems to scripting space using the [[Nasal/CppBind]] framework, to ensure that existing C++ code can be used for such purposes:

{{FGCquote
|1= I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=149376#p149376
| title = <nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
| author = <nowiki>Torsten</nowiki>
| date = Feb 2nd, 2012
}}
}}

== Related content ==
=== Wiki articles ===
* [[Autopilot PID controller tuning resources]]
* [[Howto:Design an autopilot]]
* [[Howto:Implement a Fly-By-Wire System for Airliners]]

=== Readme file ===
* {{readme file|digitalfilters}}

=== Source code ===
* {{flightgear source|src/Autopilot/digitalfilter.hxx}}
* {{flightgear source|src/Autopilot/autopilot.cxx}}

[[Category:Aircraft enhancement]]

Autopilot configuration reference

2017-03-18T21:13:03Z

Chris blues: /* Adding an autopilot configuration */ add note about indexing the autopilot configurations

{{Systems_Modeling_Disclaimer}}

[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]

{{forum|46|Autopilot & Route Manager}}
{{Autoflight Navigation}}

: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''

The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.

This page serves as a reference for the elements of [[FlightGear]] XML [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.

For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).

== Autopilot vs. property-rule configurations ==
The main difference between XML based autopilot and property-rule systems is the update rate:

* Autopilot configurations run at [[FDM]] rate
* Property-rule configurations run at frame rate

=== Performance considerations ===
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.

It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.

For example would a fly-by-wire flight control system element augmenting an unstable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.

== Adding a configuration to an aircraft ==
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code><Aircraft>-set.xml</code> file.

=== Adding an autopilot configuration ===
Autopilot configuration files are added to the aircraft by adding

<syntaxhighlight lang="xml">
<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</syntaxhighlight>

to the

<syntaxhighlight lang="xml">
<sim>
<systems>

<autopilot n="100">
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</systems>
</sim>
</syntaxhighlight>

node of your <code>aircraft-set.xml</code> file. Note, that more than one <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <syntaxhighlight lang="xml" inline><systems></syntaxhighlight>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.

While the above seems to be the recommended standard, it has occasionally lead to trouble, not to index the autopilot configurations. Anyway, it shouldn't hurt to do so.

=== Adding a property-rule configuration ===
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)

To achieve this load your filters configuration by adding:

<syntaxhighlight lang="xml">
<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</syntaxhighlight>
(Do NOT use the filename "propertyrules.xml")

to the :

<syntaxhighlight lang="xml">
<sim>
<systems>

<property-rule n="100"> 
<name>My property rule</name> 
<path>Systems/my-propertyrules.xml</path> 
</property-rule>
</systems>
</sim>
</syntaxhighlight>

node of your <code><aircraft>-set.xml</code> file. Note that you can add multiple <syntaxhighlight lang="xml" inline><property-rule></syntaxhighlight> elements, similar to the <syntaxhighlight lang="xml" inline><autopilot></syntaxhighlight> as described above.

{{tip|Configurations can be enabled and disabled through the boolean properties <code>/sim/systems/autopilot[''n'']/serviceable</code> and <code>/sim/systems/property-rule[''n'']/serviceable</code>, where''n'' is the index for a configuration}}

== Structure of a configuration file ==
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <syntaxhighlight lang="xml" inline><PropertyList></syntaxhighlight> node as a root element. A basic skeleton file looks like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params include="MyParams.xml"> 
<controls>
<aileron>controls/flight/aileron</aileron>
<rudder>controls/flight/rudder</rudder>
<elevator>controls/flight/elevator</elevator>
</controls>
</params>



</PropertyList>
</syntaxhighlight>

The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.

{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.

For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}

{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}

== Available elements ==
All elements may contain the attributes "include" and "alias".
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <syntaxhighlight lang="xml" inline><foo alias="/params/bar/baz"/></syntaxhighlight>. Use the colon to move through the document tree, similar to file system paths like <syntaxhighlight lang="xml" inline><foo alias="../../bar/baz"/></syntaxhighlight>.

Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:
* <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><filter></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><predict-simple></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><logic></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><flipflop></syntaxhighlight>
* <syntaxhighlight lang="xml" inline><state-machine></syntaxhighlight>

== Common elements used by all elements ==

=== Name of filter and controller <name> ===
The <syntaxhighlight lang="xml" inline><name></syntaxhighlight> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.

<syntaxhighlight lang="xml">
<name>NAV hold</name>
</syntaxhighlight>

=== Feedback <feedback-if-disabled> ===
The <syntaxhighlight lang="xml" inline><feedback-if-disabled></syntaxhighlight> element advises the controller to feed back the output property value to the active input property if the condition defined in the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight> within this element results in feedback disabled.

<syntaxhighlight lang="xml">
<feedback-if-disabled>true</feedback-if-disabled>
</syntaxhighlight>

=== Printing debug output <debug> ===
If the <syntaxhighlight lang="xml" inline><debug></syntaxhighlight> element is present and if it contains the word <syntaxhighlight lang="xml" inline>true</syntaxhighlight>, the containing controller prints out some diagnostic information on the console for each processing loop.

<syntaxhighlight lang="xml">
<debug>true</debug>
</syntaxhighlight>

=== Input and reference properties or values <input> and <reference> ===
Each controller has two input "lines", denoted by the tags <syntaxhighlight lang="xml" inline><input></syntaxhighlight> and <syntaxhighlight lang="xml" inline><reference></syntaxhighlight>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.

Example for a simple differential amplifier, computing output = (input-reference)*2

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>1.0</gain>
<input>/some/input</input>
<reference>/some/output</reference>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Output property <output> ===
The <syntaxhighlight lang="xml" inline><output></syntaxhighlight> element names the properties, the computed value should be written to. More than one <syntaxhighlight lang="xml" inline><output></syntaxhighlight> may be present, each named property will be assigned the computed value.

<syntaxhighlight lang="xml">
<output>controls/flight/elevator</output>
</syntaxhighlight>

=== Enabling and disabling a filter <enable> ===
Controllers can be enabled or disabled using property values. This element <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> may contain a <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> and a <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element to the <syntaxhighlight lang="xml" inline><enable></syntaxhighlight> element. This <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> follows the same syntactical rules as the one used in model animations and can model complex expression trees.
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition

<syntaxhighlight lang="xml">
<enable>
<condition>
<less-than>
<property>orientation/bank-angle-deg</property>
<value>30.0</value>
</less-than>
<greater-than>
<property>orientation/bank-angle-deg</property>
<value>-30.0</value>
</greater-than>
</condition>
</enable>
</syntaxhighlight>

=== Input values ===
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element as an example but it may be substituted by any other input element like <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>, <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> etc. Input values will be interpreted as double values.

==== A constant value <value> or <reference> ====
A constant value is defined by just adding the value as text to the input element:

<syntaxhighlight lang="xml">
<reference>
<value>3.5</value>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:

<syntaxhighlight lang="xml">
<reference>3.5</reference>
</syntaxhighlight>

If the text can be parsed by <code>strtod()</code> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)

==== A property value ====
To evaluate the value of a property, place the name of the property into the text element:

<syntaxhighlight lang="xml">
<reference>
<property>/my/property</property>
</reference>
</syntaxhighlight>

The shortcut syntax is also valid:
<syntaxhighlight lang="xml">
<reference>/my/property</reference>
</syntaxhighlight>

{{note|The shortcut syntax is only valid, if neither <syntaxhighlight lang="xml" inline><property></syntaxhighlight> nor <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exists.
If both <syntaxhighlight lang="xml" inline><property></syntaxhighlight> '''and''' <syntaxhighlight lang="xml" inline><value></syntaxhighlight> element exist, the property will be initialized with the given value with scale and offset applied correctly.
Properties don't have to exist, the will be created as needed.}}

{{note|For backward compatibility, the notation <syntaxhighlight lang="xml" inline><prop></syntaxhighlight> instead of <syntaxhighlight lang="xml" inline><property></syntaxhighlight> is also valid but considered deprecated and might go away in future releases.}}

==== Linear transformation of the input value <offset> ====
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt>
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
</reference>
</syntaxhighlight>

==== Periodical transformation of the input value <period> ====
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.

<syntaxhighlight lang="xml">
<reference>
<property>/orientation/heading-deg</property>
<period>
<min>-180.0</min>
<max>180.0</max>
</period>
</reference>
</syntaxhighlight>

==== Input clamping <min> and <max> ====
To clamp the input to a minimum value, maximum value or both, the tags <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.

The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:

<syntaxhighlight lang="xml">
<reference>
<property>/environment/temperature-degc</property>
<scale>1.8</scale>
<offset>32</offset>
<min>60</min>
<max>80</max>
</reference>
</syntaxhighlight>

==== Absolute values <abs> ====
To use the absolute (unsigned) value of the input, add <syntaxhighlight lang="xml" inline><abs type="bool">true</abs></syntaxhighlight>.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<abs type="bool">true</abs>
</reference>
</syntaxhighlight>

==== Recursive definition ====
The elements <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.

<syntaxhighlight lang="xml">
<reference>
<property>/autopilot/internal/course-error-deg</property>
<scale>2.0</scale>
<offset>
<property>orientation/bank-angle-deg</property>
<scale>
<property>some/property
<min>-1.5</min>
<max>1.5</max>
</scale>
</offset>
</reference>
</syntaxhighlight>

==== Conditional input values <condition> ====
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.

<syntaxhighlight lang="xml">
<reference>
<condition>
<property>/autopilot/coupled-to-gps</property>
</condition>
<property>instrumentation/gps/desired-track-deg</property>
</reference>
<reference>
<condition>
<property>/autopilot/coupled-to-nav2</property>
</condition>
<property>instrumentation/nav[1]/radials/selected-deg</property>
</reference>
<reference>instrumentation/nav[0]/radials/selected-deg</reference>
</syntaxhighlight>

Note the unconditional last <syntaxhighlight lang="xml" inline><reference></syntaxhighlight> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.

The <syntaxhighlight lang="xml" inline><scale></syntaxhighlight>, <syntaxhighlight lang="xml" inline><offset></syntaxhighlight>, <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements of input values itself currently don't support input value lists.

==== Expressions <expression> ====
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <syntaxhighlight lang="xml" inline><expression></syntaxhighlight> tag.

=== Output values ===
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <syntaxhighlight lang="xml" inline><period></syntaxhighlight> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value.

{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}

The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:

{| class="prettytable"
! computed !! written
|-
| -350 || 10
|-
| -270 || 30
|-
| -90 || -30
|-
| -29 || -29
|-
| 29 || 29
|-
| 90 || 30
|-
| 350 || -10
|}

<syntaxhighlight lang="xml">
<output>/some/property</output>
<period>
<min>-180</min>
<max>180</max>
</period>
<min>-30</min>
<max>30</max>
</syntaxhighlight>

This example shows how to use a table to vary an output with height. At sea level, the output is 0.045, at 22400 the output is 0.1196, and at 56000 ft the output is 0.7

<syntaxhighlight lang="xml">
<filter>
<name>GAy</name>
<debug>false</debug>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/instrumentation/altimeter/indicated-altitude-ft</property>
<entry><ind>0.0</ind><dep>0.045</dep></entry>
<entry><ind>22400</ind><dep>0.1196</dep></entry>
<entry><ind>56000</ind><dep>0.7</dep></entry>
</table>
</expression>
</input>
<output>
<property>/autopilot/gain/GAy</property>
</output>
</filter>
</syntaxhighlight>

== Logic controller <logic> ==
The logic controller provides a simple way of creating property values from the result of the condition expression in the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <syntaxhighlight lang="xml" inline><inverted></syntaxhighlight> element inverts the logic. The default is "not inverted".

Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )

<syntaxhighlight lang="xml">
<logic>
<inverted>true</inverted>
<input>
<property>a</property>
<or>
<greater-than>
<property>b</property>
<property>c</property>
</greater-than>
<property>d</property>
</or>
</input>
<output>output</output>
</logic>
</syntaxhighlight>

== Flip flop logic <flipflop> ==
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.
All input lines, including the clock line, are encoded as condition constructs.
If negative logic for the input line is required, wrap the condition into a <syntaxhighlight lang="xml" inline><not></syntaxhighlight> tag to invert the logic.

{{note|The type, for example '''RS''', is case sensitive.}}
{{note|Using <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> tags will break the logic.}}

=== RS flip flop <RS> ===
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<syntaxhighlight lang="xml" inline><type>RS</type></syntaxhighlight>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<syntaxhighlight lang="xml" inline><type>SR</type></syntaxhighlight>) has a dominant set line and the output gets set if set and reset line are set.

Example: simple RS flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>RS</type> 
<S>
<property>/myflipflop/set</property>
</S>
<R>
<property>/myflipflop/reset</property>
</R>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== JK flip flop <JK> ===
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occur immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.
If no clock signal is provided, the frame rate serves as the clock input.

Example: simple JK flip flop with negative edge clock

<syntaxhighlight lang="xml">
<flipflop>
<type>JK</type>
<J>
<property>/myflipflop/set</property>
</J>
<K>
<property>/myflipflop/reset</property>
</K>
<clock>
<not>
<property>/myflipflop/clock</property>
</not>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== D flip flop <D> ===
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple D flip flop with inverted output

<syntaxhighlight lang="xml">
<flipflop>
<type>D</type>
<D>
<property>/myflipflop/data</property>
</D>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
<inverted type="bool">true</inverted>
</flipflop>
</syntaxhighlight>

=== T flip flop <T> ===
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.

Example: simple T flip flop

<syntaxhighlight lang="xml">
<flipflop>
<type>T</type>
<clock>
<property>/myflipflop/clock</property>
</clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

=== Monostable flip flop <monostable> ===
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory.

The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <syntaxhighlight lang="xml" inline><time></syntaxhighlight> element.

{{note|The optional <syntaxhighlight lang="xml" inline><R></syntaxhighlight> and <syntaxhighlight lang="xml" inline><K></syntaxhighlight> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<time>
<property>/myflipflop/pulsetime-sec</property>
<value>10</value>
</time>
<S><property>/myflipflop/s</property></S>
<J><property>/myflipflop/j</property></J>
<clock><property>/myflipflop/clock</property></clock>
<output>/myflipflop/output</output>
</flipflop>
</syntaxhighlight>

The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:

<syntaxhighlight lang="xml">
<flipflop>
<name>Test mf</name>
<type>monostable</type>
<inverted type="bool">true</inverted>
<S>
<not>
<property>/myflipflop/s</property>
</not>
</S>
<time>
<value>10.0</value>
</time>
<output>
<property>/myflipflop/output</property>
</output>
</flipflop>
</syntaxhighlight>

In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.

== Filters <filter> ==

=== Pure gain filter <gain> ===
A gain filter multiplies the <syntaxhighlight lang="xml" inline><input></syntaxhighlight> value by a given factor or gain <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> and returns the output to <syntaxhighlight lang="xml" inline><output></syntaxhighlight>. More than one <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <syntaxhighlight lang="xml" inline><condition></syntaxhighlight> evaluating as true the first <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> will define the used gain.

<syntaxhighlight lang="xml">
<filter>
<type>gain</type>
<gain>6.28</gain>
<input>radius</input>
<output>circumfence</output>
</filter>
</syntaxhighlight>

=== First order low pass filter <exponential> ===
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic Euler number and the associated mathematical function exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).

Example: a 1Hz first order low pass filter

<syntaxhighlight lang="xml">
<filter>
<type>exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Second order low pass filter <double-exponential> ===
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter.

The configuration is the same for exponential and double-exponential filters, just the type entry differs.

<syntaxhighlight lang="xml">
<filter>
<type>double-exponential</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/<output>
</filter>
</syntaxhighlight>

=== First order high pass filter <high-pass> ===
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter

Example: a 1Hz first order high pass filter

<syntaxhighlight lang="xml">
<filter>
<type>high-pass</type>
<filter-time>0.16</filter-time>
<input>/some/input</input>
<output>/some/output/</output>
</filter>
</syntaxhighlight>

=== Lead-Lag filter <lead-lag> ===
The lead-lag filter is a typical [https://en.wikipedia.org/wiki/Lead%E2%80%93lag_compensator] lead lag filter. As the name implies it is a combination of a lead (high-pass) filter and a lag (low-pass) filter.

Example: a lead lag filter k(s+a)/s+b).
The gain is k, filter-time-a is a, and filter-time-b is b.

In an autopilot is is often used to sharpen up the response to an input.

<syntaxhighlight lang="xml">
<filter>
<name>loc-deg leadlag</name>
<debug>false</debug>
<type>lead-lag</type>
<gain>5</gain>
<filter-time-a>5.0</filter-time-a>
<filter-time-b>1.0</filter-time-b>
<input>
<property>/autopilot/internal/loc-deg</property>
</input>
<output>
<property>/autopilot/internal/loc-deg-leadlag</property>
</output>
</filter>
</syntaxhighlight>

=== Integrator filter <lead-lag> ===
The integrator filter provides integration with time.

Example: an integrator filter k(1/s).

In this example, the normal input (<syntaxhighlight lang="xml" inline><property>/autopilot/internal/p-deg_sec</property></syntaxhighlight>)is disconnected and replaved by (output x 10) input when relay Rb is closed. This has the effect of rapidly ramping the integrator output to zero.

<syntaxhighlight lang="xml">
<filter>
<name>synthetic bank from roll rate</name>
<debug>false</debug>
<type>integrator</type>
<gain>1.0</gain>
<input>
<condition>
<property>/autopilot/internal/Rb</property>
</condition>
<property>/autopilot/internal/p-deg_sec</property>
</input>
<input> 
<expression>
<product>
<value>-10.0</value>
<property>/autopilot/internal/phi-deg_synth</property>
</product>
</expression>
</input>
<output>
<property>/autopilot/internal/phi-deg_synth</property>
</output>
<u_min>-180</u_min>
<u_max>180</u_max>
</filter>
</syntaxhighlight>

=== Moving average filter <moving-average> ===
Calculates average of specified number of values.

Currently the average length can only be given as number of samples and not time.

<syntaxhighlight lang="xml">
<filter>
<type>moving-average</type>
<samples>120</samples>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Rate limit filter <noise-spike> ===
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <syntaxhighlight lang="xml" inline><max-rate-of-change></syntaxhighlight> setting the maximum rate of change of the output property per second.

Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.

<syntaxhighlight lang="xml">
<filter>
<type>noise-spike</type>
<max-rate-of-change>0.5</max-rate-of-change>
<input>/some/input</input>
<output>/some/output</output>
</filter>
</syntaxhighlight>

=== Reciprocal filter <reciprocal> ===
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <syntaxhighlight lang="xml" inline><gain></syntaxhighlight> element may be used to scale the value. Output computes as gain divided by input.

Example: compute the flight time per pound of burned fuel from the fuel flow

<syntaxhighlight lang="xml">
<filter>
<type>reciprocal</type>
<gain>1.0</gain>
<input>/engines/engine[0]/fuel-flow-pph</input>
<output>/engines/engine[0]/fuel-flow-hpp</output>
</filter>
</syntaxhighlight>

=== Derivative filter <derivative> ===
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <syntaxhighlight lang="xml" inline><filter-time></syntaxhighlight> acts as gain and must be given because it has default 0.

Example: compute derivative of static port pressure

<syntaxhighlight lang="xml">
<filter>
<type>derivative</type>
<input>systems/static[0]/pressure-inhg</input>
<output>autopilot/internal/pressure-rate</output>
<filter-time>1.0</filter-time>
</filter>
</syntaxhighlight>

== PID controller <pid-controller> ==
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <syntaxhighlight lang="xml" inline><max></syntaxhighlight> and <syntaxhighlight lang="xml" inline><min></syntaxhighlight> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.

The xml element creating a pid controller is <syntaxhighlight lang="xml" inline><pid-controller></syntaxhighlight>.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| The overall gain for the proportional, integral and derivative part
|-
! <syntaxhighlight lang="xml" inline><Ti></syntaxhighlight>
| Integrator time
|-
! <syntaxhighlight lang="xml" inline><Td></syntaxhighlight>
| Derivator time
|-
! <syntaxhighlight lang="xml" inline><Ts></syntaxhighlight>
| Sampling interval (default: sample at frame rate)
|-
! <syntaxhighlight lang="xml" inline><alpha></syntaxhighlight>
| Scaling factor for Td (defaults to 0.1)
|-
! <syntaxhighlight lang="xml" inline><beta></syntaxhighlight>
| Reference weighing factor for the proportional component (defaults to 1.0)
|-
! <syntaxhighlight lang="xml" inline><gamma></syntaxhighlight>
| Reference weighing factor for the derivate component (defaults to 0.0)
|}

== PI controller <pi-simple-controller> ==
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <syntaxhighlight lang="xml" inline><min></syntaxhighlight> and <syntaxhighlight lang="xml" inline><max></syntaxhighlight> elements are present.
The xml element creating a PI controller is <syntaxhighlight lang="xml" inline><pi-simple-controller></syntaxhighlight>
Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><Kp></syntaxhighlight>
| Gain of the proportional component
|-
! <syntaxhighlight lang="xml" inline><Ki></syntaxhighlight>
| Gain of the integrator component
|}

== Predictor <predict-simple> ==
Estimates the future value for a given property based on its current (or averaged) rate of change.

Legal elements are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><seconds></syntaxhighlight>
| The time to be estimated ahead
|-
! <syntaxhighlight lang="xml" inline><filter-gain></syntaxhighlight>
| Smoothing factor (0.0-1.0, 1.0=no smoothing)
|}

Example: compute estimated speed 5 seconds ahead

<syntaxhighlight lang="xml">
<predict-simple>
<name>predicted air speed 5 seconds ahead</name>
<debug>false</debug>
<input>velocities/airspeed-kt</input>
<output>autopilot/internal/airspeed-5-sec-ahead</output>
<seconds>5.0</seconds>
<filter-gain>0.1</filter-gain>
</predict-simple>
</syntaxhighlight>

== State Machine <state-machine> ==
For a description of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].

{{note|Current behaviour with enter, exit and update tags differs from this documentation. Refer to the developer mailing list [https://sourceforge.net/p/flightgear/mailman/message/35557652/] before implementing bindings in state machines.}}

<syntaxhighlight lang="xml">
<state-machine>
<branch>/my-statemachine</branch>
<state>
<name>init</name>
<enter>
<binding></binding>
<binding></binding>
</enter>
<exit>
<binding></binding>
</exit>
<update>
<binding></binding>
</update>
</state>
<state>
<name>finished</name>
<enter>Zero to many bindings, fired upon state enter</enter>
<exit>Zero to many bindings, fired upon state exit</exit>
<update>Zero to many bindings, fired upon every state change</update>
</state>
<transition>
<name>ready</name>
<source>init</source>
<target>finished</target>
<exclude-target type="bool">true</exclude-target>
<condition>
<greater-than>
<property>/sim/time/elapsed-sec</property>
<value>30</value>
</greater-than>
</condition>
<binding>Zero to many bindings, fired upon state change</binding>
</transition>
</state-machine>
</syntaxhighlight>

Legal elements for the state machine are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><branch></syntaxhighlight>
| A path to a property node where the internal states of the machine gets written to. Can be empty.
|-
! <syntaxhighlight lang="xml" inline><state></syntaxhighlight>
| Two ore more state elements are required for a minimal state machine
|-
! <syntaxhighlight lang="xml" inline><transition></syntaxhighlight>
| Any number of transition elements. Describes how to change from one state to another.
|}

Legal elements for the state element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the state a name for reference
|-
! <syntaxhighlight lang="xml" inline><enter></syntaxhighlight>
| Optional, zero to many enter elements containing a SGBinding to fire upon state enter
|-
! <syntaxhighlight lang="xml" inline><exit></syntaxhighlight>
| Optional, zero to many exit elements containing a SGBinding to fire upon state exit
|-
! <syntaxhighlight lang="xml" inline><update></syntaxhighlight>
| Optional, zero to many update elements containing a SGBinding to fire upon state change
|}

Legal elements for the transition element are:

{| class="prettytable"
! <syntaxhighlight lang="xml" inline><name></syntaxhighlight>
| Required, gives the transition a name for reference
|-
! <syntaxhighlight lang="xml" inline><source></syntaxhighlight>
| Optional, zero to many source elements containing the name of a source state. If no source state is definied, this transition applies to all states.
|-
! <syntaxhighlight lang="xml" inline><target></syntaxhighlight>
| Required, exactly one target element defining the target state
|-
! <syntaxhighlight lang="xml" inline><condition></syntaxhighlight>
| Required, contains a SGCondition when this state change occours
|-
! <syntaxhighlight lang="xml" inline><exclude-target></syntaxhighlight>
| Optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target
|-
! <syntaxhighlight lang="xml" inline><binding></syntaxhighlight>
| Optional, zero to many binding elements containing a SGBinding to fire when this transition triggers
|}

== Proposed extensions ==
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.

=== Expose to Nasal ===
Given that Nasal is a widely-known bottleneck, people should not use it for implement FDM/AP or route-manager functionality in scripting space. However, for the time being, the underlying C++ code is not exposed to scripting space, so that aircraft developers tend to reinvent the wheel. Thus, it would make sense to expose the AP/property-rule/state machine subsystems to scripting space using the [[Nasal/CppBind]] framework, to ensure that existing C++ code can be used for such purposes:

{{FGCquote
|1= I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=149376#p149376
| title = <nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
| author = <nowiki>Torsten</nowiki>
| date = Feb 2nd, 2012
}}
}}

== Related content ==
=== Wiki articles ===
* [[Autopilot PID controller tuning resources]]
* [[Howto:Design an autopilot]]
* [[Howto:Implement a Fly-By-Wire System for Airliners]]

=== Readme file ===
* {{readme file|digitalfilters}}

=== Source code ===
* {{flightgear source|src/Autopilot/digitalfilter.hxx}}
* {{flightgear source|src/Autopilot/autopilot.cxx}}

[[Category:Aircraft enhancement]]

Cessna 550 Citation II

2017-03-17T19:57:11Z

Chris blues: /* Recently updated */ correct typo

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
{{#tag:syntaxhighlight |
$ {{fgaddon co|Citation|post=Citation}}
$ svn up
| lang="bash"
}}

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for [[State_Overlay_System|state overlays]]. Will be available with FG-2017.2 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 MHz with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:37:05Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for [[State_Overlay_System|state overlays]]. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 MHz with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:35:20Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 MHz with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:34:31Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 MHz meaning NAV1 is set to 110.300 with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:33:33Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* '''parking''' ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* '''taxi''' ( engines and all systems running - ready to taxi )
* '''take-off''' ( flaps and AP set - just throttle up and go )
* '''cruise''' ( flying at FL360 on AP )
* '''approach''' ( !experimental! use with:
''--glideslope=degrees'' ( usually 3 ) '''or'''
''--altitude=ft-above-msl'' ( alt above sea level ) '''or'''
''--offset-distance=nm'' ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
''--in-air'' ( well, just do it... )
if you want, you can add options like this:
''--nav1=rad:freq'' ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:30:28Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* taxi ( engines and all systems running - ready to taxi )
* take-off ( flaps and AP set - just throttle up and go )
* cruise ( flying at FL360 on AP )
* approach ( !experimental! use with:
--glideslope=degrees ( usually 3 ) '''or'''
--altitude=ft-above-msl ( alt above sea level ) '''or'''
--offset-distance=nm ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
--in-air ( well, just do it... )
if you want, you can add options like this:
--nav1=rad:freq ( Going into [https://skyvector.com/airport/LPAZ/Santa-Maria-Airport LPAZ] 18 enter --nav1=179:110.300 meaning NAV1 is set to 110.300 with a radial of 179°, which is the G/S of LPAZ-18 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:19:30Z

Chris blues: /* Recently updated */ add state overlay options

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking ( cold and dark, all systems off) (same as without <code>--state=$state</code> )
* taxi ( engines and all systems running - ready to taxi )
* take-off ( flaps and AP set - just throttle up and go )
* cruise ( flying at FL360 on AP )
* approach ( !experimental! use with:
--glideslope=degrees ( usually 3 ) '''or'''
--altitude=ft-above-msl ( alt above sea level ) '''or'''
--offset-distance=nm ( 10 seems like a good start )
Never use all 3 options at once! Only 2 of them. Triangle calculation - remember?
--in-air ( well, just do it... )
if you want, you can add options like this:
--nav1=rad:freq ( Going into LOWI 26 enter --nav1=255:111.100 meaning NAV1 is set to 111.100 with a radial of 255°, which is the G/S of LOWI26 )
)

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:07:17Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Will be available with FG-2017.3 or recent dev-Version. Activate state overlay by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking (cold and dark, all systems off) (same as without <code>--state=$state</code> )
* taxi (engines and all systems running - ready to taxi)
* take-off (flaps and AP set - just throttle up and go)
* cruise (flying at FL360 on AP)
* approach ( !experimental! use with <code>--glideslope=degrees --offset-distance=nm --in-air</code> )

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:05:21Z

Chris blues: /* Recently updated */ formatting

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Activate by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking (cold and dark, all systems off) (same as without <code>--state=$state</code> )
* taxi (engines and all systems running - ready to taxi)
* take-off (flaps and AP set - just throttle up and go)
* cruise (flying at FL360 on AP)
* approach ( !experimental! use with <code>--glideslope=degrees --offset-distance=nm --in-air</code> )

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:04:14Z

Chris blues: /* Recently updated */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Activate by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking (cold and dark, all systems off) (same as without <code>--state=$state</code> )
* taxi (engines and all systems running - ready to taxi)
* take-off (flaps and AP set - just throttle up and go)
* cruise (flying at FL360 on AP)
* approach ( !experimental! use with <code>--glideslope=degrees --offset-distance=nm --in-air</code> )

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T01:01:38Z

Chris blues: /* Recently updated */ add state overlays

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
* New support for state overlays. Activate by adding <code>--state=$state</code> to your command-line.
$state can be:
* parking (cold and dark, all systems off)
* taxi (engines and all systems running - ready to taxi)
* take-off (flaps and AP set - just throttle up and go)
* cruise (flying at FL360 on AP)
* approach ( !experimental! use with <code>--glideslope=degrees --offset-distance=nm --in-air</code> )

==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II

2017-03-17T00:55:49Z

Chris blues: /* Model */

{{:{{PAGENAME}}/info}}
The '''Cessna 550 Citation II''' debuted in [[FlightGear]] 0.9.8 in January 2005. It has four "special views": copilot, center-console, passenger 1 and passenger 2.

== Overview ==
The Cessna 550/551 Citation II is a light corporate jet built between 1978 and 2006. The FlightGear model is a luxury corporate jet for two pilots and seven passengers. However you should not view the original Citation II as a real jet; with a cruising speed of only 330 KTAS, it was really intended as a competitor for high-end twin turboprops.

The Cessna 550 requires two pilots; the 551 is the same aircraft certified for single-pilot use.

Later variants of this aircraft include the [[Cessna_Citation_Bravo|Cessna Citation Bravo]], which has newer avionics (available separately in FlightGear), the Cessna Citation S/II with improved wings (not currently available in FlightGear), and the Sierra Super II, available together with this aircraft in FlightGear.

The Sierra Super II is an aftermarket modification of the Cessna 550/551 which replaces the engines with Williams International FJ44-3 turbofans introduced in 2004. They
provide more thrust and less fuel consumption. Climb performance in particular is dramatically improved.

The new engines lack thrust reversers; they are not needed because their idle thrust is only 40 lbf, as opposed to 400 lbf on the old engines.

[[File:CitationII Cockpit Dusk 2015-03-29.jpg|thumb|Cockpit Cessna 550 Citation II at dusk]]
Features available in FlightGear include:

* Choice of two variants: the basic Citation II or the re-engined Sierra Super II
* Several liveries
* Several checklists
* Autostart
* Weight and speed limitations
* Tuned autopilot with built-in climb schedule
* Working speedbrakes (engage with {{key press|k}}, retract with {{key press|j}} - alternatively {{key press|Ctrl|b}} toggles the s/b's)
* Working thrust reversers (engage with {{key press|Del}}) on the Citation II only
* Support for the [[Walk_view|Walk View]]

At low altitude, this aeroplane is light and slow enough for sightseeing in the canyons. At high altitude, it is fast enough for medium-haul, multiple-hour flights and GPS navigation. You can fly VFR or IFR, with or without GPS.

== Download ==

=== For FlightGear 3.4 and earlier ===

[https://sourceforge.net/p/flightgear/fgaddon/460/tarball?path=/trunk/Aircraft/Citation Citation rev 460]

=== For FlightGear 3.5 and higher ===

* Subversion:
<syntaxhighlight lang="bash">
$ svn checkout http://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Citation Citation
$ svn up
</syntaxhighlight>

* Tarball:

[http://sourceforge.net/p/flightgear/fgaddon/HEAD/tarball?path=/trunk/Aircraft/Citation Citation HEAD]

== Startup ==
Use the aircraft checklist for startup instructions; alternatively, use the menu for autostart.

== Performance ==
{| class="wikitable"
|-
! !! Citation II !! Sierra Super II
|-
! Never exceed speed
| 263 KIAS || 263 KIAS
|-
! Typical cruise speed at FL410
| 330 KTAS || 380 KTAS
|-
! Range at MTOW and full fuel, FL410, full throttle
| 1900 nmi || 2500 nmi
|-
! Endurance (hours) at full throttle
| 5:45 || 6:33
|-
! Climb rate at sea level
| 3000 fpm || 6000 fpm
|-
! Climb to FL410
| 45 min (stepped) || 22 min (direct)
|-
! Thrust reversers
| yes || no
|}

== Autopilot ==
The autopilot will disengage 500 feet above ground level or below the decision height selected on the radio altimeter, whichever is highest. This implies that you must climb at least to 500 ft above ground before you engage the autopilot. In addition, you should never engage autopilot while manoeuvering; always stabilize the aeroplane before you engage autopilot.

When the FD OFF button is illuminated, the autopilot is OFF. Clicking this button will engage the autopilot in wing leveler (horizontal) and pitch hold (vertical) modes. You can also engage autopilot, with the same effects, with the AP ENGAGE button between the seats. The following lateral, vertical and speed modes are available:

=== Lateral modes ===
; Wing Leveler: All lights are off
; HDG: Follow the magnetic heading bug selected on the pilot's HSI.
; NAV: Follow the radial selected on either NAV1 or NAV2. Switch between NAV1 and NAV2 using the NAV/HSI button.
; GPS: Follow the course selected by GPS. To engage, click on the NAV button a second time.
; APR: Click this button to engage both NAV1 and glideslope for an ILS approach. Note that, since the autopilot will disengage at least 500 ft above ground, this aeroplane is certified only for CAT I ILS approaches; it has no autoland capability.

=== Vertical modes ===
; Pitch hold: All lights are off. Adjust pitch (in increments of 1 degree) with the PITCH wheel between the seats.
; ALT: Climb or descend to, then maintain the altitude selected with the ALT knob left of the ADF radio. You can adjust the selected altitude with this knob or with the PITCH wheel between the seats.
; V/S: Hold current vertical speed. Adjust the selected vertical speed with the PITCH wheel between the seats.

You should engage ALT mode in more or less level flight with an angle of attack no greater than 0.2 and airspeed at least 220 KIAS. The autopilot includes a climb schedule and will climb at a speed appropriate for your engines; it will automatically decrease the rate of climb as you gain altitude.

On the base Citation II, you need a stepped climb and 45 minutes to reach FL410. The first step should be at FL330 or thereabouts.

On the re-engined Super II, you can climb all the way to FL430 in one step, even at MTOW, provided you respect the prerequisites listed above before engaging ALT mode.

=== Speed modes ===
; Autothrottle: Engage and disengage with Ctrl+S to hold current indicated airspeed. Note that the real Citation II does not have this, so you may consider using autothrottle cheating.

== Radio navigation ==
Tune the two NAV and COM radios and the sole ADF radio on the cockpit.

=== Horizontal Situation Indicators ===
On startup, the captain's [[HSI|horizontal situation indicator]] uses NAV1 and the copilot's HSI uses NAV2. The NAV/HSI button under each HSI switches between NAV1 and NAV2; you can switch the HSIs independently. If the autopilot is engaged in NAV mode, then the autopilot will also switch between NAV1 and NAV2, always following the radio selected on the captain's HSI. The best usage of this feature is as follows:

# Tune the NAV1 radio to a VOR beacon.
# Select the NAV1 radial on the captain's HSI.
# Fly the selected radial.
# Tune the NAV2 radio to another VOR beacon.
# Select the NAV2 radial on the copilot's HSI.
# When you intercept the radial selected on NAV2, click on the NAV/HSI button on the captain's side. The autopilot will now follow the NAV2 radial.
# Switch the copilot's HSI to NAV1.
# Tune NAV1 to a third VOR beacon.
# Select the NAV1 radial on the copilot's HSI.
# Repeat as necessary.

The two HSIs feature an integrated Radio Magnetic Indicator: the thin red arrow points to the selected VOR beacon (either NAV1 or NAV2). They also have a built-in Distance Measuring Equipment showing the distance between you and the selected beacon, in nautical miles.

=== Radio Magnetic Indicators ===
The cockpit has additional Radio Magnetic Indicators on both the pilot and copilot side. This indicator has two arrows and two buttons:

* The ''left'' button switches the single-stemmed arrow to point either to the NAV1 VOR beacon or to the NDB.
* The ''right'' button switches the double-stemmed arrow to point either to the NAV2 VOR beacon or to the NDB.

Combined with the HSI you can have arrows pointing simultaneously to all three beacons. By default:

* The ''single-stemmed'' arrow points to the NDB selected on the ADF radio
* The ''double-stemmed'' arrow points to the VOR beacon selected on the NAV2 radio
* The ''thin red needle'' of the HSI points to the VOR beacon selected on the NAV1 radio

=== Glideslope NAV1 indicator ===
To the left of the pilot's HSI is an additional NAV1 indicator with two needles; this merely repeats localizer and glideslope information from the HSI and from the attitude indicator.
Thus you have triple redundancy :) This instrument is hardwired to NAV1, so you can fly an ILS approach by hand while simultaneously pointing your HSI at the NAV2 beacon.

=== Distance Measuring Equipment ===
The DME shows the distance in nautical miles to the selected beacon. You can use it either to repeat the information on the HSI or to show the distance to the other beacon.
This instrument also shows your speed towards or from the beacon (''not'' your groundspeed: Only the component of your groundspeed that is on the line between you and the beacon), or
the time to go to the beacon in minutes at your current speed.

=== Control Display Unit ===
The CDU on the central console allows you to create a simple route from one airport to another.

To create a route:

# Click on the DEP ARR button.
# Type the ICAO code of your departure airport.
# Click on the ORIGIN (top left) button.
# Type the ICAO code of your destination airport.
# Click on the DEST (top right) button.
# Optionally type the departure runway number then click the RWY button.
# Click ACTIVATE.

This activates the Route Manager, which you can of course still control with the generic Route Manager dialog.

== Development ==
=== Recently updated ===
==== Systems ====
* Several checklists have been added.
* A realistic startup procedure.
* A major overhaul of the Autopilot-systems.
* The FDM got upgraded and several bugs got fixed in the process.
* All knobs can now be turned with the mouse-wheel.
* Some circuit breakers have been made functional, mainly on pilots side cb-panel.

==== Instruments ====
* Added a new Lighting Panel to the pilots panel. All knobs and switches, which actually have a function are animated.
* Instrument Panel got new textures. Looks a bit more used now.
* RMI now is switchable on Nav1/ADF and Nav2/ADF.
* HSI can be switched between Nav1/Nav2/GPS with the AP control panel's NAV-button.
* A CDU was added on the center pedestal.

==== Model ====
* All lights are now Rembrandt-capable.
* ALS flame / heat blur effect was added.
* ALS glass shader was added.
* The missing door-ladder was added and animated.
* Baggage compartments were added and doors animated.
* The speedbrakes got a major overhaul and are now much closer to the real thing, also the lower speedbrakes are added and animated.
* Small details like pitot tubes and antennas were added.
* Several small additions to the cockpit and cabin, including an accurate circuit breaker panel, with some functionality for now.
* Wing-flex has been added

=== Todo ===
* Create different liveries for Citation II and Sierra Super II.
* CDU needs more functions and bug fixes.
* Add some baggage.
* Add new GPS unit.
See [http://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation/ToDo.txt ToDo.txt @ sourceforge]

== External links ==
* {{wikipedia|Cessna Citation II}} Wikipedia article
* [http://www.sijet.com/page727822 Corporate site for the Sierra Super II aftermarket modification]

{{Cessna}}

Cessna 550 Citation II/info

2017-03-17T00:32:52Z

Chris blues: fix typo

<includeonly>{{infobox aircraft
| name = Cessna 550 Citation II
| hangar = fgaddon
| aircraft = Citation
| image = CitationII 2015-03-29.jpg
| image2 = CitationII Cockpit.png
| alt2 = The cockpit of a Cessna 550
| type = Business jet/Business aircraft
| config = Low wing aircraft
| propulsion = Jet aircraft
| manufacturer = Cessna
| authors = Curtis Olson/Syd Adams/Ludovic Brenta/chris_blues
| fdm = YASim
| fgname = Citation-II/Sierra-Super-II
| status-fdm = 5
| status-systems = 4
| status-cockpit = 5
| status-model = 5
| ready = rembrandt/checklist/tutorials
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 550 Citation II]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Cessna 550 Citation II/info

2017-03-17T00:31:29Z

Chris blues: add checklist and tutorial support

<includeonly>{{infobox aircraft
| name = Cessna 550 Citation II
| hangar = fgaddon
| aircraft = Citation
| image = CitationII 2015-03-29.jpg
| image2 = CitationII Cockpit.png
| alt2 = The cockpit of a Cessna 550
| type = Business jet/Business aircraft
| config = Low wing aircraft
| propulsion = Jet aircraft
| manufacturer = Cessna
| authors = Curtis Olson/Syd Adams/Ludovic Brenta/chris_blues
| fdm = YASim
| fgname = Citation-II/Sierra-Super-II
| status-fdm = 5
| status-systems = 4
| status-cockpit = 5
| status-model = 5
| ready = rembrandt/checklist/tutorial
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 550 Citation II]].
[[Category:Aircraft infobox documentation]]
</noinclude>

State overlay system

2017-03-15T00:21:16Z

Chris blues: /* Background */ Add links to Citation and J3Cub

{{Stub}}

== Objective ==

== Status ==
To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

For now there is no definitive list of possible states. These are my first suggestions:

* parking (meaning cold and dark)
* taxi (all systems running and ready to taxi)
* take-off (standing on the runway with take-off configuration)
* cruise (cruise configuration)
* approach (approach configuration)

== Implementation ==
=== overlay file ===
To add state overlays to your aircraft, create a folder called <code>states</code>. In there you can put your <code>$state-overlay.xml</code>. In the beginning your overlay.xml should look like this:
<pre>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<PropertyList>
<name type="string" n="1">parking</name>
<overlay>

</overlay>
</PropertyList>
</pre>
Now you can put your items, which need to be set between the overlay tags. You only need to put properties in there, which differ from your default setup.

Another rule of thumb is that you use the hierarchy of the property-tree's root. It speeded up my research by quite a bit, when I found out, it's possible to [[Howto:Create_animation_XML_files_from_Nasal|dump the PropertyTree]] with a nasal command. Open up the Nasal-console from the developer-menu and put in the following: <code>io.write_properties( path: "/home/myName/.fgfs/Export/PropTree.xml", prop: "/" );</code>

Beware! This outputs the '''entire''' PropertyTree! This is several thousand lines long. You might want to dump only single folders of the PropertyTree by changing the <code>"/"</code> to sth like <code>"/controls"</code> or whatever folder you want to dump. Now you can simply delete everything from that file, that you don't need and copy&paste it into your overlay.xml.

=== include ===
Now you need to include your overlay.xml in your <code>$Aircraft-set.xml</code> file like this:
<pre>
<PropertyList>
<sim>
...
<state include="states/parking-overlay.xml" n="0" />
<state include="states/taxi-overlay.xml" n="1" />
...
</sim>
</PropertyList>
</pre>

== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

At this moment, the [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Citation Citation] and the [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/J3Cub J3 Cub] have this implemented.

== Motivation ==

== Related ==

== References ==
{{Appendix}}

State overlay system

2017-03-15T00:14:52Z

Chris blues: /* overlay file */

{{Stub}}

== Objective ==

== Status ==
To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

For now there is no definitive list of possible states. These are my first suggestions:

* parking (meaning cold and dark)
* taxi (all systems running and ready to taxi)
* take-off (standing on the runway with take-off configuration)
* cruise (cruise configuration)
* approach (approach configuration)

== Implementation ==
=== overlay file ===
To add state overlays to your aircraft, create a folder called <code>states</code>. In there you can put your <code>$state-overlay.xml</code>. In the beginning your overlay.xml should look like this:
<pre>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<PropertyList>
<name type="string" n="1">parking</name>
<overlay>

</overlay>
</PropertyList>
</pre>
Now you can put your items, which need to be set between the overlay tags. You only need to put properties in there, which differ from your default setup.

Another rule of thumb is that you use the hierarchy of the property-tree's root. It speeded up my research by quite a bit, when I found out, it's possible to [[Howto:Create_animation_XML_files_from_Nasal|dump the PropertyTree]] with a nasal command. Open up the Nasal-console from the developer-menu and put in the following: <code>io.write_properties( path: "/home/myName/.fgfs/Export/PropTree.xml", prop: "/" );</code>

Beware! This outputs the '''entire''' PropertyTree! This is several thousand lines long. You might want to dump only single folders of the PropertyTree by changing the <code>"/"</code> to sth like <code>"/controls"</code> or whatever folder you want to dump. Now you can simply delete everything from that file, that you don't need and copy&paste it into your overlay.xml.

=== include ===
Now you need to include your overlay.xml in your <code>$Aircraft-set.xml</code> file like this:
<pre>
<PropertyList>
<sim>
...
<state include="states/parking-overlay.xml" n="0" />
<state include="states/taxi-overlay.xml" n="1" />
...
</sim>
</PropertyList>
</pre>

== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

== Motivation ==

== Related ==

== References ==
{{Appendix}}

State overlay system

2017-03-14T17:54:27Z

Chris blues: /* Implementation */

{{Stub}}

== Objective ==

== Status ==
To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

For now there is no definitive list of possible states. These are my first suggestions:

* parking (meaning cold and dark)
* taxi (all systems running and ready to taxi)
* take-off (standing on the runway with take-off configuration)
* cruise (cruise configuration)
* approach (approach configuration)

== Implementation ==
=== overlay file ===
To add state overlays to your aircraft, create a folder called <code>states</code>. In there you can put your <code>$state-overlay.xml</code>. In the beginning your overlay.xml should look like this:
<pre>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<PropertyList>
<name type="string" n="1">parking</name>
<overlay>

</overlay>
</PropertyList>
</pre>
Now you can put your items, which need to be set between the overlay tags. Rule of thumb is that you use the hierarchy of the property-tree's root. It speeded up my research by quite a bit, when I found out, it's possible to [[Howto:Create_animation_XML_files_from_Nasal|dump the PropertyTree]] with a nasal command. Open up the Nasal-console from the developer-menu and put in the following: <code>io.write_properties( path: "/home/myName/.fgfs/Export/PropTree.xml", prop: "/" );</code>

Beware! This outputs the '''entire''' PropertyTree! This is several thousand lines long. You might want to dump only single folders of the PropertyTree by changing the <code>"/"</code> to sth like <code>"/controls"</code> or whatever folder you want to dump. Now you can simply delete everything from that file, that you don't need and copy&paste it into your overlay.xml.

=== include ===
Now you need to include your overlay.xml in your <code>$Aircraft-set.xml</code> file like this:
<pre>
<PropertyList>
<sim>
...
<state include="states/parking-overlay.xml" n="0" />
<state include="states/taxi-overlay.xml" n="1" />
...
</sim>
</PropertyList>
</pre>

== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

== Motivation ==

== Related ==

== References ==
{{Appendix}}

State overlay system

2017-03-14T17:51:42Z

Chris blues: /* Implementation */ Add infos for state files

{{Stub}}

== Objective ==

== Status ==
To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

For now there is no definitive list of possible states. These are my first suggestions:

* parking (meaning cold and dark)
* taxi (all systems running and ready to taxi)
* take-off (standing on the runway with take-off configuration)
* cruise (cruise configuration)
* approach (approach configuration)

== Implementation ==
=== overlay file ===
To add state overlays to your aircraft, create a folder called <code>states</code>. In there you can put your <code>$state-overlay.xml</code>. In the beginning your overlay.xml should look like this:
<pre>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<PropertyList>
<name type="string" n="1">parking</name>
<overlay>

</overlay>
</PropertyList>
</pre>
Now you can put your items, which need to be set between the overlay tags. Rule of thumb is that you use the hierarchy of the property-tree's root. It speeded up my research by quite a bit, when I found out, it's possible to dump the PropertyTree with a nasal command. Open up the Nasal-console from the developer-menu and put in the following: <code>io.write_properties( path: "/home/myName/.fgfs/Export/PropTree.xml", prop: "/" );</code>

Beware! This outputs the '''entire''' PropertyTree! This is several thousand lines long. You might want to dump only single folders of the PropertyTree by changing the <code>"/"</code> to sth like <code>"/controls"</code> or whatever folder you want to dump. Now you can simply delete everything from that file, that you don't need and copy&paste it into your overlay.xml.

=== include ===
Now you need to include your overlay.xml in your <code>$Aircraft-set.xml</code> file like this:
<pre>
<PropertyList>
<sim>
...
<state include="states/parking-overlay.xml" n="0" />
<state include="states/taxi-overlay.xml" n="1" />
...
</sim>
</PropertyList>
</pre>

== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

== Motivation ==

== Related ==

== References ==
{{Appendix}}

State overlay system

2017-03-14T11:54:16Z

Chris blues: add implementation

State overlay system

2017-03-14T11:44:15Z

Chris blues: Move start parameter to status section

State overlay system

2017-03-14T11:42:48Z

Chris blues: /* Status */ add state list as a first template

{{Stub}}

To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

== Objective ==

== Status ==
For now there is no definitive list of possible states. These are my first suggestions:

* parking (meaning cold and dark)
* taxi (all systems running and ready to taxi)
* take-off (standing on the runway with take-off configuration)
* cruise (cruise configuration)
* approach (approach configuration)

== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

== Motivation ==

== Related ==

== References ==
{{Appendix}}

State overlay system

2017-03-14T11:09:53Z

Chris blues: add command line parameter

{{Stub}}

To start FlightGear with an existing overlay add <code>--state=statename</code> to you command line.

== Objective ==

== Status ==
== Background ==
Wayne Bragg has been working a bit with James on the state overly system.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35552024/
|title = <nowiki> [Flightgear-devel] FlightGear aircraft state support </nowiki>
|author = <nowiki> Wayne Bragg </nowiki>
|date = Dec 14th, 2016
|added = Dec 14th, 2016
|script_version = 0.36
}}</ref>

== Motivation ==

== Related ==

== References ==
{{Appendix}}

Talk:FFGo

2016-10-11T12:00:35Z

Chris blues: talk

About the Debian installation:<br>
A hint of<br>
<code>apt-get install --no-install-recommends ffgo python3-pil.imagetk geographiclib-tools python3-geographiclib</code><br>
might be helpful! Note the --no-install-recommends!

Cheers<br>
chris
:Hi Chris,
:
:Feel free to suggest the option, explaining why it is useful. I didn't think about it probably because I use aptitude, which handles Recommends in a nice way IME. It's a wiki, not my private sandbox. :)
:
:--[[User:Rominet|Rominet]] ([[User talk:Rominet|talk]]) 05:29, 11 October 2016 (EDT)

::Well, it took me hours (again) to get it right, reading up on the old thread on the forum, which is loong, until I found this little piece of information. So I thought, it might be easier to find here... Anyway, I've put a note-box under "Debian".
::[[User:Chris blues|Chris blues]] ([[User talk:Chris blues|talk]]) 06:58, 11 October 2016 (EDT)
:::Sorry it took you some time, and thanks for your contribution to the page. :-)
:::
:::BTW, there is a new apt command-line tool, since you seem to like apt-get.
:::<blockquote>apt provides a high-level commandline interface for the package management system. It is intended as an end user interface and enables some options better suited for interactive usage by default compared to more specialized APT tools like apt-get(8) and apt-cache(8).</blockquote>
:::
:::I haven't tried it, though.
:::--[[User:Rominet|Rominet]] ([[User talk:Rominet|talk]]) 07:51, 11 October 2016 (EDT)

::::Yes, I've tried apt and didn't like it. It does some things better, but all-in-all I like apt-get better. Things like scrolling through the terminal is important to me. :o)
::::Though I don't know, from the top of my head, if it resolves recommendations better than apt-get. Since it still uses apt-get - I doubt it. Maybe I'll try aptitude...
::::[[User:Chris blues|Chris blues]] ([[User talk:Chris blues|talk]]) 08:00, 11 October 2016 (EDT)

Talk:FFGo

2016-10-11T10:59:23Z

Chris blues:

Talk:FFGo

2016-10-11T10:58:52Z

Chris blues:

FFGo

2016-10-11T10:52:57Z

Chris blues: /* Debian */ mention the option for apt-get --no-install-recommends

{{-}}
{{Infobox Software
| title = FFGo
| image = FFGo LPMA-apt-tooltip-and-FG-cmd.png
| alt = Screenshot of FFGo 1.10.1
| developedby = Florent Rougon
| type = Graphical launcher for FlightGear
| initialrelease = 1.0.0 (Aug 21, 2015)
| latestrelease = 1.11.3 (Apr 30, 2016)

| writtenin = Python
| writteninversion = 3
| os = Unix-like (incl. Linux), Windows, MacOS X
| developmentstatus = Active (as of April 2016)
| website = http://frougon.net/projects/FFGo/
| license = {{wikipedia|WTFPL#Version 2|WTFPL version 2|noicon=1}}
}}

'''FFGo''' is a graphical launcher for FlightGear, and a fork of [[FGo!]]. It vastly improves on FGo! by fixing bugs and adding a host of new features.

== Features ==

One of the things that distinguish FFGo from other FlightGear launchers is the text window allowing one to write any (possibly advanced) [[Command_line_options|command line options]] that will be passed to FlightGear. This is similar, but more convenient and powerful, to editing the [[Fgfsrc|.fgfsrc]] configuration file. The main difference in power compared to editing .fgfsrc or using FGo! comes from FFGo's use of [http://frougon.net/projects/CondConfigParser/ CondConfigParser] to process the user's configuration. See [http://frougon.net/projects/FFGo/doc/README-conditional-config/ FFGo conditional config documentation] for more information on this aspect of FFGo.

In addition to this, FFGo offers:
* an easy setup (Preferences dialog);
* convenient selection of aircraft and startup airport or AI carrier;
* possibility to choose between identically-named aircrafts based on which directory they are stored in (using tooltips in the aircraft list);
* easy selection of startup runway or parking position, offering startup locations from apt.dat if there is no groundnet-defined parking position for the selected airport;
* detailed airport, runway, helipad and parking tooltips. Airport tooltips show things such as airport type (land airport, seaplane base or heliport), latitude, longitude, elevation, number of land runways, water runways, helipads, magnetic variation... Runway/helipad tooltips show runway type, length and width, surface type, magnetic as well as true heading, etc. Parking tooltips show similar information as runway tooltips, plus maximum aircraft radius, reserved airline codes... (note: The [http://geographiclib.sourceforge.net/html/MagneticField.1.html MagneticField] program from [http://geographiclib.sourceforge.net/ GeographicLib] is needed for magnetic data)
* easy consulting of METAR data for the nearest station relatively to the selected airport (if any);
* a ''Pressure Converter'' dialog to convert between inches of mercury (inHg) and hectopascals (hPa);
* a powerful Airport Finder dialog allowing one to easily find airports using various criteria: distance to a chosen, ''reference airport''; number of land runways, water runways, or helipads; length of the longest or shortest runway in the airport, etc. The table of results displays, among others, the distance and bearings between the reference airport and each “result airport”. It can be sorted according to any column with a simple click on the column header.
* a GPS Tool dialog allowing one to find the distance, initial and final bearings for the shortest path between two given airports. The dialog also computes the flight duration for a given ground speed, and vice versa.
* easy selection of one or more scenarios, allowing one to browse the description of each available scenario;
* realtime preview of the [[Command_line_options|arguments]] that would be passed to fgfs (the FlightGear executable) if the ''Run FG'' button were to be pressed;
* easy display of the output of ''fgfs --help --verbose'' for the selected FlightGear version (''Help → Show available fgfs options'');
* the possibility to copy to the clipboard a shell command that is equivalent to what FFGo would do if the ''Run FG'' button were to be pressed;
* the option to translate fgfs' ''--parkpos'' option into the corresponding combination of ''--lat'', ''--lon'' and ''--heading'' options. This behavior can be enabled using the ''Fake the --parkpos option'' checkbox found in the Miscellaneous tab of the Preferences dialog. It is useful when the ''--parkpos'' option is broken in FlightGear (which is unfortunately the case in FlightGear 2016.1.1 and in the ''next'' branch of [[FlightGear Git|FlightGear's Git repository]] as of March 2016);
* easy viewing and saving of FlightGear output (log);
* automatic FFGo + FlightGear log saving and rotating;
* complete German translation, complete French translation except for the help file ([https://github.com/frougon/FFGo/blob/master/ffgo/data/help/help_en en], [https://github.com/frougon/FFGo/blob/master/ffgo/data/help/help_fr fr]), other translations currently outdated (English is the language FFGo is written in, thus it is obviously complete, and not a translation ''per se'').

== Screenshots ==

=== Main window and Command Window ===

[[File:FFGo LPMA-apt-tooltip-and-FG-cmd.png|thumbnail|Airport tooltip and preview of the FlightGear command at Madeira (LPMA)]]

Starting from version 1.10.0, FFGo remembers how many days you used each aircraft, or visited each airport, during a user-defined period (see the ''Statistics'' tab in the ''Preferences'' dialog). This data is subject to expiration via configurable periods too. These simple statistics allow FFGo to know which aircrafts (resp. airports) you used (resp. visited) most during the selected period, and present them first in the aircrafts (resp. airports) list. You can still sort the lists based on other criteria if you wish (aircraft or airport name, airport ICAO code...) by simply clicking on the corresponding column headers. Click a second time on a given column header to reverse the sort order.

The FlightGear Command window shows exactly which arguments are going to be passed to the FlightGear executable (fgfs) when the ''Run FG'' button is clicked. It can be resized, hidden, detached (as in the screenshot) or attached to FFGo's main window.

{{Note|If you want to copy these arguments to the clipboard for use in a shell (“command line”), use the corresponding function from the Tools menu (''Copy FG shell-equivalent command''). This will prepend the configured path to the FlightGear executable, properly quote all arguments for a POSIX shell (which might contain spaces or other special characters), and separate them with spaces.}}

=== The Preferences dialog ===

<gallery mode="packed">
FFGo Prefs-window-FG-settings-tab-with-transparent-bg-behind-tooltip.png
FFGo Prefs-window-Statistics-tab-with-transparent-bg-behind-tooltip.png
FFGo Prefs-window-misc-tab.png</gallery>

=== The Tools menu ===

<gallery mode="packed">
FFGo Tools-menu.png
</gallery>

=== Selecting AI scenarios ===

<gallery mode="packed">
FFGo Scenarios-popup-menu-with-scenario-description.png
</gallery>

You may select one or more AI scenarios to load from the Scenarios popup menu. Selecting a scenario does nothing particular for FFGo, but each selected scenario will be passed as part of a ''--ai-scenario=...'' option to FlightGear when it is started. Left-clicking on a scenario name toggles selection of this scenario. Right-clicking displays its description.

=== Selecting an AI carrier ===

<gallery mode="packed">
FFGo Carrier-popup-menu.png
</gallery>

Instead of starting at an airport, you can select an AI carrier in the Carrier popup menu and FFGo will make you start there, automatically adding the corresponding AI scenario. In order to make the Carrier popup menu appear, just click on the airport ICAO code below the aircraft image.

If you choose a different carrier or quit “carrier mode” (by choosing None in the Carrier popup menu, or simply selecting an airport in the airport list), the scenario for the selected carrier will be automatically removed from the list of scenarios to load.

=== Weather info — the METAR widget ===

<gallery mode="packed">
Raw-metar.png
Decoded-metar.png
</gallery>

The METAR widget allows one to check the latest weather information for the selected airport. It is available from the Tools menu.

=== The Pressure Converter dialog ===

This dialog, accessible from the Tools menu, allows one to quickly convert a pressure value from inches of mercury (inHg) to hectopascals (hPa) and vice versa. This is useful when the QNH value obtained from METAR or ATIS (the “altimeter setting”) is not in a unit that is directly usable with your aircraft's instruments.

<gallery mode="packed">
FFGo_Pressure-converter-dialog.png
</gallery>

=== Airport metadata ===

==== Airport tooltips ====
<gallery mode="packed">
Hamburg-airport-tooltip.png
LFBD-decoded-METAR.png
</gallery>

==== Runway tooltips ====
<gallery mode="packed">
Hamburg-runway-23-tooltip.png
Beaver-Dam-Lake water-runway-tooltip.png
1001-Fourth-Avenue-Plaza helipad-tooltip.png
</gallery>

==== Parking tooltips ====
<gallery mode="packed">
KSFO-A10-parking-tooltip.png
</gallery>

=== The Airport Finder dialog ===
<gallery mode="packed">
Airports-around-LOWI.png
Longest-runways-around-Clermont-Ferrand.png
Water-runways-around-Cuba.png
Highest-number-of-helipads-in-the-world.png
</gallery>

The Airport Finder dialog, accessible under the Tools menu, allows one to easily find airports using various criteria: distance to a chosen, “reference airport”; number of land runways, water runways, or helipads; length of the longest or shortest runway in the airport, etc. Results are listed in a table giving these criteria for each airport as well as the initial and final bearings for the shortest path from or to the reference airport. The table of results can be sorted according to airport ICAO code, name or any of the aforementioned criteria (click on a column header to sort according to the corresponding field; click a second time on the same column header to reverse the sort order).

This dialog is fairly versatile, but one of the uses it is particularly well-suited for is to find a start airport in the desired range with respect to a given airport. For instance, let's say you saw on the [[MPMap|multiplayer map]] that someone is offering [[Air traffic control|Air Traffic Control (ATC)]] services at MHTG (just an example), and you are looking for an airport that is neither too close, nor too far from MHTG in order to take off there and land at MHTG, following instructions from the air traffic controller. Since it is possible, in the Airport Finder dialog, to sort found airports based on bearings from, or to the reference airport, you can also easily find airports that are, for instance, located more or less north-east of the reference airport. Many, many other things are possible. cf. [http://forum.flightgear.org/viewtopic.php?f=18&t=27054&p=269261#p268159 this forum message for more details].

=== The GPS Tool dialog ===

<gallery mode="packed">
Gps-tool-EGKK-LFML_1.9.0.png
</gallery>

The GPS Tool dialog allows one to find the distance, initial and final bearings for the shortest path between two given airports. The dialog also computes the flight duration for a given ground speed, and vice versa.

This dialog should be more convenient than the Airport Finder dialog for the cases where you already know the start and destination airports you are interested in, and you just want to get the results for these airports. Or you want to check several pairs of airports, and you know precisely which ones you want the calculations to be done for.

=== Seeing the available fgfs options ===

[[File:FFGo_Show-available-fgfs-options.png|thumbnail|FFGo displaying the output of <code>fgfs --help --verbose</code>]]

From version 1.11.0 onwards, FFGo allows one to easily see the output of <code>fgfs --help --verbose</code>, i.e.: the [[Command_Line_Options|command-line options]] supported by FlightGear. This is useful to get an idea of what can be put in the Options Window.

== Installation tips ==
=== Instructions — Read this first! ===
Since installation instructions may in general depend on the particular FFGo version you want to install, they are always included in release tarballs and zip files, precisely in the <tt>docs/INSTALL</tt> folder. Such tarballs and zip files can be downloaded from [http://frougon.net/projects/FFGo/ FFGo's home page] as well as from [https://pypi.python.org/pypi/FFGo FFGo's page on PyPI] (PyPI being [https://pypi.python.org/pypi the Python Package Index]). However, apart from the addition of a small number of optional dependencies, the installation method hasn't changed since FFGo 1.0.0, therefore there is little risk for now using the online [https://github.com/frougon/FFGo/blob/master/docs/INSTALL/INSTALL_en Git version of the installation guide].

The guide mentioned in the previous paragraph is rather detailed, because it explains a few concepts that may be new to users who are not Python developers, and tries to give general instructions covering all common cases, which is not very easy given that Python may or may not be shipped depending on the particular operation system in use (Windows, Linux, MacOS X, etc.). To the contrary, the following sections give specific instructions applicable in the most common cases on each OS where I know a working procedure. They are more practical, probably easier to follow than the installation guide, at the expense of being less generic.

=== Sample installations ===

==== Windows ====

===== Installing FFGo and its dependencies =====

Typical FFGo installation on Windows is easy, because there is no system Python shipped with Windows, therefore there is no risk of messing up your Windows installation by just installing or upgrading Python packages. The instructions below assume you have no existing Python installation on your Windows system.<ref name="SampleWindowsInstall.WhenHavingPythonAlreadyInstalled">If you do, the general principle is the same, but you'll have to make sure to invoke ''pip'' for the right Python installation, for instance with:<br/>
: <code>py -3.5 -m pip install FFGo Pillow geographiclib</code><br/>
to run ''pip'' with a Python 3.5 installation</code> (not having Windows, I haven't been able to test this myself; please remove this parenthesis if this works, otherwise report on the [http://forum.flightgear.org/viewtopic.php?f=18&t=27054 FFGo thread on the FlightGear forum] with enough details to allow me to help you).</ref> There we go:

<ol type="1">
<li>
Install Python 3.4 or later:
<ol type="a">
<li>
Download Python from the [https://python.org/ Python home page].
</li>
<li>
Make sure to enable the ''Tcl/tk'' and ''pip'' components in the
installer (this may be located under a label such as <i>Customize
installation</i>).
</li>
<li>
Don't change the default value for the Python installation folder, otherwise you are likely to run into permission problems: except for old versions of Windows, writing to <i>Program Files</i>, at least, is subject to special restrictions that may cause the <code>pip install</code> step to fail. Also take note of what this installation folder is—you may find this helpful later.
</li>
<li>
It is recommended ''not to disable'' the [https://docs.python.org/3/using/windows.html#launcher Python Launcher for Windows], as it may prove very useful later.
</li>
<li>
<p>
If you are not comfortable with the [[Command_line|command line]] (“Command Prompt”), it is suggested you choose <i>Add python.exe to Path</i> (or <i>Add Python X.Y to PATH</i>: the precise wording depends on the Python version). This way, you will be able to run the <tt>pip</tt> and <tt>ffgo</tt> programs directly at the Command Prompt in the simplest possible way (this mainly matters for <tt>pip</tt>, because for <tt>ffgo</tt>, you can easily create a shortcut on the Desktop, for instance).
</p>

<p>
<i>If you choose not to do this:</i>
</p>

<blockquote>
<p>
In such a case, assuming you didn't disable the [https://docs.python.org/3/using/windows.html#launcher Python Launcher for Windows] in the Python installer, you'll have to type commands such as:
</p>

<pre>py -3.5 -m pip install ...</pre>

<p>
instead of:
</p>

<pre>pip install ...</pre>

<p>
Such a command is similar to <code>pip install ...</code>, but makes sure that <tt>pip</tt> is run by Python 3.5, in case there are several Python installations on your Windows system.
</p>

<p>
Another way would be to call the desired <tt>pip</tt> executable by specifying its full path, like this:
</p>

<pre>C:\PythonXY\Scripts\pip install ...</pre>

<p>
(where <i>XY</i> would be <tt>35</tt> for a Python 3.5 installation, for instance)<br />
This method requires knowing where the Python installation you are interested in is installed (<tt>C:\PythonXY</tt> in this example), which seems to depend on the Windows version. Therefore, the <code>py -X.Y -m pip ...</code> method, using the [https://docs.python.org/3/using/windows.html#launcher Python Launcher for Windows], will be preferred here.
</p>
</blockquote>
</li>
</ol>
</li>
<li>
Open a terminal, also known as “Command Prompt”:

<p>
There are various ways to do this, depending on the version of Windows
in use. One way that should work is using the <tt>Windows+R</tt>
keyboard shortcut, then entering <tt>cmd.exe</tt> in the text input box.
Apparently (according to Google, see for yourself), on Windows 10, this
can (also?) be done with the <tt>Windows+X</tt> keyboard shortcut, then
choosing <i>Command Prompt</i> in the menu that should appear. If you
have never used the Command Prompt on Windows, reading the
[[Command_line|Command line page on the wiki]] would certainly be a good
idea.
</p>
</li>
<li>
In this terminal, type: <code>pip install FFGo Pillow geographiclib</code>

{{Note|[[File:FFGo - Windows installation using the Python Launcher for Windows (py).png|thumbnail|Windows installation under Python 3.5 using the Python Launcher for Windows (py)]]
<p>
If you didn't add Python to your PATH environment variable when installing it, the command would rather be something like:
</p>

<pre>py -3.5 -m pip install FFGo Pillow geographiclib</pre>

<p>
for a Python 3.5 installation. Specifying <code>-3</code> instead of <code>-3.5</code> would use the latest Python 3.x version installed on your system.
</p>}}

<p>
FFGo can work without Pillow and geographiclib, but it will offer more
features if you install them. The previous command should automatically
download and install FFGo from
[https://pypi.python.org/pypi/FFGo FFGo's page on PyPI].
</p>

{{Note|<code>pip install ffgo</code> has the same effect as <code>pip install FFGo</code>.}}

<p>
Also note that messages such as:
</p>

<blockquote>
<tt>warning: no previously-included files found matching 'docs\README.conditional-config\_static\README.txt'</tt>
</blockquote>

<p>
when running the <code>pip install ...</code> command are completely normal and harmless, just ignore them. This command should print something like:
</p>

<blockquote>
<tt>Successfully installed CondConfigParser FFGo Pillow geographiclib</tt>
</blockquote>

<p>
towards the end if all went well.
</p>
</li>
</ol>

After these steps, you should have a working FFGo. You can run it by double-clicking on either <tt>ffgo.exe</tt> or <tt>ffgo-noconsole.exe</tt> in a directory such as <tt>C:\Python</tt><i>XY</i><tt>\Scripts</tt>, where <tt><i>XY</i></tt> corresponds to the Python version that was used in the <code>pip install FFGo ...</code> command. These two executables do the same, except <tt>ffgo.exe</tt> opens a Windows terminal (“console”) containing all FFGo messages, while <tt>ffgo-noconsole.exe</tt> doesn't. You can safely use the latter most of the time. Should FFGo refuse to start for some reason, running <tt>ffgo.exe</tt> and examining/reporting the printed messages would certainly be helpful. You may want to create shortcuts for these files by right-clicking on the <tt>.exe</tt> file of your choice, choosing <i>Create Shortcut</i> and dragging the newly-created shortcut to the final, desired place (e.g., your desktop).

{{tip|If you wish, you can also run FFGo from a Command Prompt; here is how.

<p>
First, [[Command_line#Windows|open a Command Prompt]], then:
</p>

<ul>
<li>
if you chose to add <tt>python.exe</tt> to the PATH in the Python
installer as hinted above, just type <code>ffgo</code>;
</li>
<li>
otherwise:

<ul>
<li>
either run FFGo directly using a full path to one of its executables<ref name="Windows-allows-omitting-.exe-extension">As shown in the command, you may omit the <tt>.exe</tt> extension from the executable name.</ref><ref name="default-Python-install-path-depends-on-Windows-version">The default Python installation path (e.g., <tt>C:\Python<i>XY</i></tt>) seems to depend on the version of Windows, not only on the Python version (which would be <i>X.Y</i> in this example).</ref>, such as:

<pre>C:\PythonXY\Scripts\ffgo</pre>
</li>
<li>
or change to the containing directory, then run the executable you
want, as in:

<pre>C:
cd \PythonXY\Scripts
ffgo</pre>
</li>
</ul>
</li>
</ul>}}

The instructions given above install all dependencies of FFGo, except one optional dependency: the [http://geographiclib.sourceforge.net/html/MagneticField.1.html MagneticField] executable from [http://geographiclib.sourceforge.net/ GeographicLib] (see [[FFGo#A word about GeographicLib|below]]). To have a complete installation, that is able to show the magnetic variation at each airport and magnetic headings for runways, routes, etc., you need to do this in addition:

<ol>
<li>
<p>
Go to [http://geographiclib.sourceforge.net/html/install.html#binaryinst GeographicLib's installation page] and run the appropriate installer for your system. This will install the <tt>MagneticField.exe</tt> executable on your computer. Take note of the folder it is installed to, because you'll have to tell the full path of this program to FFGo, unless you let the GeographicLib installer modify your <tt>PATH</tt> environment variable.
</p>
<gallery mode="packed">
GeographicLib - Setup wizard (first screen).png
GeographicLib - License agreement.png
GeographicLib - Installation options without modifying PATH.png
GeographicLib - Installation location.png
GeographicLib - Creating Start menu folder.png
GeographicLib - End of installation wizard.png
</gallery>
</li>
<li>
<p>
<tt>MagneticField.exe</tt> needs one or more datasets to be installed, otherwise it can't work properly. To get such a dataset, go to [http://geographiclib.sourceforge.net/html/magnetic.html GeographicLib's page for magnetic models] and install the magnetic model data file(s) of your choice. <tt>wmm2015</tt> should be fine until 2020. You may also install the <tt>emm2015</tt> dataset, however I can't say whether this will bring any visible change for typical aviation usage.
</p>
<gallery mode="packed">
GeographicLib - Finding the download page for magnetic models.png
GeographicLib - Choosing a magnetic model for download.png
GeographicLib - WMM2015 magnetic model setup wizard.png
</gallery>
<p>
When asked for the installation folder, you should probably choose <tt>C:\ProgramData\GeographicLib</tt> as per the above link.
</p>
</li>
<li>
<p>
If you let the GeographicLib installer modify your <tt>PATH</tt> in step 1, there is nothing else to do. Otherwise, you have to tell FFGo where to find <tt>MagneticField.exe</tt>. In order to do this, start FFGo and open the <i>Settings → Preferences</i> dialog; go to the <i>Miscellaneous</i> tab, and enter the precise path for <tt>MagneticField.exe</tt> in the appropriate field (cf. step 1). Finally, click on <i>Save settings</i> and you should be done.
</p>
<gallery mode="packed">
FFGo - Opening the Preferences dialog (Windows screenshot).png
FFGo - Specifying a path to GeographicLib's MagneticField program.png
</gallery>
</li>
</ol>

The FFGo dialog reachable via <i>Help → About</i> displays the versions of the main dependencies used by FFGo. In case you entered an invalid path, or some other error, a hint is generally given there. In any case, troubleshooting information is always printed to the terminal (if you ran <tt>ffgo.exe</tt> as opposed to <tt>ffgo-noconsole.exe</tt>) and to the FFGo log file located in the <tt>%APPDATA%\FFGo\Logs</tt> folder (do a Google search with keywords “Windows” and “APPDATA” if you don't know what this means).

<strong>If for some reason you can't run <tt>pip</tt>:</strong>
# Write down exactly what you did, copy the error messages, take screenshots to make sure you won't miss anything, and report your problem in [http://forum.flightgear.org/viewtopic.php?f=18&t=27054 FFGo's thread on the FlightGear forum].
# If you feel adventurous and want to solve the problem all by yourself, a user reported success using the get-pip.py script as explained on [https://pip.pypa.io/ the pip home page]. Personally, I would first try running something like <code>py -3 -m ensurepip</code> from a Command Prompt, but both methods should work to install <tt>pip</tt> into a Python installation where it is missing (<code>py -3</code> invokes the [https://docs.python.org/3/using/windows.html#launcher Python Launcher for Windows] to automatically find the latest Python 3.x installation present on your system; you can use <code>py -3.5</code> to invoke Python 3.5, etc.).

===== Updating the software =====

<p>The method for updating software installed via <tt>pip</tt> is basically
the same as on Linux. The main difference compared to the instructions given
in the Linux section is that the procedure described here uses <tt>pip</tt>
directly on your Python installation, whereas the procedure given for Linux
below uses a virtual environment. This means that instead of doing stuff
like:</p>

<pre><venv-dir>/bin/pip ...</pre>

<p>as in the Linux section, you just need to do:</p>

<pre>pip ...</pre>

<p>here (it is assumed that the <tt>pip</tt> executable is in your PATH, which
should be the case if you chose <i>Add python.exe to Path</i> in the Python
installer). Otherwise, just replace <tt>pip</tt> with its full path (something
like <tt>C:\Python<i>XY</i>\Scripts\pip.exe</tt>, where <tt><i>XY</i></tt>
corresponds to the Python version). So, here we go:</p>

<p>Open a terminal (also known as “Command Prompt”) as explained above in the
section concerning installation, and <strong>examine what we have installed with
<tt>pip</tt>:</strong></p>
<pre>C:\> pip list
CondConfigParser (1.0.2)
FFGo (1.9.0)
geographiclib (1.45)
Pillow (3.1.0)
pip (1.5.6)
setuptools (18.8)</pre>

{{Note|If the <tt>pip</tt> executable is in your PATH, it shouldn't matter in general whether the prompt starts with <tt>C:\</tt>, <tt>C:\Windows</tt>, <tt>C:\Users\UserName</tt> or whatever—this part, up to and including the <tt>></tt> character, is called the <i>prompt</i>, and the actual <i>command</i> is what you type afterwards.}}

<p>Now, <strong>let's see what can be updated:</strong></p>
<pre>C:\> pip list --outdated
setuptools (Current: 18.8 Latest: 19.5)
pip (Current: 1.5.6 Latest: 8.0.2)</pre>

<p>Only <tt>setuptools</tt> and <tt>pip</tt> are out-of-date in this venv,
<strong>let's upgrade</strong> them:</p>
<pre>C:\> pip install --upgrade setuptools pip
Downloading/unpacking setuptools from https://pypi.python.org/packages/3.5/s/setuptools/setuptools-19.5-py2.py3-none-any.whl#md5=c44407cb10f9b231f5a05908dea1a803
Downloading setuptools-19.5-py2.py3-none-any.whl (471kB): 471kB downloaded
Downloading/unpacking pip from https://pypi.python.org/packages/py2.py3/p/pip/pip-8.0.2-py2.py3-none-any.whl#md5=2056f553d5b593d3a970296f229c1b79
Downloading pip-8.0.2-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded

[...]

Successfully installed setuptools pip
Cleaning up...</pre>

<p>This is it. We have updated the two <tt>pip</tt>-installed packages that
were not at their latest stable version. Of course, had FFGo been listed as
outdated too, we could have updated it this way:</p>
<pre>C:\> pip install --upgrade ffgo</pre>

<p>which, by the way, can be shortened this way if you wish:</p>

<pre>C:\> pip install -U ffgo</pre>

===== Using development snapshots, release candidates, etc. =====

<p>The instructions given above for <tt>pip</tt>-installed Python software
only upgrade to releases labelled as “stable” by their upstream maintainers.
Sometimes, you'll want to try a beta or development release of FFGo for
instance, especially if you didn't install it from the Git repository (which
is only covered in the Linux section in order to keep things simple here).
To do this, the method is the same as previously described, except that you
have to pass <code>pip install</code> the <tt>--pre</tt> option to indicate
that you are ready to install a version that is not necessarily labelled as
“stable”. Therefore, instead of upgrading FFGo with:</p>

<pre>C:\> pip install --upgrade ffgo</pre>

you would use:

<pre>C:\> pip install --upgrade --pre ffgo</pre>

{{Note|Development snapshots have version numbers such as 1.9.0.dev2; beta versions have numbers like 1.9.0b1; for release candidates, the version number can be of the form 1.9.0c2 or 1.9.0rc2, etc. All this is explained in [https://www.python.org/dev/peps/pep-0440/ PEP 0440] if you are interested.}}

===== Uninstalling the software =====

<p>If you installed FFGo using the instructions given above, you can remove it
by simply running:</p>

<pre>C:\> pip uninstall ffgo</pre>

<p>from a Windows terminal (“Command Prompt”). This assumes you chose <i>Add
python.exe to Path</i> in the Python installer. Otherwise, just replace
<tt>pip</tt> with its full path (something like
<tt>C:\Python<i>XY</i>\Scripts\pip.exe</tt>, where <tt><i>XY</i></tt>
corresponds to the Python version).</p>

<p>This command only removes FFGo, of course. You can remove other packages
listed by the <code>pip list</code> command using the same method. And you can
also uninstall Python if you so desire, using standard methods for software
installed on Windows.</p>

==== Linux ====

===== Using distribution packages =====

====== Debian ======

Debian packages for FFGo have been prepared by the FFGo upstream maintainer,
Florent Rougon. They can be downloaded and installed normally using
''apt-get'', ''aptitude'', etc. provided you have installed
[http://frougon.net/OpenPGP-key.asc Florent's OpenPGP key].

<ul>
<li>'''First step: install Florent Rougon's OpenPGP key into the <tt>apt</tt> keyring'''

<p>There are two main ways to get the key:</p>

<ol style="list-style-type: lower-alpha"><li>The [https://www.gnupg.org/ GnuPG] way is:

<ol style="list-style-type: decimal"><li>Get the key from a key server (as
defined in your GnuPG configuration):
<syntaxhighlight lang="shell" enclose="div">
gpg2 --recv-keys C785B90B5053A3A2
gpg2 --list-keys --fingerprint C785B90B5053A3A2
</syntaxhighlight>

the output of which should show the [http://frougon.net/keys.html correct fingerprint]:

<pre>pub rsa4096/0xC785B90B5053A3A2 2010-03-17 [expires: 2016-10-19]
Key fingerprint = 125B 5A0F DB78 8FDD 0EF4 1A9D C785 B90B 5053 A3A2</pre>

Normally, in the OpenPGP model, you would get the fingerprint by a really secure
channel (e.g., meeting Florent in person) or you would rely on the <i>web of
trust</i> (trusting someone who trusts someone who... who trusts this key
actually belongs to Florent. The chain verification is automated by
<tt>gpg</tt>/<tt>gpg2</tt>—name of the main [https://www.gnupg.org/ GnuPG]
command—using digital signatures, done with each participant's key).
</li>
<li>Then, in order to have the key in a separate file, say <tt>~/tmp/flo-key</tt>, you can run:

<syntaxhighlight lang="shell" enclose="div">
gpg2 --export -o ~/tmp/flo-key C785B90B5053A3A2
</syntaxhighlight> (using <tt>~/tmp/flo-key</tt> to avoid symlink
attacks—using <tt>/tmp</tt> instead of <tt>~/tmp</tt> wouldn't be a great idea).</li></ol>
</li>
<li>The other way is getting [http://frougon.net/OpenPGP-key.asc the key] from [http://frougon.net/ Florent's home page] (it is linked from [http://frougon.net/keys.html that page] on Florent's site). In short, assuming you have the <tt>wget</tt> package installed, you can get the key with:

<syntaxhighlight lang="shell" enclose="div">
wget -O ~/tmp/flo-key http://frougon.net/OpenPGP-key.asc
</syntaxhighlight></li>
Once you have that key in the file <tt>flo-key</tt>, you can install it for <tt>apt</tt> by running, <i>as root</i>:

<syntaxhighlight lang="shell" enclose="div">
apt-key add flo-key
</syntaxhighlight>

One could even combine the two operations into a single command (getting the key and installing it into <tt>apt</tt>'s keyring):

<syntaxhighlight lang="shell" enclose="div">
wget -O- http://frougon.net/OpenPGP-key.asc | apt-key add -
</syntaxhighlight>

but this would have to be done as root, which I don't like much for <tt>wget</tt> (this can
be overcome by using <tt>ssh</tt>, maybe also with <tt>sudo</tt>, but it is
a bit out of scope here).
</ol>
</li>
<li>
'''Second step: add the relevant lines to your <tt>/etc/apt/sources.list</tt> file'''

<p>Add the following lines to your <tt>/etc/apt/sources.list</tt>:</p>

<pre>deb http://frougon.net/debian-ffgo unstable main
deb-src http://frougon.net/debian-ffgo unstable main</pre>

<p>(replace <tt>unstable</tt> with <tt>jessie</tt> if you are using <i>jessie</i>)</p>
</li>
<li>'''Third step: update the <tt>apt</tt> package list'''

<p>This is typically done with:</p>

<pre>apt-get update</pre>

or

<pre>aptitude update</pre>

etc., depending on the Debian package manager you are using.
</li>
<li>'''Final step: install the packages'''

<p>Install the ffgo package, at least. It is also recommended to install:</p>
<ul>
<li><tt>python3-pil.imagetk</tt>, otherwise you won’t be able to see the aircraft thumbnails;</li>
<li><tt>geographiclib-tools</tt> for the <tt>MagneticField</tt> program, in order to be able to see the magnetic variation at a given airport, magnetic headings, etc.;</li>
<li><tt>python3-geographiclib</tt> if available for your distribution (i.e., after <i>jessie</i>), for better geodesic calculations.</li></ul>

<p>In other words, if you are using ''unstable'', you can run:</p>

<pre>apt-get install ffgo python3-pil.imagetk geographiclib-tools python3-geographiclib</pre>

If you are using ''jessie'' without any backport of <tt>python3-geographiclib</tt>, run this instead:

<pre>apt-get install ffgo python3-pil.imagetk geographiclib-tools</pre>

{{Note|To avoid pulling in the entire FlightGear packages, you could tell apt-get to not install the recommendations in the deb file:<br>
<code>apt-get install --no-install-recommends ffgo python3-pil.imagetk geographiclib-tools python3-geographiclib</code><br>
This is useful, if you have FG installed some other way, than by your package manager.}}

{{Note|Installing the <tt>geographiclib-tools</tt> package is not enough to have the <tt>MagneticField</tt> program working. This program needs one or more datasets which are not part of the <tt>geographiclib-tools</tt> package. One easy way to install the minimal dataset on Debian is to run the following command with root privileges:

<pre>/usr/sbin/geographiclib-get-magnetic minimal</pre>

This will automatically download and install a minimal dataset under <tt>/usr/share/GeographicLib/magnetic</tt>, where it can be found by <tt>MagneticField</tt> (not registering the added files with <tt>dpkg</tt> though, which is a bit ugly, cf. [https://bugs.debian.org/687253 Debian bug #687253]). Otherwise, you can read the [http://geographiclib.sourceforge.net/html/MagneticField.1.html MagneticField(1) manual page] which explains how to tell MagneticField where he should look to find the datasets it needs.}}

Once the <tt>ffgo</tt> package is installed, FFGo can be run from the [http://freedesktop.org/ freedesktop] menu and, obviously, from the command line (the command name is <tt>ffgo</tt>).
</li>
</ul>

===== Using pip (generic method) =====

====== A word about pip and Python virtual environments ======

[https://pip.pypa.io/ pip] is nowadays' standard, OS-independent tool for
clean installation, upgrade and removal of Python packages. The method
described in this section should thus be applicable to any distribution (even
to non-Linux OSes, provided you can install Python and pip, and know where
the installed Python executable can be found).

The first thing to understand is that, when installing Python packages
with [https://pip.pypa.io/ pip], the destination directory is by default
''entirely determined'' by the particular Python interpreter used to run pip. For
instance, let's assume you have several Python installations:
* one of Python 2.7 reachable via <tt>/usr/bin/python</tt>, with third-party packages located in <tt>/usr/lib/python2.7/dist-packages</tt> (this would be Debian or a derivative—other distributions are more likely to use /usr/lib/python2.7/site-packages);
* one of Python 3.4 reachable via <tt>/usr/bin/python3.4</tt>, with third-party packages in <tt>/usr/lib/python3/dist-packages</tt><ref name="PYC-Repository-Directories">Python 3.2 and later are smart enough with <tt>.pyc</tt> files to allow using only one base directory for all Python versions, cf. ''PEP 3147: PYC Repository Directories'' in [https://docs.python.org/3/whatsnew/3.2.html What’s New In Python 3.2]</ref>;
* and one of Python 3.5 that you compiled yourself and installed in <tt>/opt/python3.5</tt>, with the interpreter executable being <tt>/opt/python3.5/bin/python3</tt>, and third-party packages located in <tt>/opt/python3.5/lib/python3.5/site-packages</tt>.

If you run pip this way:
<pre>/opt/python3.5/bin/python3 -m pip install FFGo</pre>
(think of <code>/opt/python3.5/bin/python3 -m pip</code> as the name of the <tt>pip</tt> command) then FFGo will be installed for the interpreter you compiled yourself, with Python modules under <tt>/opt/python3.5/lib/python3.5/site-packages</tt> and executables in <tt>/opt/python3.5/bin</tt>. This should be fine. However, if you run this pip invocation with <tt>/usr/bin/python</tt> instead of <tt>/opt/python3.5/bin/python3</tt>, then it will try to install things under <tt>/usr/lib/python2.7/dist-packages</tt> and in <tt>/usr/bin</tt>, which is certainly a bad idea with most Linux distributions (and that would require root permissions, but don't do it unless you ''really'' know what you are doing). The same would apply if the command were to be run with <tt>/usr/bin/python3.4</tt>: it is a bad idea, because it would step on the toes of a Python installation from your Linux distribution.

So, what can we do short of compiling Python ourselves? The canonical answer is to use pip <em>in a [https://docs.python.org/3/library/venv.html#venv-def virtual environment]</em>. Quoting the Python documentation:

<blockquote>A <i>virtual environment</i> (also called a <i>venv</i>) is a Python environment such that the Python interpreter, libraries and scripts installed into it are isolated from those installed in other virtual environments, and (by default) any libraries installed in a “system” Python, i.e. one which is installed as part of your operating system.</blockquote>

In other words, you may create as many virtual environments from a given
“base” Python installation as you want. Then, when you install, upgrade or
remove a Python package from one of these virtual environments, it will have
no effect on the other virtual environments nor on the base installation.
Since virtual environment creation and package installation with pip is very
quick and easy, virtual environments are quite convenient to experiment with
Python packages without taking the risk of messing up your system.

For more explanations on all this, you can read [https://github.com/frougon/FFGo/blob/master/docs/INSTALL/INSTALL_en FFGo's INSTALL_en file].

====== General idea of the method ======

The general idea behind the [https://pip.pypa.io/ pip]-based method explained here is the following:
<ol style="list-style-type: decimal"><li>First, you '''choose a Python interpreter''', for instance <tt>/usr/bin/python3.4</tt>, '''and create a virtual environment from this Python interpreter'''.
The interesting thing, with this kind of workflow, is that you never need to install packages as root, except for the base stones such as <tt>python3</tt> and <tt>python3-tk</tt><ref name="python-debian-package-names">These are package names used in Debian; other distributions may ship the same software components under slightly different names.</ref>, which are part of a standard Python installation. These can be installed normally using your usual distribution tools: <tt>apt-get</tt>, <tt>aptitude</tt> or <tt>dpkg</tt> for Debian and derivatives; <tt>yum</tt> or <tt>rpm</tt> for Redhat and derivatives, <tt>pacman</tt> for Arch Linux, etc. Therefore, using this method, there is no risk of messing up your Linux system (contrary to people coming up with crappy installation scripts and telling you to run them as root and hope for the best). A virtual environment can be created as a simple user, like this:

<syntaxhighlight lang="shell" enclose="div">
/usr/bin/python3.4 -m venv <venv-dir>
</syntaxhighlight>

Just as for the [https://pip.pypa.io/ pip] command explained above, think of <code>/usr/bin/python3.4 -m venv</code> as the name of a program (it just runs the main function of the Python <tt>venv</tt> module). In the above command, you can freely choose the <venv-dir> directory. It is just a directory that is going to contain the newly-created virtual environment once this command returns (therefore, you shouldn't have anything inside it before running the command, otherwise that would be messy).

<p>Notes:</p>
<blockquote>
<ul><li><p>Some systems may provide executables named <tt>pyvenv-3.4</tt> or similar. For instance, on Debian, <tt>/usr/bin/pyvenv-3.4</tt> is a “shortcut” for <code>/usr/bin/python3.4 -m venv</code>. Thus, one may type:</p>

<syntaxhighlight lang="shell" enclose="div">
/usr/bin/pyvenv-3.4 <venv-dir>
</syntaxhighlight>

<p>to obtain the same effect as above: creating a virtual environment in <venv-dir> based on the Python interpreter <tt>/usr/bin/python3.4</tt>. Thanks to shell command history, using <code>/usr/bin/python3.4 -m venv</code> is not much of a problem, and since this makes it quite clear which Python interpreter is going to be used, I'll favor this syntax here rather than the shorter syntax based on <tt>pyvenv-3.4</tt>.</p>
</li>
<li>
<p>
If you use Debian <i>unstable</i>, be sure to have the <tt>python3.5*</tt>
packages in version 3.5.1-8 or newer (these were uploaded on March 18,
2016). With earlier versions, creating a virtual environment
[https://bugs.debian.org/815864 could fail]. Workarounds have been given in
[http://forum.flightgear.org/viewtopic.php?f=18&t=27054&p=278031#p278031 this message on the FlightGear forum],
but the simplest thing to do now is to just make sure that your
<tt>python3.5*</tt> packages are recent enough.
</p>
</li>
</ul>
</blockquote>

</li><li>'''Once you have a virtual environment''' (and you can have as many as you wish), '''you can install, upgrade and uninstall Python packages inside it as a simple user''', like this:

<syntaxhighlight lang="shell" enclose="div">
<venv-dir>/bin/pip install package_1 package_2 ... package_n
<venv-dir>/bin/pip install --upgrade package_1 package_2 ... package_n
<venv-dir>/bin/pip uninstall package_1 package_2 ... package_n
</syntaxhighlight>

<p>Such installations are done ''in the venv'' based at <venv-dir>, therefore the <tt>ffgo</tt> executable obtained after running <code><venv-dir>/bin/pip install ffgo</code> will be <tt><venv-dir>/bin/ffgo</tt>.</p>

<p>In order to save some typing afterwards, you may want to create an alias for this command in your <tt>~/.bashrc</tt>, <tt>~/.zshrc</tt>, etc.<ref name="creating-ffgo-alias-in-Unix-shells>A line such as:
<pre>alias ffgo="<venv-dir>/bin/ffgo"</pre>
should be enough to create the alias in typical Unix shells.</ref>. This way, you'll be able to just run <tt>ffgo</tt> from a terminal. Alternatively, you can create a <tt>/usr/local/bin/ffgo</tt> symlink pointing to <tt><venv-dir>/bin/ffgo</tt>.</p></li></ol>

====== Sample installation sessions ======

In this section, I'll give two sample installation sessions using the [https://pip.pypa.io/ pip]-based method explained above. Both sessions start by installing the major dependencies of FFGo (Python 3 and Tkinter) with usual distribution tools. Then, the first session installs FFGo and the rest of its dependencies with pip, whereas the second session installs the rest of the dependencies with pip, but clones FFGo itself from its [https://github.com/frougon/FFGo Git repository] (this is best if you want to follow FFGo development). In this second case, it is not useful to install FFGo <i>per se</i>: it can be run directly from the Git repository clone using the [https://github.com/frougon/FFGo/blob/master/ffgo-launcher.py ffgo-launcher.py] script shipped with FFGo.

These sample sessions are given for Debian—at least for now—but the method is generic and can be applied to other distributions (the <tt>apt-get</tt> commands will have to be adapted, obviously):
<ol style="list-style-type: decimal"><li>
<p><em><strong>First session:</strong> installing FFGo (and some of its
dependencies, such as
[http://frougon.net/projects/CondConfigParser/ CondConfigParser])
using <tt>pip</tt> in a virtual environment.</em></p>

<ul><li>
<p>First, as root:</p>

<p>Mandatory:</p>
<pre>apt-get install python3 python3-tk python3-venv</pre>

<p>Optional—may help if you want to compile Pillow (which is automatically
done if you install it using pip):</p>
<pre>apt-get install gcc libpython3-dev tcl-dev tk-dev</pre>

<p>If the Pillow installation (later) fails even with this,
run the following command as root:</p>
<pre>apt-get build-dep python3-pil.imagetk</pre>

<p>This will install more packages, but should definitely allow you to compile
Pillow.</p>

<p>Optional: to have magnetic declination, magnetic headings, etc.:</p>
<pre>apt-get install geographiclib-tools
# Install a minimal dataset for the MagneticField program
/usr/sbin/geographiclib-get-magnetic minimal</pre>

<p>Highly optional, for better precision (no idea if one can see the
difference for typical aviation needs):</p>
<pre>/usr/sbin/geographiclib-get-magnetic emm2015</pre>
</li>
<li><p>Then, <strong>as an unprivileged user:</strong></p>

<p>Create a virtual environment in <tt>~/my-venvs/venv1</tt>, linked to the
base Python installation that provides <tt>/usr/bin/python3.4</tt>:</p>
<pre>~ % mkdir -p ~/my-venvs && cd ~/my-venvs
~/my-venvs % /usr/bin/python3.4 -m venv venv1</pre>

<p>Check what we have in there:</p>
<pre>~/my-venvs % ls venv1
bin include lib lib64 pyvenv.cfg</pre>

<p>Install FFGo in this venv using the <tt>pip</tt> executable <strong>from
this venv</strong>. This is the crucial point. Don't run this with any
<tt>pip</tt> executable you find, otherwise you won't be able to know where
the installation is taking place.</p>
<pre>~/my-venvs % venv1/bin/pip install ffgo
Downloading/unpacking ffgo
Downloading FFGo-1.9.0.tar.gz (767kB): 767kB downloaded
Running setup.py (path:/tmp/pip-build-phq2qtge/ffgo/setup.py) egg_info for package ffgo

[...]

Downloading/unpacking CondConfigParser (from ffgo)
Downloading CondConfigParser-1.0.2.tar.bz2 (46kB): 46kB downloaded
Running setup.py (path:/tmp/pip-build-phq2qtge/CondConfigParser/setup.py) egg_info for package CondConfigParser

[...]

Installing collected packages: ffgo, CondConfigParser
Running setup.py install for ffgo

[...]

Successfully installed ffgo CondConfigParser
Cleaning up...</pre>

<p>Run FFGo:</p>
<pre>~/my-venvs % venv1/bin/ffgo
FFGo 1.9.0 started
Using:
- Python 3.4.4
- CondConfigParser 1.0.2
- MagneticField: GeographicLib version 1.45

[FFGo warning] Pillow library not found. Aircraft thumbnails won't be
displayed.
[FFGo notice] GeographicLib's Python binding not found. FFGo has fallback
strategies, therefore you shouldn't see much of a difference. However, some
particular geodetic calculations can only be done with GeographicLib. You will
be notified when such a case is encountered.
Detected FlightGear version: 2016.1.0</pre>

<p>FFGo works. It just told us about the two optional dependencies we haven't
installed. Let's install them now. There is another way that uses Debian
packages (creating the venv with <tt>--system-site-packages</tt>); it is
explained in
[https://github.com/frougon/FFGo/blob/master/docs/INSTALL/INSTALL_en docs/INSTALL/INSTALL_en], but I can't replicate all of its contents
here...</p>

<p>OK, so let's install these optional dependencies now:</p>
<pre>~/my-venvs % venv1/bin/pip install Pillow geographiclib
Downloading/unpacking Pillow
Downloading Pillow-3.1.0.tar.gz (9.9MB): 9.9MB downloaded

[...]

Installing collected packages: Pillow, geographiclib
Running setup.py install for Pillow

warning: no previously-included files found matching '.editorconfig'
building 'PIL._imaging' extension

[...]

Cleaning up...</pre>

<p>Let's start FFGo again:</p>
<pre>~/my-venvs % venv1/bin/ffgo
FFGo 1.9.0 started
Using:
- Python 3.4.4
- CondConfigParser 1.0.2
- GeographicLib's Python binding 1.45
- MagneticField: GeographicLib version 1.45

Detected FlightGear version: 2016.1.0</pre>

<p>No warning anymore: all optional dependencies have been installed.</p>
</li></ul>
</li>
<li><p><em><strong>Second session:</strong> installing some of FFGo's
dependencies (such as
[http://frougon.net/projects/CondConfigParser/ CondConfigParser])
using <tt>pip</tt> in a virtual environment, while using FFGo directly from a
clone of its [https://github.com/frougon/FFGo Git repository].</em></p>

<p>Create a virtual environment (the second command is equivalent to
<code>/usr/bin/pyvenv-3.4 venv2</code> on Debian):</p>
<pre>~ % cd ~/my-venvs
~/my-venvs % /usr/bin/python3.4 -m venv venv2</pre>

<p>Install CondConfigParser in this venv using the <tt>pip</tt> executable
<strong>from this venv</strong>:</p>
<pre>~/my-venvs % venv2/bin/pip install CondConfigParser
Downloading/unpacking CondConfigParser
Downloading CondConfigParser-1.0.2.tar.bz2 (46kB): 46kB downloaded
Running setup.py (path:/tmp/pip-build-gdlz9yez/CondConfigParser/setup.py)

[...]

Successfully installed CondConfigParser
Cleaning up...</pre>

<p>Clone FFGo's Git repository:</p>
<pre>~ % mkdir -p ~/src && cd ~/src
~/src % git clone https://github.com/frougon/FFGo.git ffgo.git
Cloning into 'ffgo.git'...
remote: Counting objects: 3001, done.
remote: Total 3001 (delta 0), reused 0 (delta 0), pack-reused 3001
Receiving objects: 100% (3001/3001), 1.39 MiB | 940.00 KiB/s, done.
Resolving deltas: 100% (1927/1927), done.
Checking connectivity... done.</pre>

<p>This must be done whenever you work with FFGo's Git repo (unless you know
what you are doing), after <code>git clone</code> and every
<code>git pull</code> to have exisiting and up-to-date icons and translation
(<tt>.mo</tt>) files. This requires to have installed stuff as indicated in
the <i>Installation from the Git repository</i> section of FFGo's
[https://github.com/frougon/FFGo/blob/master/docs/INSTALL/INSTALL_en docs/INSTALL/INSTALL_en]
file.</p>
<pre>~/src % cd ffgo.git
~/src/ffgo.git % make
make -C share/icons
make[1]: Entering directory '/home/flo/src/ffgo.git/share/icons'

[...]

make[1]: Leaving directory '/home/flo/src/ffgo.git/ffgo/data/locale'</pre>

<p>Since FFGo was not installed with pip in this case, no <tt>ffgo</tt>
executable has been created. The recommended way to run FFGo in such a case is
via the <tt>ffgo-launcher.py</tt> script. The full path to
<tt>ffgo-launcher.py</tt> is not needed here since it is in the current
directory, however if you create an alias for this command, or if you
configure an icon in your menu bar/whatever to run it, you will need the path
(and maybe <tt>/home/username</tt> instead of <tt>~</tt> too). The path to the
Python interpreter (<tt>~/my-venvs/venv2/bin/python</tt>), however, is crucial
since it is for <em>this</em> Python interpreter that we have installed
CondConfigParser.</p>
<pre>~/src/ffgo.git % ~/my-venvs/venv2/bin/python ~/src/ffgo.git/ffgo-launcher.py
FFGo 1.9.0 started
Using:
- Python 3.4.4
- CondConfigParser 1.0.2
- MagneticField: GeographicLib version 1.45

[FFGo warning] Pillow library not found. Aircraft thumbnails won't be
displayed.
[FFGo notice] GeographicLib's Python binding not found. FFGo has fallback
strategies, therefore you shouldn't see much of a difference. However, some
particular geodetic calculations can only be done with GeographicLib. You will
be notified when such a case is encountered.
Detected FlightGear version: 2016.1.0</pre>

<p>Again, FFGo works fine and just warned us about the two optional
dependencies it couldn't find. They can be installed in exactly the same way
as above:</p>
<pre>~/src/ffgo.git % ~/my-venvs/venv2/bin/pip install Pillow geographiclib

[...]</pre>
</li></ol>

====== Updating the software ======

{{Note|None of the following should be run as root.}}

<ol style="list-style-type: decimal">
<li><p>First case: FFGo was installed in the virtual environment under
<tt>~/my-venvs/venv1</tt>.</p>

<p>Examine what is installed in <tt>~/my-venvs/venv1</tt>:</p>
<pre>% ~/my-venvs/venv1/bin/pip list
CondConfigParser (1.0.2)
FFGo (1.9.0)
geographiclib (1.45)
Pillow (3.1.0)
pip (1.5.6)
setuptools (18.8)</pre>

<p>Now, let's see what can be updated:</p>
<pre>% ~/my-venvs/venv1/bin/pip list --outdated
setuptools (Current: 18.8 Latest: 19.5)
pip (Current: 1.5.6 Latest: 8.0.2)</pre>

<p>Only <tt>setuptools</tt> and <tt>pip</tt> are out-of-date in this venv,
let's upgrade them:</p>
<pre>% ~/my-venvs/venv1/bin/pip install --upgrade setuptools pip
Downloading/unpacking setuptools from https://pypi.python.org/packages/3.5/s/setuptools/setuptools-19.5-py2.py3-none-any.whl#md5=c44407cb10f9b231f5a05908dea1a803
Downloading setuptools-19.5-py2.py3-none-any.whl (471kB): 471kB downloaded
Downloading/unpacking pip from https://pypi.python.org/packages/py2.py3/p/pip/pip-8.0.2-py2.py3-none-any.whl#md5=2056f553d5b593d3a970296f229c1b79
Downloading pip-8.0.2-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded

[...]

Successfully installed setuptools pip
Cleaning up...</pre>

</li>
<li><p>Second case: FFGo is used directly from a clone of its Git repository
by means of the
[https://github.com/frougon/FFGo/blob/master/ffgo-launcher.py ffgo-launcher.py]
script.</p>

<p>The procedure for updating the software that is installed in the venv is
the same as in the first case:</p>
<pre>% ~/my-venvs/venv2/bin/pip list --outdated
setuptools (Current: 18.8 Latest: 19.5)
pip (Current: 1.5.6 Latest: 8.0.2)</pre>

<p>Again, the same two packages need an update; all the others are at their
latest upstream stable version. Let's upgrade the two packages:</p>
<pre>% ~/my-venvs/venv2/bin/pip install --upgrade setuptools pip
Downloading/unpacking setuptools from https://pypi.python.org/packages/3.5/s/setuptools/setuptools-19.5-py2.py3-none-any.whl#md5=c44407cb10f9b231f5a05908dea1a803

[...]

Successfully installed setuptools pip
Cleaning up...</pre>

<p>FFGo was not installed via <tt>pip</tt> in the venv; we are using the Git
repo for FFGo. Let's update our clone of FFGo's Git repository:</p>
<pre>% cd ~/src/ffgo.git
~/src/ffgo.git % git pull

[...]</pre>

<p>Always run <tt>make</tt> after updating your clone of FFGo's Git
repository:</p>
<pre>~/src/ffgo.git % make
make -C share/icons
make[1]: Entering directory '/home/flo/src/ffgo.git/share/icons'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/flo/src/ffgo.git/share/icons'
make -C ffgo/data/pics
make[1]: Entering directory '/home/flo/src/ffgo.git/ffgo/data/pics'
make[1]: Nothing to be done for 'default'.
make[1]: Leaving directory '/home/flo/src/ffgo.git/ffgo/data/pics'
make -C ffgo/data/locale update-mo
make[1]: Entering directory '/home/flo/src/ffgo.git/ffgo/data/locale'
make[1]: Nothing to be done for 'update-mo'.
make[1]: Leaving directory '/home/flo/src/ffgo.git/ffgo/data/locale'
~/src/ffgo.git %</pre>

<p>Everything is now up-to-date.</p>
</li></ol>

In these instructions, we have updated each outdated package one by one.
<tt>pip</tt> in its current state doesn't allow updating all packages in a
virtual environment at once with a simple command
(cf. [https://github.com/pypa/pip/issues/59 pip issue #59]). However, with a
bit of plumbing, it is possible to write a script that does that: see
[http://forum.flightgear.org/viewtopic.php?f=18&t=27054&start=105#p274118 this message on the FlightGear forum]
for an example (the error handling may be imperfect, so watch the updates as
they are going if you use such a script).

====== Using development snapshots, release candidates, etc. ======

The instructions given above for <tt>pip</tt>-installed Python software only
upgrade to releases labelled as “stable” by their upstream maintainers.
Sometimes, you'll want to try a beta or development release of FFGo for
instance, especially if you didn't install it from the Git repository. To do
this, the method is the same as previously described, except that you have to
pass <code>pip install</code> the <tt>--pre</tt> option to indicate that you are
ready to install a version that is not necessarily labelled as “stable”.
Therefore, instead of upgrading FFGo with:

<pre><venv-dir>/bin/pip install --upgrade ffgo</pre>

you would use:

<pre><venv-dir>/bin/pip install --upgrade --pre ffgo</pre>

(development snapshots have version numbers such as 1.9.0.dev2, beta versions
like 1.9.0b1, etc. All this is explained in
[https://www.python.org/dev/peps/pep-0440/ PEP 0440] if you are interested)

====== Uninstalling the software ======

Let's assume you have a virtual environment based at directory <venv-dir> and
you want to uninstall two Python packages named ''pkg1'' and ''pkg2'' from
this virtual environment (one of these packages could be <tt>ffgo</tt>, for
instance). All you have to do is:

<pre><venv-dir>/bin/pip uninstall pkg1 pkg2</pre>

If you'd rather get rid of the whole virtual environment, just delete its base
directory <venv-dir>. That is all there is to it!

====== When the base Python installation is updated or removed ======

Let's say you built a virtual environment using a command such as:

<syntaxhighlight lang="shell" enclose="div">
/usr/bin/python3.4 -m venv <venv-dir>
</syntaxhighlight>

In such a case, your virtual environment located in <venv-dir> is somehow
linked to its <i>base Python installation</i>, the one providing
<tt>/usr/bin/python3.4</tt>. If you are on Debian for instance, this base
Python installation comes from the <tt>python3.4</tt> package. So, what happens
when this package is updated or removed?

<ul><li>
<p>My experience didn't show any particular problem so far when the package
for the venv's underlying base installation is updated. I suppose this will be
more or less always like that as long as updates are reasonable in terms of
backward-compatibility—which is normally the case when the Python major
version isn't changed (here: 3.4).</p>

<p>Note:</p>

<blockquote>
It is possible to pass the following option upon venv creation (i.e., after
something like <code>/usr/bin/python3.4 -m venv</code>):

<pre>--upgrade Upgrade the environment directory to use this version
of Python, assuming Python has been upgraded in-place.</pre>

(this can be found by running, e.g., <code>/usr/bin/python3.4 -m venv --help</code>)

Since venv creation using a script is extremely fast, I haven't felt any need
for this option so far, and thus have no experience to share regarding it.
</blockquote>
</li>

<li>
<p>However, when you upgrade your Linux/BSD/etc. distribution, it may happen
that for instance Python 3.4 is removed and replaced with Python 3.5. This is
not very frequent, but it does happen. In such a case, your virtual
environments built from <tt>/usr/bin/python3.4</tt> are quite likely not to
work anymore.</p>

<p>The cure for this kind of problem is not very difficult: just delete the
concerned virtual environments and recreate them using the new Python
interpreter of your choice (e.g., <tt>/usr/bin/python3.5</tt>). To facilitate
this, and also as a convenient means of remembering exactly which commands you
ran to create your virtual environment, I suggest to keep a short script
containing exactly the commands you used to create the venv. For instance:</p>

<syntaxhighlight lang="shell" enclose="div">
#! /bin/sh

set -e

target_dir="${1:-default-venv-dir}"
base_python="/usr/bin/python3.4"

if [ -e "$target_dir" ]; then
echo "!!Warning!! '$target_dir' already exists. If you continue, its"
echo " contents will be deleted. Press Enter to continue,"
echo " otherwise interrupt the script with Ctrl-C."
read dummy
fi

"$base_python" -m venv --clear "$target_dir"
"$target_dir"/bin/pip install --upgrade \
pip setuptools Pillow geographiclib FFGo
</syntaxhighlight>

<p>This script takes one optional argument: the base path where you want the
virtual environment to be created (represented by <venv-dir> above). As the
script is written, this argument defaults to <i>default-venv-dir</i> in the
current directory, but you can of course replace this with any path of your
choice.</p>

{{Note|This script installs FFGo inside the virtual environment. If you want to use FFGo from its Git repository instead, just replace <tt>FFGo</tt> with <tt>CondConfigParser</tt> in the last line of the script (since CondConfigParser is a mandatory dependency of FFGo).}}
</li>
</ul>

==== MacOS X ====

Installation should be similar to how it is done on Linux with ''pip'' in most ways, once you have installed a suitable Python version. OS X expert needed for the little OS X-specific details:
* how to install Python 3.4 or later in a non-intrusive way for the system;
* how to access the corresponding <tt>python</tt> executable, and;
* how to create a shortcut to the resulting ''ffgo'' executable for convenience.

=== A word about GeographicLib ===

[http://geographiclib.sourceforge.net/ GeographicLib] is a powerful C++ library that can perform many kinds of geographic calculations (such as finding the shortest “walkable” path between two points on Earth), and also provides information about Earth's magnetic field. This library has been written by researcher Charles F. F. Karney, who designed well-known algorithms to solve the geodetic direct and inverse problems.

Apart from the C++ library and accompanying programs such as [http://geographiclib.sourceforge.net/html/MagneticField.1.html MagneticField], Charles Karney provides a standalone Python 2 & 3 implementation of the geodetic algorithms. This Python implementation is what you get when running commands such as (depending on your setup):

<syntaxhighlight lang="shell" enclose="div">
pip install geographiclib
</syntaxhighlight>

or:

<syntaxhighlight lang="shell" enclose="div">
<venv-dir>/bin/pip install geographiclib
</syntaxhighlight>

It is ''not'' a binding for the C++ library; rather, it is a ''reimplementation'' in Python of ''some'' of the algorithms featured by the GeographicLib C++ library.

FFGo uses the following software components if it can find them:
* GeographicLib's implementation for Python 3;
* GeographicLib's MagneticField program.

The former is normally obtained via pip, while the latter comes with the “full GeographicLib package” as published on [http://geographiclib.sourceforge.net/ GeographicLib's home page].

== Related content ==
* [http://frougon.net/projects/FFGo/ FFGo's home page]
* [http://frougon.net/projects/FFGo/doc/README-conditional-config/ FFGo conditional config documentation]
* [http://forum.flightgear.org/viewtopic.php?f=18&t=27054 FFGo's thread on the FlightGear forum]
* [[FGo!]] — ''predecessor to FFGo''
* [[FlightGear Launch Control]] (a.k.a. FGRun) — ''default graphical frontend''
* [[Integrated_Qt5_Launcher|FlightGear's integrated Qt5-based launcher]]
* [[FGX|FGx]]

== Footnotes ==
<references/>

[[Category:FlightGear front ends]]

Talk:FFGo

2016-10-11T02:35:50Z

Chris blues: Add note about --no-install-recommends for debian?

FlightGear Newsletter September 2016

2016-10-01T15:35:45Z

Chris blues:

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[Latest newsletter]].}}

{{Newsletter-header|September 2016}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>

[[#Poll for the next default airport|Poll for the next default airport]]<br>
{{Newsletter-cover-header|In the hangar}}<br>
[[#Burrito F1| Burrito F1]]
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

=== Poll for the next default airport ===
Once again, after 2016.3 'Rio de Janeiro' has been released, we're looking for the next default airport. If you're quick, until October 4th you can submit your [https://forum.flightgear.org/viewtopic.php?f=42&t=30541 vote to the poll] in the forums.

== In the hangar ==
=== Burrito F1 ===
Bulldog RS has just released [[Burrito F1]], a fictional flying car. It is available from [https://bulldogrs.wordpress.com/ official website].
[[File:Burrito_F1.jpg|600px|Burrito F1]]

== Scenery corner ==
*Buildings and structures in Rio de Janeiro by Catalanoic availible via TerraSync.

== Community news ==
* The FlightGear Team will be attending the [http://www.fsweekend.com/ FSweekend], from november 5th to 6th at Lelystad Airport, the Netherlands. Early preparations are currently being made. Most likely we will demonstrate a multi-pc (multiplayer/solo) ATC-environment around Rio de Janeiro. Aircraft currently in our scope are the new/updated MD-11, 757, Seneca II. If you have any additional ideas, let us know on [https://forum.flightgear.org/viewtopic.php?f=42&t=30260/ the Forums]. If you are planning to attend, sign up for the [https://www.facebook.com/events/1112269228887897/ Facebook-event]!

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [https://forum.flightgear.org/viewtopic.php?f=19&t=30364 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=30364#p293984 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page.

 

 

[[Category:FlightGear Newsletter|2016 09]]
[[Category:Changes after 2016.3]]

[[de:FlightGear Newsletter September 2016]]

FlightGear Newsletter September 2016

2016-10-01T15:35:22Z

Chris blues:

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[Latest newsletter]].}}

{{Newsletter-header|September 2016}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>

[[#Poll for the next default airport|Poll for the next default airport]]
{{Newsletter-cover-header|In the hangar}}<br>
[[#Burrito F1| Burrito F1]]
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

=== Poll for the next default airport ===
Once again, after 2016.3 'Rio de Janeiro' has been released, we're looking for the next default airport. If you're quick, until October 4th you can submit your [https://forum.flightgear.org/viewtopic.php?f=42&t=30541 vote to the poll] in the forums.

== In the hangar ==
=== Burrito F1 ===
Bulldog RS has just released [[Burrito F1]], a fictional flying car. It is available from [https://bulldogrs.wordpress.com/ official website].
[[File:Burrito_F1.jpg|600px|Burrito F1]]

== Scenery corner ==
*Buildings and structures in Rio de Janeiro by Catalanoic availible via TerraSync.

== Community news ==
* The FlightGear Team will be attending the [http://www.fsweekend.com/ FSweekend], from november 5th to 6th at Lelystad Airport, the Netherlands. Early preparations are currently being made. Most likely we will demonstrate a multi-pc (multiplayer/solo) ATC-environment around Rio de Janeiro. Aircraft currently in our scope are the new/updated MD-11, 757, Seneca II. If you have any additional ideas, let us know on [https://forum.flightgear.org/viewtopic.php?f=42&t=30260/ the Forums]. If you are planning to attend, sign up for the [https://www.facebook.com/events/1112269228887897/ Facebook-event]!

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [https://forum.flightgear.org/viewtopic.php?f=19&t=30364 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=30364#p293984 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page.

 

 

[[Category:FlightGear Newsletter|2016 09]]
[[Category:Changes after 2016.3]]

[[de:FlightGear Newsletter September 2016]]

FlightGear Newsletter September 2016

2016-10-01T15:33:46Z

Chris blues: /* Development news */ Add poll for next default airport

{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[Latest newsletter]].}}

{{Newsletter-header|September 2016}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Development news}}<br>

{{Newsletter-cover-header|In the hangar}}<br>
[[#Burrito F1| Burrito F1]]
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery Corner}}<br>
{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Contributing}}<br>
[[#Translators required|Translators required]]<br>
[[#FlightGear logos|FlightGear logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small>
|}</div>

== Development news ==

===Poll for the next default airport===
Once again, after 2016.3 'Rio de Janeiro' has been released, we're looking for the next default airport. If you're quick, until October 4th you can submit your [https://forum.flightgear.org/viewtopic.php?f=42&t=30541 vote to the poll] in the forums.

== In the hangar ==
=== Burrito F1 ===
Bulldog RS has just released [[Burrito F1]], a fictional flying car. It is available from [https://bulldogrs.wordpress.com/ official website].
[[File:Burrito_F1.jpg|600px|Burrito F1]]

== Scenery corner ==
*Buildings and structures in Rio de Janeiro by Catalanoic availible via TerraSync.

== Community news ==
* The FlightGear Team will be attending the [http://www.fsweekend.com/ FSweekend], from november 5th to 6th at Lelystad Airport, the Netherlands. Early preparations are currently being made. Most likely we will demonstrate a multi-pc (multiplayer/solo) ATC-environment around Rio de Janeiro. Aircraft currently in our scope are the new/updated MD-11, 757, Seneca II. If you have any additional ideas, let us know on [https://forum.flightgear.org/viewtopic.php?f=42&t=30260/ the Forums]. If you are planning to attend, sign up for the [https://www.facebook.com/events/1112269228887897/ Facebook-event]!

== Contributing ==
=== Translators required ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====
Entries for this month's best screenshot can be submitted to [https://forum.flightgear.org/viewtopic.php?f=19&t=30364 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=30364#p293984 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented on this page.

 

 

[[Category:FlightGear Newsletter|2016 09]]
[[Category:Changes after 2016.3]]

[[de:FlightGear Newsletter September 2016]]

Earthview

2016-07-27T21:57:17Z

Chris blues: /* Customization */

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{note|You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files here:

* 1024x1024 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_1k.7z world] (7.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_1k.7z clouds] (5.2MB)

* 2048x2048 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_2k.7z world] (27.3MB) - [https://musicchris.de/download/FG/EarthView/clouds_2k.7z clouds] (18.9MB)

* 4096x4096 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_4k.7z world] (99.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_4k.7z clouds] (64.4MB)

* 8192x8192 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_8k.7z world] (361.6MB) - [https://musicchris.de/download/FG/EarthView/clouds_8k.7z clouds] (212.8MB)

* 16384x16384 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_16k_dds.7z world] dds (~310MB) - [https://musicchris.de/download/FG/EarthView/world_16k_png.7z world] png (~1GB) (Warning: Requires much more than 1GB Graphics RAM - FG crashes on my machine with 1GB GRAM)

Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).<br />
Alternatively, you can download the complete set of textures here (this server is much faster!)

https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.001 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.002 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.003 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.004 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.005 (200MB)<br />

In a bash, you could get it all with the following one-liner:
<syntaxhighlight lang="bash">for p in 1 2 3 4 5 ; do wget https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.00$p -c -O raw-data-NASA.7z ; done</syntaxhighlight>

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.

Earthview

2016-07-27T19:31:44Z

Chris blues: /* Customization */

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{note|You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files here:

* 1024x1024 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_1k.7z world] (7.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_1k.7z clouds] (5.2MB)

* 2048x2048 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_2k.7z world] (27.3MB) - [https://musicchris.de/download/FG/EarthView/clouds_2k.7z clouds] (18.9MB)

* 4096x4096 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_4k.7z world] (99.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_4k.7z clouds] (64.4MB)

* 8192x8192 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_8k.7z world] (361.6MB) - [https://musicchris.de/download/FG/EarthView/clouds_8k.7z clouds] (212.8MB)

* 16384x16384 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_16k_dds.7z world] dds (~310MB) - [https://musicchris.de/download/FG/EarthView/world_16k_png.7z world] png (~1GB) (Warning: Requires much more than 1GB Graphics RAM - FG crashes on my machine with 1GB GRAM)

Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).<br />
Alternatively, you can download the complete set of textures here (this server is much faster!)
{{note| The following files will be done uploading at 2016-07-27 21:00 UTC. Feel free to remove this note afterwards.}}
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.001 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.002 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.003 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.004 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.005 (200MB)<br />

In a bash, you could get it all with the following one-liner:
<syntaxhighlight lang="bash">for p in 1 2 3 4 5 ; do wget https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.00$p -c -O raw-data-NASA.7z ; done</syntaxhighlight>

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.

Earthview

2016-07-27T14:29:34Z

Chris blues: /* Customization */ Add note about the amount of textures

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
=== Overview ===
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview.jpg|thumb|Earthview configuration dialog]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed in FGData as the highest resolution set has eight textures sheets of 172 MB each which would double the current repository size. It is however easily possible to obtain the textures from the NASA website and apply them.

At highest texture resolution, visuals are generally very compelling:

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory (this is not an issue for the default texture size). Provided there is sufficient texture memory available, loading the texture sheets is another bottleneck and FG may hang for a couple of seconds while the textures appear.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format.

While it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues.

== Customization ==

Getting your own hires version of textures requires a few simple steps:

{{note|You can skip the next 2 steps ("obtain a texture set" and "convert the texture set") and download the ready-to-use files here:

* 1024x1024 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_1k.7z world] (7.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_1k.7z clouds] (5.2MB)

* 2048x2048 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_2k.7z world] (27.3MB) - [https://musicchris.de/download/FG/EarthView/clouds_2k.7z clouds] (18.9MB)

* 4096x4096 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_4k.7z world] (99.5MB) - [https://musicchris.de/download/FG/EarthView/clouds_4k.7z clouds] (64.4MB)

* 8192x8192 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_8k.7z world] (361.6MB) - [https://musicchris.de/download/FG/EarthView/clouds_8k.7z clouds] (212.8MB)

* 16384x16384 7z-zipped: [https://musicchris.de/download/FG/EarthView/world_16k_dds.7z world] dds (~310MB) - [https://musicchris.de/download/FG/EarthView/world_16k_png.7z world] png (~1GB) (Warning: Requires much more than 1GB Graphics RAM - FG crashes on my machine with 1GB GRAM)

Or you could get yourself this Bash-script to let it do the generation for you: https://github.com/chris-blues/Nasa2FGearthview}}

* obtain a texture set
Go to [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and download a texture set of your choice (there's different seasons available for instance).<br />
Alternatively, you can download the complete set of textures here (this server is much faster!)
{{note| The following files will be done uploading at 2016-07-27 20:00 UTC. Feel free to remove this note afterwards.}}
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.001 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.002 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.003 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.004 (500MB)<br />
https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.005 (200MB)<br />

In a bash, you could get it all with the following one-liner:
<syntaxhighlight lang="bash">for p in 1 2 3 4 5 ; do wget https://musicchris.de/download/FG/EarthView/raw-data-NASA.7z.00$p -c -O raw-data-NASA.7z ; done</syntaxhighlight>

NASA typically delivers the hires textures with naming conventions N1 - N4 (northern hemisphere) and S1 - S4 (southern hemisphere) and Earthview follows that convention.

* convert the texture set

Graphics cards prefer powers of two in texture sizes, so you probably want to resize the sheets to either 8192x8192 or 16384x16384. At the same time, you might want to save them in pre-compressed and mip-mapped dds format (this may require a gimp plugin) for better loading times. Do this on a machine with plenty of memory, as the graphics program may need a lot in intermediate stages.

* assign the texture sheets

Look into $FGData/Models/Astro - this is where Earthview resides. The current texture sheets are pale_blue_aug_??.png and clouds_??.png where ?? stands for the NASA position reference.

The simple way is to assign your texture to earth_unitscale_rawuv.ac (then they can be used 'as is'). It's easiest to open the file with the text editor, look for the lines like
<b>texture "pale_blue_aug_N1.png"</b>
and replace them with your own N1 texture. Then open earth.xml and point to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. Do the same for cloudsphere.xml (it's entirely possible to do all this in a 3d modeling application like blender, but chances are it will get rather slow and unwieldy for such huge texture sheets).

Assigning textures as they are to the rawuv sphere creates visible seams where the texture sheets end. The solution is to add margins (like done for the texture set provided). If you edit your textures to add such margins, you don't need to use <b>earth_unitscale_rawuv.ac</b> and can assign your textures to <b>earth_unitscale_hires.ac</b> (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the details of creating such textures)

For comparison, a 16384x16384 texture sheet in pre-compressed and mip-mapped dds format should come to 341 MB. Unless you have a substantial amount of memory, consider using less than full resolution, since you always need 4 of these textures loaded into graphics memory, and 8 if you also switch on clouds.

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Development ==

Earthview in its current state isn't perfect, for instance in low light it may produce mismatches with the atmosphere shader (as it's fogging model is not precisely the same, and the numerics of the projected Earth sphere doesn't always match what the atmosphere shader computes as horizon). For that reason, its visuals are developed further, but the priority is in general low as by and large the goal to have viable spaceflight visuals is met.

Over the years, there have been diverse proposals for alternative ways to render orbital visuals in a way that is more integrated with FG - the only viable alternative that has actually materialized so far seems to be [[Building FlightGear with osgEarth Integration]], however this lacks atmosphere visuals.