FlightGear wiki - User contributions [en]

GSoC: Candidate Projects

2011-02-21T15:54:47Z

Ac001: /* FlightGear Launch Control (fgrun) */

TODO: copy/paste feature requests and mini projects from other wiki pages that might make for good candidate projects, for a possible application/participation. Update this page to show that we will be applying for participation in '''2011'''

Feel free to propose completely new projects, you can also create a new wiki page if you want to.

Keep in mind that proposed projects should be "do-able" within a 3 month time frame by a student who may not know anything about FlightGear (but it's safe to assume they know how to program).

= Related Wiki Pages =
* [[Google Summer of Code 2011]]
* [[Google_Summer_of_Code_Mentors]]
* [[Google_Summer_of_Code_Student_Applications]]

Wiki pages containing possible inspirations for candidate projects:
* [[Feature Requests / Proposals / Ideas]]
* [[FGFS Todo]]
* [[Bugs]]

= FlightGear Candidate Projects =

TODO: put here suitable ideas for projects

* [[Implement Shadows for FlightGear]]
* [[Implement OSGOcean for FlightGear]] (see forum discussions)

== [[FlightGear Scenery]] ==

* [[AutoGen Scenery for FlightGear]]
* Add support for apt.dat 8.50 format into FG scenery.
** This would mean considerable changes to both Terragear and the FG btg parser.

== [[FlightGear Multiplayer Server]] ==

* reduce bandwidth used by not relaying information to server "N" about aircraft that are not visible to any fliers on server "N"
** Already implemented, but there are other possible bandwidth saving improvements that could be tried.
* reduce bandwidth used by not sending all active MP enabled properties in every packet.

== [[FlightGear Launch Control (fgrun)]] ==

* offer (via checkbox option) automatic selection of nearest MP server based on geographic location (by IP address), lowest lag (ping time) or least server load (which of these is the better metric may need research)

* place commonly used (or as added by user) command line options as individual items in a listbox with a checkbox or radio button for each such that they can be easily found and turned on/off individually and their values easily changed.

== [[FlightGear Cockpit]] ==
* create arduino interfaces and view modes and self design in settings

== [[FlightGea.AutoPilot]]
the pis is a problem cos it all defined everwhere.
The Mission:
To take a series of "stable" aircraft of various types
and analyse the pid and problems

* create arduino interfaces and view modes and self design in settings

== FlightGear [[JSBsim]] ==

== FlightGear [[YASim]] ==

* improve interaction of aircraft with the ground. Helicopters tend to rotate (rotor torque?) and/or slide around when on the ground.

{{Stub}}
[[Category:GSoC]]

Howto:Shader programming in FlightGear

2010-12-05T01:55:37Z

Ac001: olde cvs to git link

{{Stub}}

This is meant to become an introduction to shader programming in FlightGear, for the time being (03/2010), this is work in progress, please feel free to ask questions or suggest topics.

Your help in improving and updating this article is appreciated, thanks!

Tutorials about GLSL Programming in general are collected at [[GLSL Shader Programming Resources]]

For an OpenGL quick reference, please see: http://www.khronos.org/files/opengl-quick-reference-card.pdf for an GLSL quick reference see [http://www-evasion.imag.fr/Membres/Sebastien.Barbier/Enseignement/glsl_quickref.pdf glsl_quickref.pdf]

= Intro =
GLSL (OpenGL Shading Language or "GLslang") is the official OpenGL shading language and allows you to write programs, so called "shaders" in a high level shading language that is based on the C programming language to create OpenGL fragment (pixel) and vertex shaders.

With the recent advances in graphics cards, new features have been added to allow for increased flexibility in the rendering pipeline at the vertex and fragment level. Programmability at this level is achieved with the use of fragment and vertex shaders.

GLSL was created to give developers more direct control of the graphics pipeline without having to use assembly language or hardware-specific languages. Shaders provide the possibility to process individual vertices or fragments individually, so that complex rendering tasks can be accomplished without stressing the CPU. Support for shader was first introduced via extensions in OpenGL 1.5, but is now part of the core OpenGL 2.0 standard.

Shaders are written and stored as plain text files, which can be uploaded (as strings) and executed on the GPU (processor of the graphics card).

= What is a Shader =
A shader is a programmable replacement for parts of the fixed OpenGL function pipeline, you can imagine it sort of like a "plugin" to customize rendering for specific scene elements.

GLSL shaders are not stand-alone applications; they require an application that utilizes the OpenGL API.
A shader is a program, to be run it must be loaded, compiled and linked.
Shaders will be compiled when the 3D application starts. They will be validated and optimized for the current hardware.

Actually each vertex and fragment shader must have one entry point (the main function) each, but you can create and link more shaders.

GLSL shaders themselves are simply a set of strings that are passed to the hardware vendor’s driver for compilation from within an application using the OpenGL API's entry points. Shaders can be created on the fly from within an application or read in as text files, but must be sent to the driver in the form of a string.

GLSL has explicit ties to the OpenGL API - to the extent that much of the OpenGL 'state' (eg which light sources are bound, what material properties are currently set up) is presented as pre-defined global variables in GLSL.

Shaders offer:
* Opportunity for Improved Visual Quality
* Algorithm Flexibility
* Performance Benefits

Shaders have access to the render state (parameters, matrices, lights, materials ...) and textures.
A "pass" is the rendering of a 3D Model with a vertex and pixel shader pair.
An effect can require multiple passes, while each pass can use a different shader and/or model pair.
A Pass can render to a texture (to be used by another pass). Think of the "fixed functionality" as the default Shader.

To make it simple, a shader is a program that is loaded on the GPU and called for every vertex or pixel: this gives programmers the possibility to implement techniques and visual effects and execute them faster. In modern games or simulators lots of shaders are used: lights, water, skinning, reflections and much more.

We can create as many shader programs as needed (you can have many shaders of the same type (vertex or fragment) attached to the same program, but only one of them can define the entrypoint:the main() function).

Each Shader program is assigned an handler, and you can have as many programs linked and ready to use as you want (and your hardware allows).
Once rendering, we can switch from program to program, and even go back to fixed functionality during a single frame.

To really understand shaders, you should have a knowledge about the rendering pipeline; this helps to understand where and when the shaders act in the rendering process. In general, you must know that vertex are collected, processed by vertex shaders, primitives are built, then are applied colors, textures and are also called fragment shaders; finally it comes to the rasterization and the frame is put on the buffer.

Some benefits of using GLSL are:
* Cross platform compatibility on multiple operating systems, including Linux, Mac OS and Windows.
* The ability to write shaders that can be used on any hardware vendor’s graphics card that supports the OpenGL Shading Language.
* Each hardware vendor includes the GLSL compiler in their driver, thus allowing each vendor to create code optimized for their particular graphics card’s architecture.

= Language Features =

While GLSL has a C-Like syntax, it introduces some new types and keywords. To get a detailed view of the language, please see the GLSL specification you can find on http://www.opengl.org/documentation/glsl/

The OpenGL Shading Language provides many operators familiar to those with a background in using the C programming language. This gives shader developers flexibility when writing shaders. GLSL contains the operators in C and C++, with the exception of pointers. Bitwise operators were added in version 1.30.

Similar to the C programming language, GLSL supports loops and branching, including if, else, if/else, for, do-while, break, continue, etc.

User defined functions are supported, and a wide variety of commonly used functions are provided built-in as well. This allows the graphics card manufacturer the ability to optimize these built-in functions at the hardware level if they are inclined to do so. Many of these functions are similar to those found in the math library of the C programming language such as exp() and abs() while others are specific to graphics programming such as smoothstep() and texture2D().

= Shader Types =

There are two types of shaders in GLSL: "vertex shaders" and "fragment shaders" (with geometry shaders being a part of OpenGL 3.2).

These are executed by vertex and fragment processors in the graphics hardware.

* Vertex shaders transform vertices, set up data for fragment shaders
* Fragment shaders operate on fragments generated by rasterization
* Geometry shaders create geometry on the GPU

Typically, vertex shader files use the file extension ".vert", while fragment shader files use the ".frag" extension.
In FlightGear, these files can be found in the "Shaders" subdirectory of the base package, i.e. $FG_ROOT/Shaders

For a list of currently available shaders, you may want to take a look at: http://gitorious.org/fg/fgdata/trees/master/Shaders

So, shaders generally go around in pairs - one shader (the "Vertex shader") is a short program that takes in one vertex from the main CPU and produces one vertex that is passed on to the GPU rasterizer which uses the vertices to create triangles - which it then chops up into individual pixel-sized fragments.

A vertex shader is run once per vertex, while a fragment shader is run once per pixel.
Many such executions can happen in parallel. There is no communication or ordering between
executions. Vertex shaders are flexible and quick.

== Vertex Shaders ==
Input: Vertex attributes

Output: At least vertex position (in the clip space)

Restrictions: Cannot access any vertex other than the current one

Note: Loading a vertex shader turns off parts of the OpenGL pipeline (vertex shaders fully replace the "Texturing & Lighting unit")

Objects in a computer graphics scene are usually meshes that are made up of polygons. The corner of each of those polygons is called a "vertex".
A vertex shader receives input in the form of per-vertex variables called "attribute variables", and per-polygon variables called "uniform variables".
The vertex shader must specify the coordinates of the vertex in question. This way, the geometry of the object can be modified.

Vertex shaders operate on each vertex, the vertex shader is executed for every vertex related OpenGL call (e.g. glVertex* or glDrawArrays).
Accordingly, this means for example, that for meshes that contain e.g. 5000 vertices, the vertex shader will also be executed 5000 times.

A single vertex itself is composed of a number of "attributes" (vertex attrib), such as: position, texture coordinates, normal and color for the most common.
The position (attribute) is the most important one. The coordinates (x, y and z) of the vertex's entering position are those which have been given by the 3D modeler during the creation of the 3D model. The vertex's position is defined in the local space of the mesh (or object space).

A vertex shader provides almost full control over what is happening with each vertex. Consequently, all per-vertex operations of the fixed function OpenGL pipeline are replaced by the custom vertex shader.

Vertex Shaders take application geometry and per-vertex attributes as input and transform the input data in some meaningful way.

* A vertex shader MUST write to gl_Position
* A vertex shader CAN write to gl_PointSize, gl_ClipVertex
* gl_Vertex is an attribute supplying the untransformed vertex coordinate
* gl_Position is an special output variable for the transformed vertex coordinate

A vertex shader can also set other variables which are called "varying variables".
The values of these variables are passed on to the second kind of shader, the "fragment shader".
The fragment shader is run for every pixel on the screen where the polygons of the mesh appear.The fragment shader is responsible for setting the final color of that little piece of the mesh

Common tasks for a vertex shader include:

* Vertex position transformation
* Per vertex lighting
* Normal transformation
* Texture coordinates transformation or generation
* Vertex color computation
* Geometry skinning
* Animation
* Setting up data for fragment shaders

The vertex shader runs from start to end for each and every vertex that's passed into the graphics card - the fragment process does the same thing at the pixel level. In most scenes there are a heck of a lot more pixel fragments than there are vertices - so the performance of the fragment shader is vastly more important and any work we can do in the vertex shader, we probably should.

A minum vertex shader example may looks this:

void main(void)
{
gl_Position = ftransform();
}

== Fragment Shaders ==
Input: Interpolation of the vertex shader outputs

Output:Usually a fragment color.

Restrictions: Fragment shaders have no knowledge of neighboring pixels.

Note: Loading a fragment shader turns off parts of the OpenGL pipeline (pixel shaders fully replace the "Texturing Unit")

The other shader (the "Fragment shader" - also known (incorrectly) as the "pixel shader") takes one pixel from the rasterizer and generates one pixel to write or blend into the frame buffer.

A fragment shader can write to the following special output variables:
* gl_FragColor to set the color of the fragment
* gl_FragData[n] to output to a specific render target
* gl_FragDepth to set the fragment depth

Common tasks of fragment shaders include:
* Texturing (even procedural)
* Per pixel lighting and material application
* ray tracing
* Fragment color computation
* Operations on Interpolated Values
* Doing operations per fragment to make pretty pictures

A minimum fragment shader may look like this:

void main(void)
{
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}

A fragment shader takes perspective-correct interpolated attribute values as input and either discards the fragment or outputs the fragment's color.

Fragment shaders operate on every fragment which is produced by rasterization. Fragment shaders give you nearly full control over what is happening with each fragment. However just like vertex shaders, a fragment shader replaces all per-fragment operations of the fixed function OpenGL pipeline.

= Data Types in GLSL =
Note that there is no implicit type conversion in GLSL, all conversions and initializations have to be done using explicit constructor calls!

== Scalars ==
* float - 32 bit, very nearly IEEE-754 compatible
* int - at least 16 bit, but not backed by a fixed-width register
* bool - like C++, but must be explicitly used for all flow control

== Vectors ==
* vec2, vec3, vec4 2D, 3D and 4D floating point vector
* ivec2, ivec3, ivec4 2D, 3D and 4D integer vector
* bvec2, bvec3, bvec4 2D, 3D and 4D boolean vectors

Accessing a vector can be done using letters as well as standard C selectors.

TODO: explain swizzling

One can use the letters x,y,z,w to access vectors components; r,g,b,a for color components; and
s,t,p,q for texture coordinates.

== Matrices ==
* mat2 2x2 floating point matrix
* mat3 3x3 floating point matrix
* mat4 4x4 floating potint matrix

== Samplers ==
In GLSL, textures are represented and accessed using so called "samplers", which are used for sampling textures and which have to be uniform. The following samplers are available:

* sampler1D, sampler2D, sampler3D 1D, 2D and 3D texture
* samplerCube Cube Map texture
* sampler1Dshadow, sampler2Dshadow 1D and 2D depth-component texture

== Arrays ==
GLSL supports the same syntax for creating arrays that is already known from C or C++, e.g.:

vec2 foo[10];

So, arrays can be declared using the same syntax as in C, but can't be initialized when declared. Accessing array's elements is done as in C.

== Structures ==
Structures can also be created like in C or C++, e.g.:

struct foo {
vec3 pos;
};

= Global Storage Qualifiers =
Used for communication between shaders and application:

* const - for declaring non-writable, compile-time constant variables
* attribute - For frequently changing (per vertex) information passed from the application to a vertex shader (no integers, bools, structs, or arrays)
* uniform - for infrequently changing (per primitive) information passed from the application to a vertex or fragment shader:constant shader parameters that can be changed between draws (cannot be written to in a shader, do not change per-vertex or per-fragment)
* varying - for information passed from a vertex shader to a fragment shader, will be interpolated in a perspective-correct manner during rasterization (can write in vertex shader, but only read in fragment shader)

= Functions =
* Much like C++
* Entry point into a shader is void main()
* Overloading based on parameter type (but not return type)
* No support for direct or indirect recursion
* Call by value-return calling convention

As in C, a shader is structured in functions. At least each type of shader must have a main function declared with the following syntax: void main()
User defined functions may be defined. As in C a function may have a return value, and use the return statement to pass out its result. A function can be void. The return type can have any type, except array.

== Parameter Qualifiers ==
The parameters of a function may have the following qualifiers:
* in - copy in, but don't copy back out (still writable within function)
* out - only copy out; undefined at function entry point
* inout - copy in and copy out

If no qualifier is specified, by default it is considered to be in.

= Built-ins =
== Vertex Shader ==

* vec4 gl_Position; must be written
* vec4 gl_ClipPosition; may be written
* float gl_PointSize; may be written

== Fragment Shader ==
* float gl_FragColor; may be written
* float gl_FragDepth; may be read/written
* vec4 gl_FragCoord; may be read
* bool gl_FrontFacing; may be read

== Vertex Attributes ==
Only available in vertex shaders.

* attribute vec4 gl_Vertex;
* attribute vec3 gl_Normal;
* attribute vec4 gl_Color;
* attribute vec4 gl_SecondaryColor;
* attribute vec4 gl_MultiTexCoordn;
* attribute float gl_FogCoord;

== Uniforms ==
* uniform mat4 gl_ModelViewMatrix;
* uniform mat4 gl_ProjectionMatrix;
* uniform mat4 gl_ModelViewProjectionMatrix;
* uniform mat3 gl_NormalMatrix;
* uniform mat4 gl_TextureMatrix[n];

struct gl_MaterialParameters {
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};

* uniform gl_MaterialParameters gl_FrontMaterial;
* uniform gl_MaterialParameters gl_BackMaterial;

struct gl_LightSourceParameters {
vec4 ambient;
vec4 diffuse;
vec4 specular;
vec4 position;
vec4 halfVector;
vec3 spotDirection;
float spotExponent;
float spotCutoff;
float spotCosCutoff;
float constantAttenuation
float linearAttenuation
float quadraticAttenuation
};
* Uniform gl_LightSourceParameters gl_LightSource[gl_MaxLights];

== Varyings ==
An interface between vertex and fragment shaders is provided by varying variables: vertex shaders compute values per vertex and fragment shaders compute values per fragment.
The value of a varying variable defined in a vertex shader, will be interpolated (perspective-correct) over the primitve being rendered and the interpolated value in the fragment shader can be accessed.

Varying variables can only be used with the data types float, vec2, vec3, vec4, mat2, mat3, mat4. (and arrays of them too.)

* varying vec4 gl_FrontColor // vertex
* varying vec4 gl_BackColor; // vertex
* varying vec4 gl_FrontSecColor; // vertex
* varying vec4 gl_BackSecColor; // vertex
* varying vec4 gl_Color; // fragment
* varying vec4 gl_SecondaryColor; // fragment
* varying vec4 gl_TexCoord[]; // both
* varying float gl_FogFragCoord; // both

== Functions ==

= Anatomy of a Shader =
A shader's entry point is the main function which returns void and takes no arguments (void)

== Anatomy of a Vertex Shader ==
The function 'void main()' is called afresh for each vertex in the 3D object model:

// Vertex Shader
void main() {
gl_Position = gl_Vertex;
}

== Anatomy of a Fragment Shader ==
The function 'void main()' is called afresh for each fragment/pixel in the 3D object model:

// Fragment Shader
void main() {
gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);
}

[[Category:Howto|Shader Programming in FlightGear]]

User talk:MILSTD

2010-06-22T01:18:43Z

Ac001: MILSTD = the main knowlege base..

hi MILSTD..
I've created a new project
http://code.google.com/p/flightgear-future/

The idea in my mind is to create a "proposal list" for the future., ie not bugs//

I only realise this a few days ago, and indeed would be a cool environment. I think inbetween developers and pilots. kids etc..

I wish to make you the admin/editors etc of that, so we can get a grip of the future.

Pete [ac001]

-------------------------------------------------
SORRY, I apologise

pete

http://www2.navigraph.com/www/news.asp
#

Hi there.

CAN you PELASE REFRAIN from making changes to stuff you do not understand or know about.

Its rather silly and stupid that you keep adding "stuff", which generally does have little relevance to the content..

And IDIOT example is the recent change to the GIT page.

If you actually looked and RTFM, let alone actually USE it, then git is a disributed SCM whereas CVS DEFINATELY IS NOT.

Seems strange that you want to make changes that are irelevant..

:: ac001, without pointing out the obvious: What exactly are you referring to at all (which edits)? I'd be surprised if I should have added anything wrong about git or CVS, having used both systems for a number of years now both privately and professionally, and being quite familiar with their differences, having used CVS for over 10 years now and having in fact contributed to git in the past. I don't think I wrote anywhere that CVS is a distributed SCM (because it clearly is not), if I really did (and you can point me to the corresponding change in the edit history), it was most certainly a typo or a whole number of words missing. So, I would really appreciate it if you could point me to those of my edits that you are referring to, which are in your opinion "idiotic", "silly", "stupid" or just "irrelevant stuff" where I missed to "RTFM". Thank you in advance for actually following up your claims with hard facts. If I did mess up anything somewhere, please do feel free to revert my edits or point me to the corresponding pages, so that I can undo my changes myself, I apologize if that should have really been the case in some of my edits, but given the plethora of edits I have done here, it is of course very well possible that I added inaccurate contents, especially because these are often based on previous discussions which are copy/paste-converted to the wiki format for documentation purposes. However, please also be advised that it is usually easier to get along with people by keeping your tone civilized, it is just not helpful or constructive to yell around if you want to achieve something, even when you are right (but especially not when you are wrong). Thanks for your comments however!--[[User:MILSTD|MILSTD]] 14:16, 25 May 2010 (UTC)
::: Edit, I just took a look at the article that you mentioned, if you take a careful look for yourself, you'll probably see that the offending edit was not done by me: http://wiki.flightgear.org/index.php?title=FlightGear_and_Git&diff=21597&oldid=21533 Can you point me to any other of my edits that you disagree with?--[[User:MILSTD|MILSTD]] 14:21, 25 May 2010 (UTC)

Hi Milstd, hope we can be friends please.. and I apologise..

I am working on some tutorials as an Idea.. maybe even "Flight College"...

Your feedback, suggestions, corrects etc would appreaciated

Its in my sandbox here
[[http://wiki.flightgear.org/index.php/User:Ac001/Tutorial_Overview]]

Pete 'ac001'

== Show preview ==

Hi Milstd,

You're very active on the wiki since some time. It's really good if you add things, but whould you please first look if the page is good (Show preview) before saving it? I saw you edit pages often 3-4 times within 30 minutes. Would you please try to collect some info, place it all in an article, show the preview and than save it in once.

That's easier for all of us.

Thanks for your understanding,

[[User:Gijs|Gijs]] 09:21, 6 March 2008 (EST)

----

Hi, I'd really love to make more comprehensive edits at once, however due to the current state of affairs regarding the wiki, this can be hardly encouraged unfortunately.

Yes, sometimes I do indeed make commits without previewing things but that's mostly because of the latency involved doing ANYTHING on the wiki. And yes, I also find unnecessarily verbose commit histories somewhat disturbing.

However as discussed on the Main page's talk page, very often people will get kicked out or experience lots of other problems and even errors while working on the wiki.
Thus making tiny atomic changes and saving them right away seems to be the easiest way to ensure that stuff is actually stored directly.
Also, one of the most frustrating things is making significant modifications only to see that your session timed out and contents were not saved.

Apart from that, that's by the way how most wikis usually happen to work; not everybody has the time to sit down and make directly huge modifications of acceptable quality, rather people will often commit minor changes, so that contents will grow increasingly until they justify being refactored accordingly to resemble one comprehensive article, hopefully with an overall improve in quality. All this doesn't necessarily have to happen by one single person, though.

Anyway, you've really done a magnificent job at cleaning up the wiki, it has become so much more intuitive and convenient!

However, some of your modifications regarding my commits could be considered somewhat short-sighted, while I do understand the problem and share the view about empty skeleton pages and stub categories, it is important to view this issue from a wider angle: checking out my commit history (but also the commit history of several other contributors), you might notice that quite often page skeletons are committed to provide a structure and foundation for future contributions using boilerplate contents, sometimes this works right away-sometimes it doesn't.

In fact, some of the page skeletons (i.e. pretty much empty pages) I have created in the past have meanwhile become rather popular and are among those pages that are being consulted relatively often.So, such pages aren't necessarily about immediate usefulness, but must rather be seen as foundations for later additions and to provide a form of structure that is essential to cleanly organize contents.

This approach has in the past indeed worked quite succesfully for various different pages and contributors.

Yes, empty pages can be frustrating from a user's point of view, however on the other hand this is also how such pages get more attention, so that more potential contributors are made aware of a page being requested comparatively often.

So, rather than removing all references to such boilerplate pages or possibly even removing the pages altogether, it might make sense to find a compromise, which might for example entail moving them to less prominent places and putting such items into their own "Currently being worked on" section, but also putting a "stub" attribute on all such pages.

Regarding the removal of various categories that I recently added to several pages, you seem to have a misconception about why I added them in the first place, you may want to check out my user page to find an explanation for the motives behind adding such categories; in short: unless someone is going to step up and replace those sections of the wiki that are currently being abused to implement functionalities that are normally provided by separate dedicated software suites (i.e. bug tracker, FAQ database, aircraft database, knowledgebase system), such wiki contents are not as accessible as they ought to be, it is for example hardly possible to easily search existing bugs, or categorize aircraft by meta information.

The compromise that I settled for was to add corresponding attributes (i.e. categories) to each page in order to eventually be able to at least refine searches using such categories, so that for example an aircraft's properties were formally described using categories to determine feature completion.
--[[User:MILSTD|MILSTD]] 10:25, 6 March 2008 (EST)

----

You say that a Wiki is for tiny additions at a time. That's true, not everyone has got the time to make a large article at once. But you certainly do because you're working 30 minutes on one article, but you do it in 5 pieces or less. I've got problems with the Wiki to. It's not always working correct at the moment. But you could save the article (just copy the code with Ctrl+C) before showing a preview. If you're kicked out than you could simply refresh and paste (Ctrl+V) the code back in the editwindow.

Empty pages aren't needed. If you just place a wikilink at some pages to an article that doesn't excist (yet) it's good. Everyone could see that the article is empty (it's a red colored link) and it appears in the [[Special:Wantedpages]] list. People who want to add articles could search this list and they'll see the article you've placed the links for. This way it's easier for all of us to see if an article excists or not. If you make a page with only some headings it looks like the article excists while it isn't.

I agree with you that some more categories are needed. But it's not needed to make a categorie with only one or two articles in it (unless you're sure there will be soon more articles fitting in that categorie). I'm not saying that all your categories are usseless. There are some good ones (and I've made a categorie that was not needed later on to) and I don't wanna encourage you to stop helping us at the Wiki. But I really appreciate it if you would write a little more content on articles rather than just creating them and categorising them.

Thanks and succes with your further wiki-work ;)

[[User:Gijs|Gijs]] 10:48, 6 March 2008 (EST)

==ac001 and heading required :-)==
''agrees with the fat above that editing pages takes time - and sorry for all atomic commits but was necessary'''
* MILSTD - You have put a lot of Input into this wiki. Its fantastic, I take my cap off and thanks, because you must have spent hours and hours on it. I'm a new kid on the block, and having maintained other wiki's eg devmo I understand your frustration sometimes and my motivation is nto to mess it all up.

* Gijs - You are frustrated sometimes with edits lists. I agree with MILSTD that its impossible to edit stuff "en masse". However its cool and look its cool u the editor.

I am not going to get pissed off if u go and mess with my articles. Mass changes here and there are necessary to "edit" the stuff till its clear. Indeed I would prefer to completely Nuke pages. However that means going and reppoing backlinks.

Indeed getting down to the "nitty gritty" and making of a single page and the formating etc correct and easy, as well as presenting and linking is what we need to make it perfect, because it has to "read" and "feel" right. Such as a little snipet of code here there, removal of dead lines, adding a link etc and there is all thats needed.
Changing works "here and ther

I have great difficulty in creating pages. I have to actually verbally speak it back to myself a few moments or hours later to make it make sense!! However sometimes knicking it up on the spot because its missing is valuable also.

imho, this is the beauty of the wiki. In that a few years later someone comes along and makes it correct.
All the pages are different, and all will have the character of the person who wrote it.

The only goal imho is Glbal World Domination with FlightGear, the most popular and best, without having to spend cash on software (IMHO). So its a kinda chicken and egg zone, and a free for all because if someone has gone to the effort to editing a page, then imho there must be something passion and reason for doing so. I am a victim of that.

So my questions are?
* where is the [[wiki/TODO]] list for wiki? - There's stuff looking at [http://cvs.flightgear.org/viewvc/source/docs-mini/ /source/docs-mini/] that should be here. Albeit that the source docs have had no love and affection for a long time.
* Also I think that "subject" navigation is important.. Ie being in a "zone" eg the recent property tree, or ATC or AutoPilot. I like the "nav shortucts" links, (ta gijs)
* Categories do the same thing, but not as effectively.

I think we have the following user bases.
=Potential Pilot=
Indeed I'll put the critisism here, as in my eyes the "front" at flightgear.org looks like some redundant project. from last century.! anyway
Whilst the landing Main Page on wiki has no direction for either users or dev.

I am a faithful servant and wish to serve, and realise its a crazy mad world with lots of various mindsets.

damn I clicked the preview button once.. Second time lucky..
[[User:Ac001|ac001]] 09:33, 11 September 2009 (EDT)

User:Ac001/Navigation Tutorial

2010-06-22T01:10:12Z

Ac001:

{{Ac001-tutorial-navbar}}

'''Work in Progress'''

==How to take off and land==
This tutorial explains how to take off and fly ahead, then do a "circuit",

First thing to do is reconginse a compass and direction

http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10279.html

User:Ac001/ATC Tutorial

2010-06-13T00:57:23Z

Ac001:

==Air Traffic Control==
An aircraft is going nowhere unless instructed by [[ATC]] (and a [[Flight Plan]]).

There are various roles in the the enviroment:
* Ground Control - ie pushback, taxing down to runway
* Departures - sequencing the departure slots and take off
* Lower Air Control
*

==Radio Communications==
With ATC, you are constantly being updated on position, or reporting to "guide" you through an area.

==Callsign==
AC001 = Alpha Bravo Zero Zero One
BAZ129 = Bravo Alpha Zulu One Two Niner

Alpa Bravo Charlie etc..
Niner has the "er" on the end, because over distance the nine and five sound the same..

User:Ac001/ATC Tutorial

2010-06-12T23:39:30Z

Ac001:

User:Ac001/ATC Tutorial

2010-06-12T23:13:00Z

Ac001: Created page with '==Air Traffic Control== An aircraft is going nowhere unless instructed by ATC (and a Flight Plan). There are various roles in the the enviroment: * Ground Control - ie …'

Current events

2010-06-06T17:51:03Z

Ac001: correcting millenium

This page lists events directly, or indirectly, related to [[FlightGear]]. Please note that FlightGear is not being advertised at all of these events, but feel free to spread the word when you visit an event ;)

Upcoming and past [[multiplayer]] events can be found in the [http://www.flightgear.org/calendar.html FlightGear MP Event calendar].

'''Feel free to add events that are linked to FlightGear.'''

==Upcoming events==
* '''June 9-12 2010:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the ''Messegelände unter dem Funkturm'', Berlin, Germany
* '''July 6-11 2010:''' [http://2010.rmll.info/?lang=en Libre Software Meeting] in Bordeaux, France
* '''August 28+29 2010:''' [http://www.astrasimexpo.co.uk/ Summer Sim 2010] at the Royal Air Force Museum, Cosford, United Kingdom
* '''November 6+7 2010:''' [[FSweekend]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)

==Past events==
* '''May 15+16 2010:''' [http://www.fscweston.co.uk/ Flight Simulator Convention 2010] at the Helicopter Museum in Weston Super Mare, North Somerset, United Kingdom
* '''November 7+8 2009:''' [[FSweekend]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
** [http://www.xs4all.nl/~dtalsma/FSWeekend/web/ Pictures]
* '''June 24-27 2009:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the Messegelände unter dem Funkturm, Berlin, Germany
* '''November 1+2 2008:''' [[FSweekend]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
** [http://www.t3r.de/flightpics/fsweekend2008/ Pictures]
* '''May 28-31, 2008:''' [http://www.linuxtag.org/2008 LinuxTag] at Berlin's Messezentrum unter dem Funkturm. The world's No. 1 Linux Expo and Conference since 1996
** [http://www.t3r.de/linuxtag/ Pictures]
** [http://durktalsma.xs4all.nl/LinuxTag2008/web/index.html Pictures]
* '''February 8-10 2008:''' [http://www.socallinuxexpo.org Southern California Linux Expo] in The Westin Hotel (Los Angeles, CA, United States)
* '''November 3+4 2007:''' [[FSweekend]] at Aviodrome (Lelystad Airport, the Netherlands)
** [http://durktalsma.xs4all.nl/FSWeekend2007/web/index.html Pictures]
* '''May 30-June 2 2007:''' [http://www.linuxtag.org/2007 LinuxTag] at Berlin's Messezentrum unter dem Funkturm. The world's No. 1 Linux Expo and Conference since 1996
* '''November 4+5 2006:''' [[FSweekend]] at Aviodrome (Lelystad Airport, the Netherlands)

[[Category:List]]
[[Category:Community]]

File:Ac001 egll 27R threshold map.jpeg

2010-06-06T04:27:04Z

Ac001: uploaded a new version of "File:Ac001 egll 27R threshold map.jpeg": Am an idiot.. should have got the right runway...

EGLL 27R threshold map

User:Ac001/Navigation Tutorial

2010-06-06T03:45:47Z

Ac001: Created page with '=Navigation= Air navigation is based on maritime navgation, a stable and safe, tried and tested technique. * The NDB is the remnants still used from the original system * VOR/D…'

=Navigation=
Air navigation is based on maritime navgation, a stable and safe, tried and tested technique.
* The NDB is the remnants still used from the original system
* VOR/DME is the main system used and verification for
* EGPS which is the current technique ie augmented GPS

==Non Direction Beacon==

User:Ac001/Runway Tutorial

2010-06-06T03:28:40Z

Ac001: /* 27R */

{{Ac001-tutorial-navbar}}
=Orientation=
The map belows shows the three tarmac/pavements and six runways at [[EDDF]] Frankfurt.

[[File:Ac001 runways frankfurt.jpeg]]
* Runways ([[RWY]]) are numbered between '''01''' and '''36''' to indicate their '''magnetic heading''' (to nearest 10th degree).
* RWY 36 points north, 18 points south and 07 points NW.
* A runway can be used in both directions and therefore two names, eg '''RWY 18/36'''.
* If there are two or more runways, then '''L''', '''C''' and '''R''' are appended for Left, Center, Right, eg '''07L/25R'''.

=EGLL: 09L/27R=
The diagram shows the detail of the northen runway at Heathrow '''EGLL 09L/27R'''
[[File:Ac001 egll runway icao.jpeg]]
* The DME (top center) is the location of the [[DME]] transmitter and is placed around half way down the runway.
* Below is the label indicating the RWY length, 3901M long and 50m wide and is designed to facilitate huge/heavy/fast aircraft, as well as small ones.
* The lines of the centre line are at ?m intervals
* Below the red T, are the green lights of the "threshold", a point at which aircraft are to land or take off after. 09L is a displaced threshold as its further onto the tarmac and a blast zone.
* Under the red '''P''' on both sides are the [[PAPI]] lights next to the "touch down zone", a point past the threshold and the safe landing area.
* TODO - elevation description
* TODO The lead in lights and the ILS position TODO

==27R==
Below is the google map view of 27R threshold.
* '''T'''is the threshold
* Above the vertical purple lines are the "lead in lights", and these stretch at 25 intervals over a motorway, football pitch and a light inductrial area.
* The ILS system is clearly visible
[[File:Ac001 egll 27R threshold map.jpeg]]

The image below is an aicraft fly-by of the northen runway 27R (right entry above)

[[File:Ac001 egll 27R view.jpeg]]
* '''27R''' is clearly marked on the runway tarmac in foreground.
** The parallel 27L (09R threshold) is visible top left.
* '''T''' is the runway '''[[threshold]]''' and green lights. From the opposite side ie 09L these appear as red.
* The [[ILS]] localiser is positioned the other end of the runway near 09L threshold and red lights.
* '''D''' is the approx position of the DME transmitter halfway down the runway.
* The '''P''' are the [[PAPI]] lights, aircraft is high for fly-by.
* The '''Z''' is the target "touch down zone"

===09L===
The image below is a fly-by near the 09L threshold, a few moment after above (exiting to the left above)

[[File:Ac001 egll 09L view.jpeg]]
* '''9L''' is clearly marked on the runway for approaching aircraft
* The '''Threshold''' is marked with "red lights" and from the other side and landing, these are green.
* The threshold is "displaced" from the end of the actual tarmac and a line-up/blast zone.
* The ILS system is beyond the tarmac, the red/white coloured box.
* A taxi way is visible leading to or from the runway.

User:Ac001/Runway Tutorial

2010-06-06T03:18:50Z

Ac001: /* 27R */

{{Ac001-tutorial-navbar}}
=Orientation=
The map belows shows the three tarmac/pavements and six runways at [[EDDF]] Frankfurt.

[[File:Ac001 runways frankfurt.jpeg]]
* Runways ([[RWY]]) are numbered between '''01''' and '''36''' to indicate their '''magnetic heading''' (to nearest 10th degree).
* RWY 36 points north, 18 points south and 07 points NW.
* A runway can be used in both directions and therefore two names, eg '''RWY 18/36'''.
* If there are two or more runways, then '''L''', '''C''' and '''R''' are appended for Left, Center, Right, eg '''07L/25R'''.

=EGLL: 09L/27R=
The diagram shows the detail of the northen runway at Heathrow '''EGLL 09L/27R'''
[[File:Ac001 egll runway icao.jpeg]]
* The DME (top center) is the location of the [[DME]] transmitter and is placed around half way down the runway.
* Below is the label indicating the RWY length, 3901M long and 50m wide and is designed to facilitate huge/heavy/fast aircraft, as well as small ones.
* The lines of the centre line are at ?m intervals
* Below the red T, are the green lights of the "threshold", a point at which aircraft are to land or take off after. 09L is a displaced threshold as its further onto the tarmac and a blast zone.
* Under the red '''P''' on both sides are the [[PAPI]] lights next to the "touch down zone", a point past the threshold and the safe landing area.
* TODO - elevation description
* TODO The lead in lights and the ILS position TODO

==27R==
Below is the google map view of 27R threshold
[[File:Ac001 egll 27R threshold map.jpeg]]

The image below is an aicraft fly-by of the northen runway 27R (right entry above)

[[File:Ac001 egll 27R view.jpeg]]
* '''27R''' is clearly marked on the runway tarmac in foreground.
** The parallel 27L (09R threshold) is visible top left.
* '''T''' is the runway '''[[threshold]]''' and green lights. From the opposite side ie 09L these appear as red.
* The [[ILS]] localiser is positioned the other end of the runway near 09L threshold and red lights.
* '''D''' is the approx position of the DME transmitter halfway down the runway.
* The '''P''' are the [[PAPI]] lights, aircraft is high for fly-by.
* The '''Z''' is the target "touch down zone"

===09L===
The image below is a fly-by near the 09L threshold, a few moment after above (exiting to the left above)

[[File:Ac001 egll 09L view.jpeg]]
* '''9L''' is clearly marked on the runway for approaching aircraft
* The '''Threshold''' is marked with "red lights" and from the other side and landing, these are green.
* The threshold is "displaced" from the end of the actual tarmac and a line-up/blast zone.
* The ILS system is beyond the tarmac, the red/white coloured box.
* A taxi way is visible leading to or from the runway.

File:Ac001 egll 27R threshold map.jpeg

2010-06-06T03:16:40Z

Ac001: EGLL 27R threshold map

EGLL 27R threshold map

Template:Ac001-tutorial-navbar

2010-06-06T03:01:36Z

Ac001:

{|style="padding:0.3em; float:right; margin-left:15px; border:1px solid #A3B1BF; background:#efefef; font-size:95%; padding:0px; line-height:1.5em;"
!style="padding:0.3em; background-color:#0f7a71; line-height:2.5em; text-align:center;"|Flight College
|-
|
* [[User:Ac001/Tutorial Overview|Overview]]
* [[User:Ac001/Navigation Tutorial|Navigation]]
* [[User:Ac001/Airport Tutorial|Airport]]
* [[User:Ac001/Runway Tutorial|Runway]]
* [[User:Ac001/Takeoff|Takeoff]]
* [[User:Ac001/Cruise|Cruise]]
* [[User:Ac001/Landing|Landing]]
* [[User:Ac001/SID Tutorial|SID]]
* [[User:Ac001/STAR_Tutorial|STAR]]
* [[User:Ac001/ILS|ILS basics]]
* [[User:Ac001/Approach Procedures Tutorial|Initial Approach]]
* [[User:Ac001/Final Approach Tutorial|Final Approach]]
* [[User:Ac001/Checklist Tutorial|Checklists]]
* [[User:Ac001/ATC Tutorial]]
|}

<noinclude>[[Category:Navigation template]]</noinclude>

User:Ac001/Runway Tutorial

2010-06-06T02:51:55Z

Ac001: /* Orientation */

{{Ac001-tutorial-navbar}}
=Orientation=
The map belows shows the three tarmac/pavements and six runways at [[EDDF]] Frankfurt.

[[File:Ac001 runways frankfurt.jpeg]]
* Runways ([[RWY]]) are numbered between '''01''' and '''36''' to indicate their '''magnetic heading''' (to nearest 10th degree).
* RWY 36 points north, 18 points south and 07 points NW.
* A runway can be used in both directions and therefore two names, eg '''RWY 18/36'''.
* If there are two or more runways, then '''L''', '''C''' and '''R''' are appended for Left, Center, Right, eg '''07L/25R'''.

=EGLL: 09L/27R=
The diagram shows the detail of the northen runway at Heathrow '''EGLL 09L/27R'''
[[File:Ac001 egll runway icao.jpeg]]
* The DME (top center) is the location of the [[DME]] transmitter and is placed around half way down the runway.
* Below is the label indicating the RWY length, 3901M long and 50m wide and is designed to facilitate huge/heavy/fast aircraft, as well as small ones.
* The lines of the centre line are at ?m intervals
* Below the red T, are the green lights of the "threshold", a point at which aircraft are to land or take off after. 09L is a displaced threshold as its further onto the tarmac and a blast zone.
* Under the red '''P''' on both sides are the [[PAPI]] lights next to the "touch down zone", a point past the threshold and the safe landing area.
* TODO - elevation description
* TODO The lead in lights and the ILS position TODO

===27R===
The image below is an aicraft fly-by of the northen runway 27R (right entry above)

[[File:Ac001 egll 27R view.jpeg]]
* '''27R''' is clearly marked on the runway tarmac in foreground.
** The parallel 27L (09R threshold) is visible top left.
* '''T''' is the runway '''[[threshold]]''' and green lights. From the opposite side ie 09L these appear as red.
* The [[ILS]] localiser is positioned the other end of the runway near 09L threshold and red lights.
* '''D''' is the approx position of the DME transmitter halfway down the runway.
* The '''P''' are the [[PAPI]] lights, aircraft is high for fly-by.
* The '''Z''' is the target "touch down zone"

===09L===
The image below is a fly-by near the 09L threshold, a few moment after above (exiting to the left above)

[[File:Ac001 egll 09L view.jpeg]]
* '''9L''' is clearly marked on the runway for approaching aircraft
* The '''Threshold''' is marked with "red lights" and from the other side and landing, these are green.
* The threshold is "displaced" from the end of the actual tarmac and a line-up/blast zone.
* The ILS system is beyond the tarmac, the red/white coloured box.
* A taxi way is visible leading to or from the runway.

User:Ac001/Checklist Tutorial

2010-06-06T02:48:07Z

Ac001: /* After take off checlist */

=Checklist=
Every Pilot and flight has a checklist, its an "idiot test" to ensure the pilot's have not missed anything. These have been designed over the years to ensure that some simple detail is not missed. And its easy to miss some vital aspect as focus moves to another issue over a short period of time.
* Before landing checklist - the gear is down (oops forgot will not pass managment)
* Pressure enabled - cabin pressure is working (oops all of the pilot and crew fainted with lack of oxygen)
* Crashed into a mountain - nav error (oops I stuck in 4000ft instead of 3000ft)
* (The author spend 10hrs on an ocean flight, and almost perfect landing.. but no gear down. was in garden frustrated for a period realising stupidness of error in two critical minutes of period)

=Checklists=
Similar to a car journey, there are some idiot check's along the way to ensure the enviroment safe.

And as both experienced and un-experienced pilots there would be some issues that can cause problem, such as landing without the gear down, or frozen fuel because gear was not up mid ocean.

That is why pilots, whatever flavour have checklists.

These are by designed to ensure accidents do not happen, and for safety.

Within a modern cockpit and PF, PNF there is a dailog wherby the checklist is "checked of" with one "speaking the fact" and the other "confirming" the idiot check.

The "sheet" is normally a laminated charts

==Pre Take Off==
This is a pretend dialog of an aircraft preparing for takeoff..
Ok lets do teh pre tak off checklists...

Runway is 28L - check
Take off speed is 120 - check
Rotate is at 130 knots - check
Autopilot is set for 125 and SID departure at 5% - check
FLAPS are at 3 - check
Autrotthrell is set but not armed for TOGA at 160 - check
Takoff clearance - standby
>> ATC Alpha Charlie Zero Zero One ready for take off clearance.
Clear for take off Alpha Charlie zero Zero One 28L
Roger Pre takeoff Alpha Charlie zero Zero One 28L
>> Take off checklist complete (laminate is put away)
==After take off checlist==
* landing gear is up - check
* Flaps are at min - check
* Stable speed and direction - check
* IAS is set and direction - check
===Before Landing Checklist===

User:Ac001/Tutorial Overview

2010-06-06T02:27:58Z

Ac001: /* Analogies */

{{Ac001-tutorial-navbar}}

===Pre Intro===
* Welcome to some tutorials in sandbox and idea, working towards a "crash course" or "flight college"... this is all WIP (work in progress)
* The "airport" and "area" is London Heathrow and UK
* Feedback, corrections most welcome, etc (just go and edit stuff)
* The format is experimental and intended to make it an "observationsal" style by presenting a scenario..
* Its hoped that the format can be used for other languages eg Paris/french, Milan/Italy
* Not sure how advanced or simple to make this stuff, but its assumed user can fly an aircraft.

=Welcome to Flight College=
This is a tutorial and training series to assist new pilots get aqquainted with making trips between airports via [[IFR]].
* The series is centred on '''[[EGLL]]''' - London Heathrow Airport, UK.
** Charts from NATS
* UK airspace is governed by the UK's '''Civil Aviation Authority''' ([[CAA]]) who constantly maintain the intricate details, and publish them.
* The charts, data, et all are available from '''National Air Traffic Services''' ([[NATS]]) an ''air navigation service provider''.
* Euro Control is a sister organisation for coordinating airspace in Europe.

If you are a new pilot, then this series will take you through the steps. If the text below doesn't make sense now, it will by the end of this series. Your feedback, corrections and suggestions etc are important and valuable to help other TPs in the future.
==Analogies==
A similar concept to flying and aircraft from A to is that of driving a car on a long journey
*Prep
** in a car you have to prepare the car, fuel, check wipers, tyres(+spare) ok, water ok etc for 16hr drive
** in an aircraft u hwave to prepeare, check wipers, batteries, tyres, for 2hr flight
*Direction
** leave down the street, then through town, to motorway and the junction heading north..
** leave down the taxiway, from the parking to the runway, runway heading is SE, take off then head north
*Cruise
** On the motorway I want to travel at around 75kph, 5kph above the legal speed limit of 70kph.... so hopefully camera wont catch me..
** I need to be over 80ias, if I'm slower than that then I stall the wings and drop out of the sky in spectacular.
*Stop
**If car ahead, I can slam on the brakes and with all the kids, wife, picnic and caravan, can come to a compete stoop in about 50m
** Aircraft in air, there is no way to stop, I need to fly around up or down and around.. Stopping is impossible..
*Navigation
** Can we stop the car and look at the map... right we are here.... so if we turn back the other way we'll be there.. and decide there ok.. ''(NO no I think we should take this route.. trust me.. I think I been here before, maybe)''
** We cant stop the aircraft, so a few moments ago we were there, so were heading that way.. soon to be there.

===Pre Flight Briefing===
This is an example conversation and a briefing by the [[PNF]] to the [[PF]]. In this instance the [[First Officer]] is flying back with the Commander being the monitor.
* [[PF]] is commanding the aircraft
* [[PNF]] is doing the ATC and monitoring pilot
* Within FG, you are both.
So its the usual EGLL to EGCC, its SE wind at EGLL so RWY 09R for HON SID, then UL9 FL15 to WAL STAR, then expected NW approach to EGCC 90.

===Reality===
To be a '''real pilot''', you would do a lot of classes and tests. The tests can be really nasty and pilots are expected to perfrom at around ninety-eight percent . Indeed a lot of training is done now in a simulator, such is the sophistication. Crashing real aircraft costs money.
===Simulator===
To be a '''real pilot''', you would do a lot of classes and tests, crash and test a few planes.. switch the weather to hurricance for fun.. then ...

==Overview==

* '''Airport''' - explains the airport enviroment
* '''Runway''' explains the runway

User:Ac001/Tutorial Overview

2010-06-06T02:06:12Z

Ac001: /* Welcome to Flight College */

User:Ac001/Checklist Tutorial

2010-06-06T02:05:03Z

Ac001:

User:Ac001/Checklist Tutorial

2010-06-06T01:30:53Z

Ac001: /* pilot take off */

Every Pilot has a checklist, and an "idiot test" to ensure the pilot's have not missed anything.

=Checklists=
Similar to a car journey, there are some idiot check's along the way to ensure the enviroment safe.

And as both experienced and un-experienced pilots there would be some issues that can cause problem, such as landing without the gear down, or frozen fuel because gear was not up mid ocean.

That is why pilots, whatever flavour have checklists.

These are by designed to ensure accidents do not happen, and for safety.

Within a modern cockpit and PF, PNF there is a dailog wherby the checklist is "checked of" with one "speaking the fact" and the other "confirming" the idiot check.

The "sheet" is normally a laminated charts

==Pre Take Off==
This is a pretend dialog of an aircraft preparing for takeoff..
Ok lets do teh pre tak off checklists...

Runway is 28L - check
Take off speed is 120 - check
Rotate is at 130 knots - check
Autopilot is set for 125 and SID departure at 5% - check
FLAPS are at 3 - check
Autrotthrell is set but not armed for TOGA at 160 - check
Takoff clearance - standby
>> ATC Alpha Charlie Zero Zero One ready for take off clearance.
Clear for take off Alpha Charlie zero Zero One 28L
Roger Pre takeoff Alpha Charlie zero Zero One 28L
>> Take off checklist complete (laminate is put away)
==After take off checlist==
* landing gear is up - check
* Flaps are at min - check
* Stable speed and direction - check
* IAS is set and direction - check

User:Ac001/Checklist Tutorial

2010-06-06T01:24:23Z

Ac001: Created page with 'Every Pilot has a checklist, and an "idiot test" to ensure the pilot's have not missed anything. =Checklists= Similar to a car journey, there are some idiot check's along the wa…'

Every Pilot has a checklist, and an "idiot test" to ensure the pilot's have not missed anything.

=Checklists=
Similar to a car journey, there are some idiot check's along the way to ensure the enviroment safe.

And as both experienced and un-experienced pilots there would be some issues that can cause problem, such as landing without the gear down, or frozen fuel because gear was not up mid ocean.

That is why pilots, whatever flavour have checklists.

These are by designed to ensure accidents do not happen, and for safety.

Within a modern cockpit and PF, PNF there is a dailog wherby the checklist is "checked of" with one "speaking the fact" and the other "confirming" the idiot check.

The "sheet" is normally a laminated charts

==Pre Take Off==
This is a pretend dialog of an aircraft preparing for takeoff..
Ok lets do teh pre tak off checklists...

Runway is 28L - check
Take off speed is 120 - check
Rotate is at 130 knots - check
Autopilot is set for 125 and SID departure at 5% - check
FLAPS are at 3 - check
Autrotthrell is set but not armed for TOGA at 160 - check
Takoff clearance - standby
>> ATC Alpha Charlie Zero Zero One ready for take off clearance.
Clear for take off Alpha Charlie zero Zero One 28L
Roger Pre takeoff Alpha Charlie zero Zero One 28L
>> Take off checklist complete (laminate is put away)
==pilot take off==

Below is the the "pre takeoff checklist and CRM"..

Template:Ac001-tutorial-navbar

2010-06-06T00:59:41Z

Ac001:

{|style="padding:0.3em; float:right; margin-left:15px; border:1px solid #A3B1BF; background:#efefef; font-size:95%; padding:0px; line-height:1.5em;"
!style="padding:0.3em; background-color:#0f7a71; line-height:2.5em; text-align:center;"|Flight College
|-
|
* [[User:Ac001/Tutorial Overview|Overview]]
* [[User:Ac001/Checklist Tutorial|Checklists]]
* [[User:Ac001/Airport Tutorial|Airport]]
* [[User:Ac001/Runway Tutorial|Runway]]
* [[User:Ac001/Takeoff|Takeoff]]
* [[User:Ac001/Cruise|Cruise]]
* [[User:Ac001/Landing|Landing]]
* [[User:Ac001/SID Tutorial|SID]]
* [[User:Ac001/STAR_Tutorial|STAR]]
* [[User:Ac001/ILS|ILS basics]]
* [[User:Ac001/Approach Procedures Tutorial|Initial Approach]]
* [[User:Ac001/Final Approach Tutorial|Final Approach]]
* [[User:Ac001/ATC Tutorial]]
|}

<noinclude>[[Category:Navigation template]]</noinclude>

User:Ac001/Takeoff

2010-06-06T00:58:21Z

Ac001: /* Stratergies */

{{Ac001-tutorial-navbar}}
==Take Off==
The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam.
* Top left on '''36L''' is a '''737 Airliner''' (helijah)
** heavy aircraft for international 10 hr flight
** takeoff speed is 140 knots into headwind
* Bottom left on '''06''' is a '''Beechcraft twin prop''' (trennor)
** nimble small regional aircraft for 1 hour flight
** takeoff speed is 90 knots into a slight side wind
* Bottom right on '''36R''' is '''Citation Bravo twin jet''' (ac001)
** small jet for euro hopping on 3 hour flight
** takeoff speed is 120 knots

[[File:Ac001 eham takeoff1.jpeg]]
===Strategies===
* Each pilot has calculated the speed required to actually take off based on aircraft performance, runway length, weight, air pressure and many, many other factors some featured more below.
* Each pilot has shortened the runway by a "safety margin" (yellow lines) that has been deducted from the runway length, a "gut feel" for headwind, alignment in fog, etc.
* The red dot indicates the point that the aircraft is at enough speed it can safely take off with ONLY one engine.
* The green dot is the point where the aircraft '''has to take off''' as there is not enough runway left to stop.
* The purple dot is the hypothetical point where the aircraft would safely stop and well within runway limits.
** '''737'''
*** This aircraft is heavy with passengers, cargo and fuel and needs some momentum, and therefore requires more stopping distance.
*** The aircraft is just within the "margins" of runway/takeoff paramaters.
*** The throttle would be set to TOGA ie max.
** '''Beechcraft'''
*** This aircraft is light and requires little runway to take off at a slow takeoff speed
*** Throttle not full on as there is a lot of runway
*** The aircraft could have entered the taxiway halfway down the runway, and still conducted the takeoff on a shorter runway.
** '''Bravo'''
*** The lighter jet aircraft is taking advantage of the runway length.
*** The plan is accelerate slower and take off further down the runway with a '''[[Flex Temp]]''' takeoff, saving fuel, engine wear and less noise.

===General Info===
Below are some notes on the 'real world' scenario, some of the problems and techniques to get familiar and is biased towards jet aircraft and airliners.
* Airliner
** First the aircraft is aligned to the runway and positioned. Parkign brakes on.. this is an effort.. then pre take off checkists
** Clearance = ATc has said clear for take off
*** The engiones are fired up to 10% with the brakes ON. this will give time to warm up the engine and pumps, air bubbles.
*** The 25% period, where the jets are fired up more. Its nto full on yet to avoid blowoouts caused by air bubbles with in jet..
*** There is stabilised flow thought the engines and the aircaft is accelerating down the line...
*** v1 is achieved.. meaning we can take off.
*** v2 the point of having to take off is reached.. We can stop now. Before this point is a "rejected takeoff"

User:Ac001/Takeoff

2010-06-05T22:01:20Z

Ac001: /* Calculations */

{{Ac001-tutorial-navbar}}
==Take Off==
The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam.
* Top left on '''36L''' is a '''737 Airliner''' (helijah)
** heavy aircraft for international 10 hr flight
** takeoff speed is 140 knots into headwind
* Bottom left on '''06''' is a '''Beechcraft twin prop''' (trennor)
** nimble small regional aircraft for 1 hour flight
** takeoff speed is 90 knots into a slight side wind
* Bottom right on '''36R''' is '''Citation Bravo twin jet''' (ac001)
** small jet for euro hopping on 3 hour flight
** takeoff speed is 120 knots

[[File:Ac001 eham takeoff1.jpeg]]
===Stratergies===
* Each pilot has calculated the speed required to actually take off based on aircraft performance, runway length, weight, air pressure and many, many other factors some featured more below.
* Each pilot has shortened the runway by a "safety margin" (yellow lines) that has been deducted from the runway length, a "gut feel" for headwind, alignment in fog, etc.
* The red dot indicates the point that the aircraft is at enough speed it can safely take off with ONLY one engine.
* The green dot is the point where the aircraft '''has to take off''' as there is not enough runway left to stop.
* The purple dot is the hypothetical point where the aircraft would safely stop and well within runway limits.
** '''737'''
*** This aircraft is heavy with passengers, cargo and fuel and needs some momentum, and therefore requires more stopping distance.
*** The aircraft is just within the "margins" of runway/takeoff paramaters.
*** The throttle would be set to TOGA ie max.
** '''Beechcraft'''
*** This aircraft is light and requires little runway to take off at a slow takeoff speed
*** Throttle not full on as there is a lot of runway
*** The aircraft could have entered the taxiway halfway down the runway, and still conducted the takeoff on a shorter runway.
** '''Bravo'''
*** The lighter jet aircraft is taking advantage of the runway length.
*** The plan is accelerate slower and take off further down the runway with a '''[[Flex Temp]]''' takeoff, saving fuel, engine wear and less noise.

File:Ac001 eham takeoff1.jpeg

2010-06-05T03:22:30Z

Ac001: uploaded a new version of "File:Ac001 eham takeoff1.jpeg"

EHAM takoff with three classes of aircraft

User:Ac001/Takeoff

2010-06-05T03:21:46Z

Ac001: /* Calculations */

User:Ac001/Takeoff

2010-06-05T03:12:07Z

Ac001: /* Take Off */

User:Ac001/Takeoff

2010-06-05T02:18:35Z

Ac001:

{{Ac001-tutorial-navbar}}
==Take Off==
The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam.
* Top left on 36L is a '''737 Airliner''' (helijah) - heavy aircraft for international 10 hr flight
* Bottom left is a '''Beechcraft twin prop''' (trennor) - nimble small regional aircraft for 1 hour flight
* Bottom right a '''Citation Bravo twin jet''' (ac001) - small twin jet for euro hopping on 3 hour flight

[[File:Ac001 eham takeoff1.jpeg]]

User:Ac001/Takeoff

2010-06-05T02:09:18Z

Ac001:

{{Ac001-tutorial-navbar}}
The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam.
* Top left on 36L is a heavy 737 Airliner (helijah)
* Bottom left is a Beechcraft twin prop (trennor)
* Bottom right a Citation Bravo business jet (ac001)

[[File:Ac001 eham takeoff1.jpeg]]

File:Ac001 eham takeoff1.jpeg

2010-06-05T02:08:32Z

Ac001: uploaded a new version of "File:Ac001 eham takeoff1.jpeg"

EHAM takoff with three classes of aircraft

User:Ac001/Takeoff

2010-06-05T02:07:39Z

Ac001: Created page with 'The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam. * Top left on 36L is a heavy 737 Airliner (helijah) * Bottom left is a Beechcraft twin prop (…'

The map below shows three classes of aircraft waiting to take off at EHAM Amsterdam.
* Top left on 36L is a heavy 737 Airliner (helijah)
* Bottom left is a Beechcraft twin prop (trennor)
* Bottom right a Citation Bravo business jet (ac001)

[[File:Ac001 eham takeoff1.jpeg]]

File:Ac001 eham takeoff1.jpeg

2010-06-05T02:04:03Z

Ac001: uploaded a new version of "File:Ac001 eham takeoff1.jpeg"

EHAM takoff with three classes of aircraft

File:Ac001 eham takeoff1.jpeg

2010-06-05T01:53:06Z

Ac001: EHAM takoff with three classes of aircraft

EHAM takoff with three classes of aircraft

Template:Ac001-tutorial-navbar

2010-06-05T01:04:28Z

Ac001:

{|style="padding:0.3em; float:right; margin-left:15px; border:1px solid #A3B1BF; background:#efefef; font-size:95%; padding:0px; line-height:1.5em;"
!style="padding:0.3em; background-color:#0f7a71; line-height:2.5em; text-align:center;"|Flight College
|-
|
* [[User:Ac001/Tutorial Overview|Overview]]
* [[User:Ac001/Airport Tutorial|Airport]]
* [[User:Ac001/Runway Tutorial|Runway]]
* [[User:Ac001/Takeoff|Takeoff]]
* [[User:Ac001/Cruise|Cruise]]
* [[User:Ac001/Landing|Landing]]
* [[User:Ac001/SID Tutorial|SID]]
* [[User:Ac001/STAR_Tutorial|STAR]]
* [[User:Ac001/ILS|ILS basics]]
* [[User:Ac001/Approach Procedures Tutorial|Initial Approach]]
* [[User:Ac001/Final Approach Tutorial|Final Approach]]
* [[User:Ac001/ATC Tutorial]]
|}

<noinclude>[[Category:Navigation template]]</noinclude>

User:Ac001/Runway Tutorial

2010-06-04T03:32:20Z

Ac001: /* 27R */

{{Ac001-tutorial-navbar}}
=Orientation=
The map belows shows the three runways at [[EDDF]] Frankfurt.

[[File:Ac001 runways frankfurt.jpeg]]
* Runways ([[RWY]]) are numbered between '''01''' and '''36''' to indicate their '''magnetic heading''' (to nearest 10th degree).
* RWY 36 points north, 18 points south and 07 points NW.
* A runway can be used in both directions and therefore two names, eg '''RWY 18/36'''.
* If there are two or more runways, then '''L''', '''C''' and '''R''' are added for Left, Center, Right, eg '''07L/25R'''.

=EGLL: 09L/27R=
The diagram shows the detail of the northen runway at Heathrow '''EGLL 09L/27R'''
[[File:Ac001 egll runway icao.jpeg]]
* The DME (top center) is the location of the [[DME]] transmitter and is placed around half way down the runway.
* Below is the label indicating the RWY length, 3901M long and 50m wide and is designed to facilitate huge/heavy/fast aircraft, as well as small ones.
* The lines of the centre line are at ?m intervals
* Below the red T, are the green lights of the "threshold", a point at which aircraft are to land or take off after. 09L is a displaced threshold as its further onto the tarmac and a blast zone.
* Under the red '''P''' on both sides are the [[PAPI]] lights next to the "touch down zone", a point past the threshold and the safe landing area.
* TODO - elevation description
* TODO The lead in lights and the ILS position TODO

===27R===
The image below is an aicraft fly-by of the northen runway 27R (right entry above)

[[File:Ac001 egll 27R view.jpeg]]
* '''27R''' is clearly marked on the runway tarmac in foreground.
** The parallel 27L (09R threshold) is visible top left.
* '''T''' is the runway '''[[threshold]]''' and green lights. From the opposite side ie 09L these appear as red.
* The [[ILS]] localiser is positioned the other end of the runway near 09L threshold and red lights.
* '''D''' is the approx position of the DME transmitter halfway down the runway.
* The '''P''' are the [[PAPI]] lights, aircraft is high for fly-by.
* The '''Z''' is the target "touch down zone"

===09L===
The image below is a fly-by near the 09L threshold, a few moment after above (exiting to the left above)

[[File:Ac001 egll 09L view.jpeg]]
* '''9L''' is clearly marked on the runway for approaching aircraft
* The '''Threshold''' is marked with "red lights" and from the other side and landing, these are green.
* The threshold is "displaced" from the end of the actual tarmac and a line-up/blast zone.
* The ILS system is beyond the tarmac, the red/white coloured box.
* A taxi way is visible leading to or from the runway.

File:Ac001 egll 09L view.jpeg

2010-06-04T03:22:07Z

Ac001: EGLL 27R (09L threshold) flyby

EGLL 27R (09L threshold) flyby

File:Ac001 egll 27R view.jpeg

2010-06-04T03:21:22Z

Ac001: uploaded a new version of "File:Ac001 egll 27R view.jpeg"

EGLL 27R flyby

User:Ac001/Runway Tutorial

2010-06-04T03:16:23Z

Ac001: /* EGLL: 09L/27R */

{{Ac001-tutorial-navbar}}
=Orientation=
The map belows shows the three runways at [[EDDF]] Frankfurt.

[[File:Ac001 runways frankfurt.jpeg]]
* Runways ([[RWY]]) are numbered between '''01''' and '''36''' to indicate their '''magnetic heading''' (to nearest 10th degree).
* RWY 36 points north, 18 points south and 07 points NW.
* A runway can be used in both directions and therefore two names, eg '''RWY 18/36'''.
* If there are two or more runways, then '''L''', '''C''' and '''R''' are added for Left, Center, Right, eg '''07L/25R'''.

=EGLL: 09L/27R=
The diagram shows the detail of the northen runway at Heathrow '''EGLL 09L/27R'''
[[File:Ac001 egll runway icao.jpeg]]
* The DME (top center) is the location of the [[DME]] transmitter and is placed around half way down the runway.
* Below is the label indicating the RWY length, 3901M long and 50m wide and is designed to facilitate huge/heavy/fast aircraft, as well as small ones.
* The lines of the centre line are at ?m intervals
* Below the red T, are the green lights of the "threshold", a point at which aircraft are to land or take off after. 09L is a displaced threshold as its further onto the tarmac and a blast zone.
* Under the red '''P''' on both sides are the [[PAPI]] lights next to the "touch down zone", a point past the threshold and the safe landing area.
* TODO - elevation description
* TODO The lead in lights and the ILS position TODO

===27R===
The image below is an aicraft fly-by of the northen runway 27R (right entry above)

[[File:Ac001 egll 27R view.jpeg]]
* '''27R''' is clearly visible on the runway tarmac in foreground.
** The parallel 27L (09R threshold) is visible top left.
* '''T''' is the runway '''[[threshold]]''' and green lights. From the opposite side ie 09L these appear as red.
* The [[ILS]] localiser is positioned the other end of the runway near 09L threshold and red lights.
* '''D''' is the approx position of the DME transmitter halpway down the runway.
* The '''P''' are the PAPI lights, aircraft is high for fly-by.
* The '''Z''' is the target "touch down zone"

File:Ac001 egll 27R view.jpeg

2010-06-04T03:02:39Z

Ac001: EGLL 27R flyby

EGLL 27R flyby

User:Ac001/Runway Tutorial

2010-06-04T01:56:51Z

Ac001: /* EGLL: 09L/27R */

User:Ac001/Runway Tutorial

2010-06-04T01:55:51Z

Ac001:

File:Ac001 egll runway icao.jpeg

2010-06-04T01:37:50Z

Ac001: EGLL Runway Detail

EGLL Runway Detail

User:Ac001/STAR Tutorial

2010-06-04T01:01:13Z

Ac001: /* STAR Tutorial */

{{Ac001-tutorial-navbar}}
=STAR Tutorial=
* The map below features some of the '''Standard Terminal Arrival Routes''''s ([[STAR]]'s) for [[EGLL]] London Heathrow.
* The EGLL STAR's are for the two parallel runways '''09R/27L - 09L/27R''' (represented by purple near center).
* The STAR's are named after their arrival point. All the arrival points below are [[VOR]] stations with the exception of TOMMO which is a [[Fix]].
* The red '''H''' are the holding points en-route.
* Clockwise from the top they are:-
** '''Lambourne''' (yellow) - for E/NE arrivals.
** '''Biggin''' (orange) - for E/SE/S arrivals.
** '''Ockham u/s''' (yellow) - for S/SW arrivals (u/s denotes upper airspace).
** '''TOMMO''' (blue) - for W arrivals.
** '''Bovingdon''' (green) - for NW/N arrivals.
** '''Ockham''' (white) - for lower airspace arrival.

[[File:Ac001 EGLL STARs map.jpeg]]

* Aircraft are expected to arrive at 7,000ft which is the Mimimum Holding Altitude over London and speed limits etc.
* '''Lambourne'''
** LOGAN > TRIPO > BRASO > LAM
** The LOGAN Fix (rightmost to north) is the entry point and also the entry point for a Biggin arrival.
** The path is a direct radial between LOGAN and LAM with TRIPO and BRASO as convinient fix's
** LOGAN and TRIPO are holding points.
* '''Biggin'''
** LOGAN is an entry point for Biggin and Lambourne arrival
*** LOGAN > KOPUL > TANET > DET > BIG
*** DVR > SANDY > BIG
*** DVR > SANDY > TIGER > BIG
*** ALESO > TIGER > BIG
* '''Ockham u/s'''
** U/S denotes upper airspace arrival
*** KATHY > HAZEL > OCK
*** GIBSO > ELDER > HAZEL > OCK
*** SAM > HAZEL OCK
* '''TOMMO'''
** TOMMO is a fix and part of the Ockham holding pattern
*** NIGIT > TOMMO
*** KENET > TOMMO
*** HON > TOBID > SOPIT > WCO > TOMMO
* '''Bovingdon'''
** KENET > DONNA > BOV
** HON > TOBID > SPOIT > WCO > BOV
** LAM > DONNA > BOV
* '''Ockham''' in white
** This is "lower level" arrival.
*** LAM > DORKI > OCK
*** BIG > DORKI > OCK

==''LONDON HEATHROW via BOVINGDON''==
* The BNN [[STAR]] is for flights arriving from the north (eg X atlantic flights)
* The [http://en.wikipedia.org/wiki/Bovingdon_stack Bovingdon Stack] over the '''BNN''' vor, ready for '''Initial Approach''' to Heathrow. '''BNN''' is about 30km north off Heathrow and also the '''LON''' vor transmitter.
There are three simplified STAR's shown below followed by general info:

'''BNN 4A''' - yellow
BNN 4A Arrival via L10 (FL190 & below), N615 (FL90 to FL140) to HON VOR continue on HON VOR R142 to TOBID
then SOPIT (FL150 by SOPIT) to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.

'''BNN 1C''' - orange
Arrival via A47 (FL70) to DTY VOR continue on DTY VOR R166 to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.
'''BNN 1E''' in green
From LAM VOR maintain LAM VOR R278 to DONNA then turn right onto inbound holding track 119°M to BNN VOR.
'''General Information'''
1 Standard Routes may be varied at the discretion of ATC.
2 Cross SLPs or 3 min before holding facility at 250KIAS or less.
3 When BNN VOR is out of service the route will be to BOVVA, see AD 2-EGLL-7-4.
4 En-route holding at HON VOR: During periods of congestion in the London TMA traffic
from the north may be required to hold at HON VOR.
5 As lowest level in BNN holding stack (7000) is above transition altitude, aircraft
will be instructed by ATC to fly at the appropriate flight level.

[[File:Ac002 STAR egll BNN.jpeg]]

===BNN 4A with comment===
BNN 4A Arrival via L10 (FL190 & below), N615 (FL90 to FL140) to HON VOR continue on HON VOR R142 to TOBID
then SOPIT (FL150 by SOPIT) to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.
* Flight '''ac001''' (787) has passed the '''TOBID''' fix, heading 142, descending and slowing. Needs < 230 knots and at 15,000 by '''SPOIT''' fix ahead, before turn at '''WCO''' to '''BNN''' and [[IAF]].
'''BNN 4A Arrival'''
* '''BNN 4A''' is the "official CAA published name" of this route. It would appear on the "filed" FlightPlan.
'''via L10 (FL190 & below)'''
* '''L10''' is an airway and the leftmost brown line top left.
* The aircraft needs to flying under '''19,000ft''' ('''FL190''')
'''N615 (FL90 to FL140)'''
* '''N615''' is an airway and the middle brown line on the top left
* The aircraft needs to be flying on this leg FL90 and FL140
'''to HON VOR'''
* from either of the arrival routes above, the aircraft needs to cross over Honiley vor transmitter
'''continue on HON VOR R142'''
* then fly away from the transmitter heading south east on the '''142 radial''' which is also the heading
''' to TOBID'''
* '''TOBID''' is a fix on the path
''' then SOPIT (FL150 by SOPIT)'''
* '''SOPIT''' is a fix on the path
* the aircraft needs to be at '''15,000ft''' by this point
'''to WCO NDB'''
* '''Wescott''' is a Non Directional Beacon ([[NDB]]) on '''335'''
* and also the intersection of the '''HON 142''' and '''BNN 299''' radials
'''then turn left onto BNN VOR R299'''
* over Wescott NDB turn left towards the '''299 radial''' from Bovingdon - heading '''119'''
* the speed restriction ahead is '''< 250''' (note 2)
'''to BNN VOR.'''
* The red loop is the Bovington Stack holding point - the bottom of the stack is '''7,000ft''' (note 5)
* keep heading towards the BNN vor station
* BNN is the '''IAP''' (Initial Approach Fix) for EGLL
* The '''BNN''' Initial approach is shown in white

==BNN 4A Cockpit View==
* The [[Autopilot]] is engaged (green '''AP ENG''' top PFD) and commanding the aircraft speed, heading ('''SPD''', '''HNG''', '''ALT''' in green top of PFD).
* The nav display Range ('''R''') is set on the glareshield knob to '''80nm''', displayed left of nav display.
* The intersection of the arrows is around 20nm ahead.
[[File:Ac001 STAR egll BNN cockpit.jpeg]]

===HON vor===
* NAV1 is tuned to the HON vor '''113.65''' and the '''142''' radial.
* On the glareshield the VOR L (ie NAV1) switch is in the up position for display in blue on the nav display.
* On the nav display
** bottom left indicates VOR L is tuned to HON vor
** the Blue dot is the location of the transmitter and the blue arrow shows the 142 radial.
** The aircraft is '''DME 015.7''' (bottom left) from HON, ie 15.7nm away from the transmitter.

===BNN vor===
* NAV2 is tuned to the BNN vor '''113.75''' and the '''299 radial''' (119 heading).
* On the glareshield the VOR R (ie NAV2) switch is in the up position for display in green on nav display.
* On the nav display
** bottom right indicates '''VOR R''' is tuned to BNN vor
** the green dot is the location of the transmitter and the green arrow shows the '''299 radial'''.

===Position===
* The aircraft is heading '''142''', SE towards Wescott NDB.
* The autopilot is commanding the heading (green '''HDG''' top PFD), and heading bug is in nav display in pink.
* WCO ndb is not displayed, but is at the intersection of the HON 142 - BNN 299 radials.
* the '''HON''' vor transmitter is '''15.7nm''' behind displayed bottom left of nav display and top left of PFD.
* the aircraft is slightly off course to the right flying parallel.

===Speed===
* On the [[PFD]] - The green '''SPD''' top left indicates the [[Autopilot]] is commanding the speed. The target speed is '''230''' displayed in purple top left.
* The aircraft is travelling at '''249''' (mach '''.508''') and is slowing down to the '''230''' target. There is a speed restriction ahead of 250.

===Altitude===
* On the [[PFD]] - the green '''ALT''' top right indicates the [[Autopilot]] is commanding Altitude Hold. The target altitude is '''15,000ft''' ('''FL150''') displayed in purple top right.
* The aircraft it as crossing '''16,700ft''', descending at around '''500ft/m''' indicated on the right needle.

User:Ac001/STAR Tutorial

2010-06-04T00:58:06Z

Ac001: /* STAR Tutorial */

{{Ac001-tutorial-navbar}}
=STAR Tutorial=
* The map below features some of the ''popular'' '''Standard Terminal Arrival Routes''''s ([[STAR]]'s) for [[EGLL]] London Heathrow.
* The EGLL STAR's are for the two parallel runways '''09R/27L - 09L/27R''' (represented by purple near center).
* The STAR's are named after their arrival point. All the arrival points below are VOR stations with the exception of TOMMO which is a [[Fix]].
* The red '''H''' are the holding points en-route.
* Clockwise from the top they are:-
** '''Lambourne''' (yellow) - for E/NE arrivals.
** '''Biggin''' (orange) - for E/SE/S arrivals.
** '''Ockham u/s''' (yellow) - for S/SW arrivals (u/s denotes upper airspace).
** '''TOMMO''' (blue) - for W arrivals.
** '''Bovingdon''' (green) - for NW/N arrivals.
** '''Ockham''' (white) - for lower airspace arrival.

[[File:Ac001 EGLL STARs map.jpeg]]

* Aircraft are expected to arrive at 7,000ft which is the Mimimum Holding Altitude over London and speed limits etc.
* '''Lambourne'''
** LOGAN > TRIPO > BRASO > LAM
** The LOGAN Fix (rightmost to north) is the entry point and also the entry point for a Biggin arrival.
** The path is a direct radial between LOGAN and LAM with TRIPO and BRASO as convinient fix's
** LOGAN and TRIPO are holding points.
* '''Biggin'''
** LOGAN is an entry point for Biggin and Lambourne arrival
*** LOGAN > KOPUL > TANET > DET > BIG
*** DVR > SANDY > BIG
*** DVR > SANDY > TIGER > BIG
*** ALESO > TIGER > BIG
* '''Ockham u/s'''
** U/S denotes upper airspace arrival
*** KATHY > HAZEL > OCK
*** GIBSO > ELDER > HAZEL > OCK
*** SAM > HAZEL OCK
* '''TOMMO'''
** TOMMO is a fix and part of the Ockham holding pattern
*** NIGIT > TOMMO
*** KENET > TOMMO
*** HON > TOBID > SOPIT > WCO > TOMMO
* '''Bovingdon'''
** KENET > DONNA > BOV
** HON > TOBID > SPOIT > WCO > BOV
** LAM > DONNA > BOV
* '''Ockham''' in white
** This is "lower level" arrival.
*** LAM > DORKI > OCK
*** BIG > DORKI > OCK

==''LONDON HEATHROW via BOVINGDON''==
* The BNN [[STAR]] is for flights arriving from the north (eg X atlantic flights)
* The [http://en.wikipedia.org/wiki/Bovingdon_stack Bovingdon Stack] over the '''BNN''' vor, ready for '''Initial Approach''' to Heathrow. '''BNN''' is about 30km north off Heathrow and also the '''LON''' vor transmitter.
There are three simplified STAR's shown below followed by general info:

'''BNN 4A''' - yellow
BNN 4A Arrival via L10 (FL190 & below), N615 (FL90 to FL140) to HON VOR continue on HON VOR R142 to TOBID
then SOPIT (FL150 by SOPIT) to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.

'''BNN 1C''' - orange
Arrival via A47 (FL70) to DTY VOR continue on DTY VOR R166 to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.
'''BNN 1E''' in green
From LAM VOR maintain LAM VOR R278 to DONNA then turn right onto inbound holding track 119°M to BNN VOR.
'''General Information'''
1 Standard Routes may be varied at the discretion of ATC.
2 Cross SLPs or 3 min before holding facility at 250KIAS or less.
3 When BNN VOR is out of service the route will be to BOVVA, see AD 2-EGLL-7-4.
4 En-route holding at HON VOR: During periods of congestion in the London TMA traffic
from the north may be required to hold at HON VOR.
5 As lowest level in BNN holding stack (7000) is above transition altitude, aircraft
will be instructed by ATC to fly at the appropriate flight level.

[[File:Ac002 STAR egll BNN.jpeg]]

===BNN 4A with comment===
BNN 4A Arrival via L10 (FL190 & below), N615 (FL90 to FL140) to HON VOR continue on HON VOR R142 to TOBID
then SOPIT (FL150 by SOPIT) to WCO NDB then turn left onto BNN VOR R299 to BNN VOR.
* Flight '''ac001''' (787) has passed the '''TOBID''' fix, heading 142, descending and slowing. Needs < 230 knots and at 15,000 by '''SPOIT''' fix ahead, before turn at '''WCO''' to '''BNN''' and [[IAF]].
'''BNN 4A Arrival'''
* '''BNN 4A''' is the "official CAA published name" of this route. It would appear on the "filed" FlightPlan.
'''via L10 (FL190 & below)'''
* '''L10''' is an airway and the leftmost brown line top left.
* The aircraft needs to flying under '''19,000ft''' ('''FL190''')
'''N615 (FL90 to FL140)'''
* '''N615''' is an airway and the middle brown line on the top left
* The aircraft needs to be flying on this leg FL90 and FL140
'''to HON VOR'''
* from either of the arrival routes above, the aircraft needs to cross over Honiley vor transmitter
'''continue on HON VOR R142'''
* then fly away from the transmitter heading south east on the '''142 radial''' which is also the heading
''' to TOBID'''
* '''TOBID''' is a fix on the path
''' then SOPIT (FL150 by SOPIT)'''
* '''SOPIT''' is a fix on the path
* the aircraft needs to be at '''15,000ft''' by this point
'''to WCO NDB'''
* '''Wescott''' is a Non Directional Beacon ([[NDB]]) on '''335'''
* and also the intersection of the '''HON 142''' and '''BNN 299''' radials
'''then turn left onto BNN VOR R299'''
* over Wescott NDB turn left towards the '''299 radial''' from Bovingdon - heading '''119'''
* the speed restriction ahead is '''< 250''' (note 2)
'''to BNN VOR.'''
* The red loop is the Bovington Stack holding point - the bottom of the stack is '''7,000ft''' (note 5)
* keep heading towards the BNN vor station
* BNN is the '''IAP''' (Initial Approach Fix) for EGLL
* The '''BNN''' Initial approach is shown in white

==BNN 4A Cockpit View==
* The [[Autopilot]] is engaged (green '''AP ENG''' top PFD) and commanding the aircraft speed, heading ('''SPD''', '''HNG''', '''ALT''' in green top of PFD).
* The nav display Range ('''R''') is set on the glareshield knob to '''80nm''', displayed left of nav display.
* The intersection of the arrows is around 20nm ahead.
[[File:Ac001 STAR egll BNN cockpit.jpeg]]

===HON vor===
* NAV1 is tuned to the HON vor '''113.65''' and the '''142''' radial.
* On the glareshield the VOR L (ie NAV1) switch is in the up position for display in blue on the nav display.
* On the nav display
** bottom left indicates VOR L is tuned to HON vor
** the Blue dot is the location of the transmitter and the blue arrow shows the 142 radial.
** The aircraft is '''DME 015.7''' (bottom left) from HON, ie 15.7nm away from the transmitter.

===BNN vor===
* NAV2 is tuned to the BNN vor '''113.75''' and the '''299 radial''' (119 heading).
* On the glareshield the VOR R (ie NAV2) switch is in the up position for display in green on nav display.
* On the nav display
** bottom right indicates '''VOR R''' is tuned to BNN vor
** the green dot is the location of the transmitter and the green arrow shows the '''299 radial'''.

===Position===
* The aircraft is heading '''142''', SE towards Wescott NDB.
* The autopilot is commanding the heading (green '''HDG''' top PFD), and heading bug is in nav display in pink.
* WCO ndb is not displayed, but is at the intersection of the HON 142 - BNN 299 radials.
* the '''HON''' vor transmitter is '''15.7nm''' behind displayed bottom left of nav display and top left of PFD.
* the aircraft is slightly off course to the right flying parallel.

===Speed===
* On the [[PFD]] - The green '''SPD''' top left indicates the [[Autopilot]] is commanding the speed. The target speed is '''230''' displayed in purple top left.
* The aircraft is travelling at '''249''' (mach '''.508''') and is slowing down to the '''230''' target. There is a speed restriction ahead of 250.

===Altitude===
* On the [[PFD]] - the green '''ALT''' top right indicates the [[Autopilot]] is commanding Altitude Hold. The target altitude is '''15,000ft''' ('''FL150''') displayed in purple top right.
* The aircraft it as crossing '''16,700ft''', descending at around '''500ft/m''' indicated on the right needle.

User:Ac001/SID Tutorial

2010-06-04T00:55:05Z

Ac001: /* Cockpit View */

{{Ac001-tutorial-navbar}}
=SID Tutorial=
* The map below show the '''Standard Intrument Departure''' ([[SID]]'s) routes from the parallel runways '''27L'''/'''27R''' and '''09L'''/'''09R''' at EGLL London Heathrow.
* The SID's are constantly updated/corrected and have a published expiry time by the CAA. Available from [http://www.nats-uk.ead-it.com/public/index.php%3Foption=com_content&task=blogcategory&id=94&Itemid=143.html NATS here].
* The charts are named by their exit points eg ''WOBUN/BUZAD SID'', ''Midhurst SID'', ''Southampton SID''.
* All the exit points are a VOR station with the exception of the northen most departure '''WOBUN/BUZAD SID''' which are [[Fix]]'s.
* '''Dover/Detling SID''' (red) are identical. '''Detling''' is an exit point, with '''Dover''' vor (off the map SE) added as extra leg.

[[File:Ac003 egll sids map.jpeg]]

=Dover/Detling Departure=
* The '''DVR/DET''' sid route (red above), map shows the two routes from the same runway at EGLL. A SE heading and departure via '''Detling''' and/or '''Dover''' [VOR] transmitter stations.
* '''DET''' and '''DVR''' are within a heavily controlled ATC towards upper airspace leaving London.
* The two paths are from the same runway, '''27L''' and '''09R'''.
* There are [http://en.wikipedia.org/wiki/Cranford_Agreement verbal agreements] in addition to strict Noise Abatement procedures/routings and noise monitoring stations for fines.
* The original document has in bold - '''Do not climb above SID levels until instructed by ATC'''.

===DVR 6J: RWY 09R===
* This is an easterly departure, the route in named '''DVR 6J''' and is for runway '''09R''' takeoff.
* The take off is heading east, then a right turn to a flight path heading south east directly crossing south central London to Dover.
Straight ahead to LON D2, then turn right onto track 123°. At LON D4 turn left to establish on DET VOR R285 by DET D34,
cross DET D29 3000 or above, DET D20 5000 or above, DET D16 at 6000, DET D5 at 6000 to DET VOR, then to DVR VOR.

===DET 2G: RWY27L===
* The route is named '''DET 2G''', a western takeoff from '''27L''' (favoured over 27R for noise).
* After takeoff a 130 degree left turn heading south east, then a left turn east crossing over south London to the DET VOR.
Straight ahead to LON D1,then turn left on to NDB EPM QDM139°,to EPM NDB, 4000 or above(5%),
then(but not before LON D10) DET VOR R273, cross DET D32 5000 or above, DET D29 at 6000, DET D5 at 6000 to DET VOR.
* The SID '''DVR 2G: RWY 27L''' from same runway but Dover exit - has ''''then to DVR VOR'''' appened at end.
* '''DET 2F: RWY 27R''' for the parallel runway is identical with the exception of start: ''''Straight ahead to LON D2'''' accomodating the turn.

[[File:Ac001 SID EGLL DOVER map.jpeg]]

==DET 2G: RWY27L Explained==
'''Straight ahead to LON D1,'''
* climb straight ahead '''270''' ie runway heading
* to a distance '''1nm''' from the '''LON''' vor transmitter behind the aircraft
'''then turn left towards the NDB EPM QDM139°,'''
* make a left climbing turn towards the Epsom [[NDB]] station
* head towards this station at 139 magnetic on compass
'''to EPM NDB, 4000 or above(4.6%),'''
* keep heading for EPM
* climbing to 4000ft or above (a climb angle of greater that 4.6 degrees)
* Flight '''AC001''' on the map is at this stage
''' then (but not before LON D10) DET VOR R273,'''
* when at least '''10nm''' away from '''LON''' transmitter (which is by now north of the aircraft)
* turn left and east into the '''273''' radial from '''Detling''' vor, heading '''93'''
'''cross DET D32 5000 or above,'''
* '''32nm''' away from '''DET''', the aircraft needs to be '''above 5000ft'''
'''DET D29 at 6000,'''
* '''29nm''' from '''DET''' transmitter the aircraft must be at '''6000ft'''
'''DET D5 at 6000 to DET VOR,'''
* '''5nm''' from '''DET''' vor the aircraft must be at '''6000ft'''
* keep heading to the and pass over the '''Detling''' transmitter.

==Cockpit View==
* Flight '''AC001''' (a 787) has taken off from EGLL 27L, is completing a right 131 turn toward EPM NDB and is climbing through 4000ft with Altitude, Heading and Speed under [[Autopilot]] command.
[[File:Ac001 SID EGLL DOVER cockpit.jpeg]]

TODO

User:Ac001/Tutorial Overview

2010-06-04T00:31:41Z

Ac001: /* Pre Flight Briefing */

User:Ac001/Tutorial Overview

2010-06-04T00:29:13Z

Ac001: /* Pre Flight Briefing */

User:Ac001/Tutorial Overview

2010-06-04T00:28:23Z

Ac001: /* Pre Flight Briefing */

Distance measuring equipment

2010-06-04T00:07:44Z

Ac001:

=Distance Measuring Equipment=
A '''DME''' is a transponder-based radio navigation technology that measures distance by timing the propagation delay of VHF or UHF radio signals. [[http://en.wikipedia.org/wiki/Distance_measuring_equipment|Wikipedia]]

* A radio pulse takes around 12.36 microseconds to travel 1 nautical mile (1,852 m) to and from; this is also referred to as a radar-mile.
* The aircraft interrogates the ground transponder with a series of pulse-pairs (interrogations) and, after a precise time delay (typically 50 microseconds), the ground station replies with an identical sequence of reply pulse-pairs.

===Related===
* [[VOR-DME]]

Distance measuring equipment

2010-06-03T23:58:46Z

Ac001: Created page with '=Distance Measuring Equipment= A '''DME''' is a transponder-based radio navigation technology that measures distance by timing the propagation delay of VHF or UHF radio signals. …'