FlightGear wiki - User contributions [en]

Aircraft checklists

2017-05-23T12:44:36Z

Sanhozay: /* External link */

{{infobox subsystem
|image =Aircraft Checklists dialog.jpg
|name = Generic Aircraft Checklists
|started= 03/2010
|description = Centralized checklist management
|status = Under active development as of 05/2015
|maintainers = {{usr|Stuart}}
|developers = * {{usr|Stuart}}
* {{usr|Sanhozay}}
|changelog = * {{Git File History|project=flightgear|sub-project=fgdata|path=/Nasal/checklist.nas}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/gui/dialogs/checklist.xml}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/Aircraft/Generic/autochecklist.nas}}
}}

{{Startup}}
{{Checklists}}

As of version 2.9, [[FlightGear]] can display '''aircraft checklists''' in a standardized way, under Help > Aircraft Checklists.

== Adding checklists ==
To learn more about creating custom checklists, see {{readme file|checklists}} and the [[Cessna 172P]] as the reference implementation. Increasingly, the [[tutorials]] system is also extended such that it may make use of aircraft checklists.

Checklists are situated under <tt>/sim/checklists</tt>. As the checklists may be quite long, it is recommended that they are put in a separate file using the following entry in the <tt>-set.xml</tt> file of the aircraft:

<syntaxhighlight lang="xml">
<checklists include="c172-checklists.xml"/>
</syntaxhighlight>

Each individual checklist is created under a <checklist> XML tag, with the following sub-properties:

* <code><title></code> The name of the checklist
* <code><page></code> One or more pages from the checklist, containing one or more of the following:
** <code><item></code> A checklist item, containing
*** <code><name></code> The item name, to appear on the left hand side of the checklist
*** <code><value></code> One or more values, to appear on the right hand side of the checklist. Second and and subsequent <value> tags are displayed underneath each other. It is recommended that the <value> tags are kept short, to minimize the size of the displayed checklist.
*** <code><condition></code> An optional [[Howto:Animate models#Conditions|condition node]] that evaluates when the checklist item is complete. Incomplete checklist items are shown in yellow, while completed items are shown in green.
*** <code><marker></code> An optional marker node that is used to display a circle around a control when the user clicks a "?" button next to the item. This contains <x-m>, <y-m>, <z-m> and <scale> sub-elements and uses the [[Tutorials#Marker|tutorial marker]]. Note that this requires the marker model to be included in the aircraft model, as explained in the aforementioned article.
*** <code><binding></code> Zero or more XML bindings that are used by the simulator to execute the checklist item if the user clicks on a ">" button next to the item.

For simple checklists the <page> element can be omitted and <item> entries placed directly under the <checklist>.

The following example shows a simple checklists XML file:

<syntaxhighlight lang="xml">
<PropertyList>
<checklist>
<title>After Landing</title>
<item>
<name>Carburetor Heat</name>
<value>COLD</value>
<condition>
<equals>
<property>/controls/anti-ice/engine[0]/carb-heat</property>
<value>0</value>
</equals>
</condition>
<marker>
<x-m>-0.3225</x-m>
<y-m>-0.0850</y-m>
<z-m>-0.2117</z-m>
<scale>2.0500</scale>
</marker>
<binding>
<command>property-assign</command>
<value>0</value>
</binding>
</item>
<item>
<name>Wing Flaps</name>
<value>UP</value>
</item>
</checklist>
<checklist>
<title>Getting hamburger</title>
<page>
<item>
...
</item>
</page>
</checklist>
</PropertyList>
</syntaxhighlight>

See the Cessna 172P for an example of how this all fits together.

=== Bindings ===
[[File:C172p-checklist-via-pui.png|thumb|FlightGear [[Aircraft Checklists]] [[PUI]] dialog]]
One or more [[Bindings|binding elements]] can be added to a checklist item. Conceptually, these are the actions that the user should execute to complete the item. The checklist GUI displays items with such <binding> elements with an additional [>] button. Clicking on the button executes the bindings, allowing the user to watch as the computer/co-pilot/instructor executes the checklist item.

The <binding> element is exactly as you would expect - so property-assign, nasal etc. works.

The plan is to extend this function so that checklists with one or more items containing a <binding> element can have an (optional) button
to execute the entire checklist.

== Reloading checklists ==
Cut and paste this little code snippet in the [[Nasal Console]] and excecute it:

<syntaxhighlight lang="nasal">
var reload_checklist = func(filename) {
var checklist_path=sprintf("%s/%s",getprop("/sim/aircraft-dir"),filename);
var data = io.read_properties(checklist_path,"/sim/checklists");
}

reload_checklist(filename: "777-200-checklists.xml");
</syntaxhighlight>

Change the filename to the name of the file you are editing. Make sure to monitor the startup window and/or the [[Nasal Console]] loglist widget for any XML related warnings (e.g. parsing errors).

== Automated checklist execution ==

As of version 3.5, [[FlightGear]] can automate the execution of various sequences of aircraft checklists using the <tt>autochecklist.nas</tt> script in <tt>$FGDATA/Aircraft/Generic</tt>. The advantage of this approach is that the checklist files become the source of checklists, tutorials and autostart; if the checklists change, so does the autostart (see {{Wikipedia|Don't repeat yourself}}).

The <tt>autochecklist.nas</tt> script can be used to create an autostart menu but is not restricted to autostart; any checklist sequence can be run from any piece of Nasal code.

Automated checklists may not work for more complex aircraft startup sequences, but they are so easy to set up that it's worth trying alongside the development of the aircraft startup process. If it works, great! If it doesn't, you haven't wasted your time because you have at least made a start on your checklists.

=== Background ===

The <tt>autochecklist.nas</tt> script relies on the aircraft having a set of checklists that have complete sets of [[Bindings|bindings]] to take the aircraft from one state to another. For autostart, for example, you need to be able to start the aircraft solely by pressing the binding buttons on the right side of the checklist.

Using the script is a simple three step process involving a few lines of XML and as little as one line of [[Nasal]] code:

# Add the script to your aircraft
# Define one or more named checklist sequences
# Call the script to execute a checklist sequence

For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.

When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the {{readme file|conditions}} associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.

In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.

=== Add the script ===

Add <tt>autochecklist.nas</tt> to the aircraft's <tt>-set.xml</tt> file (or equivalent):

<syntaxhighlight lang="xml">
<nasal>
...
<autochecklist>
<file>Aircraft/Generic/autochecklist.nas</file>
</autochecklist>
</nasal>
</syntaxhighlight>

=== Define checklist sequences ===

In the aircraft's <tt>-set.xml</tt> file, create one or more named checklist sequences that specify ordered lists of checklists to execute. The names can be anything you like as long as they are valid XML tags. The names are never displayed within the simulator.

For example, to run checklists with indexes 0 and 1 for startup and checklist 9 for shutdown:

<syntaxhighlight lang="xml">
<sim>
<checklists>
<checklist include="Checklists/before-starting-engines.xml"/>
<checklist include="Checklists/start-engines.xml"/>

<checklist include="Checklists/parking.xml"/>
<startup>
<index n="0">0</index> 
<index n="1">1</index> 
</startup>
<shutdown>
<index n="0">9</index> 
</startup>
</checklists>
</sim>
</syntaxhighlight>

=== Execute the checklist sequence ===

For the typical usage of autostart, add a Nasal binding as a menu item and execute the named checklist sequence:

<syntaxhighlight lang="xml">
<item>
<label>Autostart</label>
<binding>
<command>nasal</command>
<script>autochecklist.complete_checklists("startup");</script>
</binding>
</item>
</syntaxhighlight>

Obviously, additional logic can be included in the binding if you want the autostart menu to toggle between autostart and shutdown.

==== Fine tuning checklist bindings ====

Sometimes, a checklist binding will do something like display a dialog, e.g. fuel and payload dialog. It would be irritating to the pilot if these things happened during automated execution. These bindings can make use of the <code>sim/checklists/auto/active</code> property, which will be <tt>true</tt> when the checklist binding is being run by the autochecklist script and <tt>false</tt> otherwise.

<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>
var auto = getprop("sim/checklists/auto/active");
if (!auto) gui.showWeightDialog();
</script>
</binding>
</syntaxhighlight>

==== Expedited checklists ====

For in-air start sequences in some aircraft, you can pass zero as the second argument of the <tt>complete_checklists</tt> function to expedite the sequence. All items in the checklist sequence will be executed without waiting for previous items to complete. Note that this means the checklist sequence is never considered to have failed.

<syntaxhighlight lang="nasal">
if (!getprop("gear/gear/wow")) {
autochecklist.complete_checklists(sequence: "in-air-start", wait: 0);
} else {
autochecklist.complete_checklists("ground-start");
}
</syntaxhighlight>

Clearly the checklist sequence used for in-air start should be different from a ground start and should put the aircraft into a flying state, e.g. gear up, flaps up. Bindings can use the property <code>sim/checklists/auto/expedited</code> to check if the execution is expedited, i.e. there is no wait between items. Note that the expedited flag does not in itself indicate whether a binding is being run as part of an automated checklist. You may need to test both the <code>sim/checklists/auto/active</code> and <code>sim/checklists/auto/expedited</code> properties, e.g.

<syntaxhighlight lang="nasal">
var auto = getprop("sim/checklists/auto/active");
var expedited = getprop("sim/checklists/auto/expedited");

if (auto and expedited) {
...
}
</syntaxhighlight>

=== Customizing execution (optional) ===

The behavior of the <tt>autochecklist.nas</tt> script can be customized by setting properties, either in the aircraft's <tt>-set.xml</tt> file or at runtime. Configuration is under the <tt>sim/checklists/auto</tt> node.

<syntaxhighlight lang="xml">
<sim>
<checklists>
...
<auto>
<startup-message>Running checklists, please wait ...</startup-message>
<completed-message>Checklists complete.</completed-message>
<timeout-message>Some checks failed.</timeout-message>
<timeout-sec>10</timeout-sec>
<wait-sec>3</wait-sec>
<auto>
</checklists>
</sim>
</syntaxhighlight>

* <code>startup-message</code> message displayed prior to automated checklist execution
* <code>completed-message</code> message displayed on successful completion of the checklist
* <code>timeout-message</code> message displayed if checklist execution times out waiting for a checklist condition to be satisfied
* <code>timeout-sec</code> if the previous condition is not satisfied within this timeout, the automated execution fails
* <code>wait-sec</code> time to wait before re-checking the status of the previous item if its condition is false after running the binding (effectively a polling interval).

Messages are displayed as copilot announcements (by setting <tt>sim/messages/copilot</tt>). They can be set empty if messages are not required. Note that messages are never displayed for expedited starts.

Care should be taken with the timeout value. This is the timeout for a single item waiting for the previous condition to be satisfied, not the overall timeout for the checklist sequence. If the timeout is set to a large value and conditions cannot be satisfied, the pilot will have to wait a long time for the failure message to appear.

=== Other features and ideas ===

Automated checklist execution is not restricted to autostart and shutdown. If you have an "After Landing" checklist that switches landing lights off, raises flaps and turns taxi lights on, for example, you could assign that to a keyboard shortcut. Rollout and taxi is a busy time on some aircraft and it's often not easy to find the switches and controls necessary to complete this kind of checklist.

To use the <tt>autochecklist.nas</tt> script, pilots need <tt>FGDATA</tt> v3.5 or greater, otherwise the script will not be available. The availability of automated checklists can be tested by checking whether the <tt>sim/checklists/auto</tt> node is nil and a suitable indication given to the pilot if it is nil.

For an example of using automated checklists, refer to the [[Lockheed Constellation]], for which the script was originally written.

== Development ==
the docs for this particular feature are to be found in {{readme file|checklists}}.
This is also where you can read that the c172p is considered the reference implementation.
The system itself is located in {{fgdata source|path=gui/dialogs/checklist.xml|line=18|pre=$FG_ROOT|post=(embedded Nasal)}}, but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=218209#p218209
| title = <nowiki>Re: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Sep 11th, 2014
| added = Sep 11th, 2014
| script_version = 0.25
}}
</ref>

it would be a good idea to localie any custom Nasal blocks, and instead introduce custom fgcommands using the addcommand() API - basically the reason being that there could be an aircraft-specific API using fgcommands for starting engines, instead of having aircraft-specific "Nasal blobs" in each checklist file. A while ago, this was actually discussed on the devel list, too. In other words, an "fgcommand" (implemented in Nasal) would help better isolate checklists from aircraft specifics.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=241259#p241259
| title = <nowiki>Re: Automated Checklist Execution</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = May 1st, 2015
| added = May 1st, 2015
| script_version = 0.25
}}
</ref>

== Checklist Generation Language ==

Forum user sanhozay has created a custom language called [https://github.com/sanhozay/CLGen CLGen] for generating checklists.

The main benefits to be gained from using CLGen are:

* More compact Nasal-like syntax that is easier to work with than XML
* Re-use of item definitions means source code is around 20-25% of the equivalent hand-written XML
* PDF and Graphviz DOT views of the checklists to aid prototyping
* Type checking and code generation means less debugging of checklists in Flightgear

Creating checklists with CLGen can be as simple as:

<pre>
checklist("Startup") {
check("Parking Brake", "ON");
check("Navigation Lights", "ON");
check("Beacon", "OFF");
}</pre>

CLGen supports conditions expressed in Nasal-like syntax, bindings, fgcommands, markers and automated inclusion of copyright headers. It is also possible, with some restrictions, to reverse-engineer existing checklists into CLGen source format and to generate PDF and Graphviz DOT representations of existing checklists.

[[File:CLGen DOT File.png|500px|Example of an image created from CLGen's DOT file output.]]
[[File:CLGen PDF Output.png|300px|Example of a PDF file created from CLGen.]]

CLGen is written in Java and runs on Mac OS, Linux and Windows platforms with a Java 8 runtime.

For more information, including a step-by-step Wiki tutorial, visit the [https://github.com/sanhozay/CLGen CLGen project on Github]

== External link ==
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38325.html Aircraft Checklists] (mailing list)
* [https://sourceforge.net/p/flightgear/mailman/message/33904555/ Automated Checklist Execution] (mailing list)
* [https://forum.flightgear.org/viewtopic.php?f=4&t=32180&p=310216#p310216 CLGen Release Announcement] (forum)

[[Category:Aircraft enhancement]]

Aircraft checklists

2017-05-22T22:53:24Z

Sanhozay: Add notes for anyone interested in using sanhozay's CLGen DSL for generating checklist XML files.

File:CLGen PDF Output.png

2017-05-22T22:40:09Z

Sanhozay: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Example of a PDF file created from CLGen.}}
|date=2017-05-22
|source={{own}}
|author=[[User:Sanhozay|Sanhozay]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

File:CLGen DOT File.png

2017-05-22T22:37:53Z

Sanhozay: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Example of an image created from CLGen's DOT file output.}}
|date=2017-05-22
|source={{own}}
|author=[[User:Sanhozay|Sanhozay]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

User:Sanhozay

2017-05-22T22:24:16Z

Sanhozay:

== User ==

=== Favourite Airports ===

Some of my more obscure favourite airports ...

==== [http://skyvector.com/airport/LDDU/Dubrovnik-Cilipi-Airport Dubrovnic, Croatia] ====

Dubrovnic Cilipi airport is set on a coastal hill, separated from Dubrovnic by a bay. The airport is 527ft above sea level and landing on it is a little like landing on a table top. Approaches along the coastline in either direction are attractive, with mountain ranges and small islands along the way.

Recommended aircraft: At 10827ft, the runway will take anything but to appreciate the scenery, low and slow is preferable. Try flying from Venice (LIPZ) or Split (LDZD from the north, or Ohrid (LOWH) or Athens (LGAV) from the south.

==== [http://skyvector.com/airport/BIIS/Isafjordur-Airport Isafjordur, Iceland] ====

The approach to this small airport, set in a fjord in the north-west of Iceland, is nothing short of spectacular. The most exciting approach is runway 26, which involves skirting the northern flanks of the fjord, then timing a 180° left turn over a spur running from a mountain at the end of the fjord to arrive at the threshold. Runway 08 might not be quite so spectacular but is still not straightforward; skirt the southern flanks of the fjord and approach the threshold at an angle with a late turn to line up.

Isafjordur is about 120nm north of Reykjavik which makes for a pleasant trip of less than an hour, and lots of opportunities to practice NDB navigation.

Recommended aircraft: any small to medium-sized propeller aircraft, e.g. Douglas DC3, De Havilland DHC2, De Havilland DHC6, Fokker 50.

=== Classic Routes ===

==== [http://skyvector.com/?ll=26.64144415704356,99.96775819628236&chart=301&zoom=3&plan=A.VE.VECA:N.VY.PT:A.ZP.ZPLJ:A.ZP.ZPPP The Hump] ====

The Hump was a famous supply route from Assam, India to Kunming, China during WWII. This is my best approximation of the route from historical maps but note that the pilots who flew it didn't have the benefit of the NDBs. It was an extremely hazardous route, mostly due to weather conditions, with almost 600 aircraft lost attempting to fly it.

Recommended aircraft: Douglas DC3/C47 (3h). Advanced weather, turbulence on full. Snowline set less than 4000m.

==== [http://skyvector.com/?ll=53.21803962665041,11.393646252216126&chart=301&zoom=5&plan=A.ED.EDHL:N.ED.LYE:F.ED.RARUP:V.ED.BKD:G.52.66888759567344,12.757598889020937:N.ED.RW:A.ED.EDDT:N.ED.RW:N.ED.BRU:A.ED.EDHG:V.ED.HAM:A.ED.EDHL Berlin Airlift (British Sector)] ====

This is my best approximation of the Berlin airlift route flown from the British sector and, from a navigational point of view is more interesting than the US sector route below.

Notes: depart visual south to Mölln before turning left on a track of 137° to Brunkendorf. Turn left on a track of 114° to Tegel West NDB (RW) and make a straight in approach to runway 26 or enter the pattern for runway 08. Remember that there is no go around because of the queue of aircraft behind you. If you miss your approach, you get to fly back to Lubeck! For the return leg, track 261° to the west, turning right to track 354° at Braunschweig. Use dead reconking to identify Luneburg airfield before turning left on a track of 340° to Hamburg VOR (HAM). A right turn onto 067° returns you in line with runway 07 at Lubeck. If the wind dictates runway 25, enter the pattern to land.

Recommended aircraft: Douglas DC3/C47 (2h), Lockheed Constellation (1h15). For realism, use VORs as NDBs, i.e. ignore the CDI.
==== [http://skyvector.com/?ll=52.01351431726475,11.716918957314629&chart=301&zoom=6&plan=A.ED.ETOU:V.ED.VFM:V.ED.CHA:V.ED.FUL:N.ED.MW:A.ED.EDDB:N.ED.MW:N.ED.DLE:N.ED.FTZ:A.ED.ETOU Berlin Airlift (US Sector)] ====

This US sector route is less interesting than the British sector route, only because it contains longer straight sections.

Notes: Depart Wiesbaden direct Mauhelm VOR (VFM) and then direct to Charlie VOR (CHA). Turn left on a track of 026° to Fulda VOR (FUL). Turn right on a track of 052° to Berlin NDB (MW) and make a straight in approach to runway 07 or enter the pattern for runway 25. Return to the west on a track of 267° to Leine NDB (DLE) and turn left on a track of 195° to Fritzlar NDB (FTZ). Follow a track of 212° to Wiesbaden NDB (WBD) and enter the pattern to land.

Recommended Aircraft: Lockheed Constellation (2h).

User:Sanhozay

2017-05-22T22:23:53Z

Sanhozay:

== User ==

=== Favourite Aircraft ===

=== Favourite Airports ===

Some of my more obscure favourite airports ...

==== [http://skyvector.com/airport/LDDU/Dubrovnik-Cilipi-Airport Dubrovnic, Croatia] ====

Dubrovnic Cilipi airport is set on a coastal hill, separated from Dubrovnic by a bay. The airport is 527ft above sea level and landing on it is a little like landing on a table top. Approaches along the coastline in either direction are attractive, with mountain ranges and small islands along the way.

Recommended aircraft: At 10827ft, the runway will take anything but to appreciate the scenery, low and slow is preferable. Try flying from Venice (LIPZ) or Split (LDZD from the north, or Ohrid (LOWH) or Athens (LGAV) from the south.

==== [http://skyvector.com/airport/BIIS/Isafjordur-Airport Isafjordur, Iceland] ====

The approach to this small airport, set in a fjord in the north-west of Iceland, is nothing short of spectacular. The most exciting approach is runway 26, which involves skirting the northern flanks of the fjord, then timing a 180° left turn over a spur running from a mountain at the end of the fjord to arrive at the threshold. Runway 08 might not be quite so spectacular but is still not straightforward; skirt the southern flanks of the fjord and approach the threshold at an angle with a late turn to line up.

Isafjordur is about 120nm north of Reykjavik which makes for a pleasant trip of less than an hour, and lots of opportunities to practice NDB navigation.

Recommended aircraft: any small to medium-sized propeller aircraft, e.g. Douglas DC3, De Havilland DHC2, De Havilland DHC6, Fokker 50.

=== Classic Routes ===

==== [http://skyvector.com/?ll=26.64144415704356,99.96775819628236&chart=301&zoom=3&plan=A.VE.VECA:N.VY.PT:A.ZP.ZPLJ:A.ZP.ZPPP The Hump] ====

The Hump was a famous supply route from Assam, India to Kunming, China during WWII. This is my best approximation of the route from historical maps but note that the pilots who flew it didn't have the benefit of the NDBs. It was an extremely hazardous route, mostly due to weather conditions, with almost 600 aircraft lost attempting to fly it.

Recommended aircraft: Douglas DC3/C47 (3h). Advanced weather, turbulence on full. Snowline set less than 4000m.

==== [http://skyvector.com/?ll=53.21803962665041,11.393646252216126&chart=301&zoom=5&plan=A.ED.EDHL:N.ED.LYE:F.ED.RARUP:V.ED.BKD:G.52.66888759567344,12.757598889020937:N.ED.RW:A.ED.EDDT:N.ED.RW:N.ED.BRU:A.ED.EDHG:V.ED.HAM:A.ED.EDHL Berlin Airlift (British Sector)] ====

This is my best approximation of the Berlin airlift route flown from the British sector and, from a navigational point of view is more interesting than the US sector route below.

Notes: depart visual south to Mölln before turning left on a track of 137° to Brunkendorf. Turn left on a track of 114° to Tegel West NDB (RW) and make a straight in approach to runway 26 or enter the pattern for runway 08. Remember that there is no go around because of the queue of aircraft behind you. If you miss your approach, you get to fly back to Lubeck! For the return leg, track 261° to the west, turning right to track 354° at Braunschweig. Use dead reconking to identify Luneburg airfield before turning left on a track of 340° to Hamburg VOR (HAM). A right turn onto 067° returns you in line with runway 07 at Lubeck. If the wind dictates runway 25, enter the pattern to land.

Recommended aircraft: Douglas DC3/C47 (2h), Lockheed Constellation (1h15). For realism, use VORs as NDBs, i.e. ignore the CDI.
==== [http://skyvector.com/?ll=52.01351431726475,11.716918957314629&chart=301&zoom=6&plan=A.ED.ETOU:V.ED.VFM:V.ED.CHA:V.ED.FUL:N.ED.MW:A.ED.EDDB:N.ED.MW:N.ED.DLE:N.ED.FTZ:A.ED.ETOU Berlin Airlift (US Sector)] ====

This US sector route is less interesting than the British sector route, only because it contains longer straight sections.

Notes: Depart Wiesbaden direct Mauhelm VOR (VFM) and then direct to Charlie VOR (CHA). Turn left on a track of 026° to Fulda VOR (FUL). Turn right on a track of 052° to Berlin NDB (MW) and make a straight in approach to runway 07 or enter the pattern for runway 25. Return to the west on a track of 267° to Leine NDB (DLE) and turn left on a track of 195° to Fritzlar NDB (FTZ). Follow a track of 212° to Wiesbaden NDB (WBD) and enter the pattern to land.

Recommended Aircraft: Lockheed Constellation (2h).

Aircraft checklists

2017-05-22T22:22:30Z

Sanhozay:

{{infobox subsystem
|image =Aircraft Checklists dialog.jpg
|name = Generic Aircraft Checklists
|started= 03/2010
|description = Centralized checklist management
|status = Under active development as of 05/2015
|maintainers = {{usr|Stuart}}
|developers = * {{usr|Stuart}}
* {{usr|Sanhozay}}
|changelog = * {{Git File History|project=flightgear|sub-project=fgdata|path=/Nasal/checklist.nas}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/gui/dialogs/checklist.xml}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/Aircraft/Generic/autochecklist.nas}}
}}

{{Startup}}
{{Checklists}}

As of version 2.9, [[FlightGear]] can display '''aircraft checklists''' in a standardized way, under Help > Aircraft Checklists.

== Adding checklists ==
To learn more about creating custom checklists, see {{readme file|checklists}} and the [[Cessna 172P]] as the reference implementation. Increasingly, the [[tutorials]] system is also extended such that it may make use of aircraft checklists.

Checklists are situated under <tt>/sim/checklists</tt>. As the checklists may be quite long, it is recommended that they are put in a separate file using the following entry in the <tt>-set.xml</tt> file of the aircraft:

<syntaxhighlight lang="xml">
<checklists include="c172-checklists.xml"/>
</syntaxhighlight>

Each individual checklist is created under a <checklist> XML tag, with the following sub-properties:

* <code><title></code> The name of the checklist
* <code><page></code> One or more pages from the checklist, containing one or more of the following:
** <code><item></code> A checklist item, containing
*** <code><name></code> The item name, to appear on the left hand side of the checklist
*** <code><value></code> One or more values, to appear on the right hand side of the checklist. Second and and subsequent <value> tags are displayed underneath each other. It is recommended that the <value> tags are kept short, to minimize the size of the displayed checklist.
*** <code><condition></code> An optional [[Howto:Animate models#Conditions|condition node]] that evaluates when the checklist item is complete. Incomplete checklist items are shown in yellow, while completed items are shown in green.
*** <code><marker></code> An optional marker node that is used to display a circle around a control when the user clicks a "?" button next to the item. This contains <x-m>, <y-m>, <z-m> and <scale> sub-elements and uses the [[Tutorials#Marker|tutorial marker]]. Note that this requires the marker model to be included in the aircraft model, as explained in the aforementioned article.
*** <code><binding></code> Zero or more XML bindings that are used by the simulator to execute the checklist item if the user clicks on a ">" button next to the item.

For simple checklists the <page> element can be omitted and <item> entries placed directly under the <checklist>.

The following example shows a simple checklists XML file:

<syntaxhighlight lang="xml">
<PropertyList>
<checklist>
<title>After Landing</title>
<item>
<name>Carburetor Heat</name>
<value>COLD</value>
<condition>
<equals>
<property>/controls/anti-ice/engine[0]/carb-heat</property>
<value>0</value>
</equals>
</condition>
<marker>
<x-m>-0.3225</x-m>
<y-m>-0.0850</y-m>
<z-m>-0.2117</z-m>
<scale>2.0500</scale>
</marker>
<binding>
<command>property-assign</command>
<value>0</value>
</binding>
</item>
<item>
<name>Wing Flaps</name>
<value>UP</value>
</item>
</checklist>
<checklist>
<title>Getting hamburger</title>
<page>
<item>
...
</item>
</page>
</checklist>
</PropertyList>
</syntaxhighlight>

See the Cessna 172P for an example of how this all fits together.

=== Bindings ===
[[File:C172p-checklist-via-pui.png|thumb|FlightGear [[Aircraft Checklists]] [[PUI]] dialog]]
One or more [[Bindings|binding elements]] can be added to a checklist item. Conceptually, these are the actions that the user should execute to complete the item. The checklist GUI displays items with such <binding> elements with an additional [>] button. Clicking on the button executes the bindings, allowing the user to watch as the computer/co-pilot/instructor executes the checklist item.

The <binding> element is exactly as you would expect - so property-assign, nasal etc. works.

The plan is to extend this function so that checklists with one or more items containing a <binding> element can have an (optional) button
to execute the entire checklist.

== Reloading checklists ==
Cut and paste this little code snippet in the [[Nasal Console]] and excecute it:

<syntaxhighlight lang="nasal">
var reload_checklist = func(filename) {
var checklist_path=sprintf("%s/%s",getprop("/sim/aircraft-dir"),filename);
var data = io.read_properties(checklist_path,"/sim/checklists");
}

reload_checklist(filename: "777-200-checklists.xml");
</syntaxhighlight>

Change the filename to the name of the file you are editing. Make sure to monitor the startup window and/or the [[Nasal Console]] loglist widget for any XML related warnings (e.g. parsing errors).

== Automated checklist execution ==

As of version 3.5, [[FlightGear]] can automate the execution of various sequences of aircraft checklists using the <tt>autochecklist.nas</tt> script in <tt>$FGDATA/Aircraft/Generic</tt>. The advantage of this approach is that the checklist files become the source of checklists, tutorials and autostart; if the checklists change, so does the autostart (see {{Wikipedia|Don't repeat yourself}}).

The <tt>autochecklist.nas</tt> script can be used to create an autostart menu but is not restricted to autostart; any checklist sequence can be run from any piece of Nasal code.

Automated checklists may not work for more complex aircraft startup sequences, but they are so easy to set up that it's worth trying alongside the development of the aircraft startup process. If it works, great! If it doesn't, you haven't wasted your time because you have at least made a start on your checklists.

=== Background ===

The <tt>autochecklist.nas</tt> script relies on the aircraft having a set of checklists that have complete sets of [[Bindings|bindings]] to take the aircraft from one state to another. For autostart, for example, you need to be able to start the aircraft solely by pressing the binding buttons on the right side of the checklist.

Using the script is a simple three step process involving a few lines of XML and as little as one line of [[Nasal]] code:

# Add the script to your aircraft
# Define one or more named checklist sequences
# Call the script to execute a checklist sequence

For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.

When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the {{readme file|conditions}} associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.

In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.

=== Add the script ===

Add <tt>autochecklist.nas</tt> to the aircraft's <tt>-set.xml</tt> file (or equivalent):

<syntaxhighlight lang="xml">
<nasal>
...
<autochecklist>
<file>Aircraft/Generic/autochecklist.nas</file>
</autochecklist>
</nasal>
</syntaxhighlight>

=== Define checklist sequences ===

In the aircraft's <tt>-set.xml</tt> file, create one or more named checklist sequences that specify ordered lists of checklists to execute. The names can be anything you like as long as they are valid XML tags. The names are never displayed within the simulator.

For example, to run checklists with indexes 0 and 1 for startup and checklist 9 for shutdown:

<syntaxhighlight lang="xml">
<sim>
<checklists>
<checklist include="Checklists/before-starting-engines.xml"/>
<checklist include="Checklists/start-engines.xml"/>

<checklist include="Checklists/parking.xml"/>
<startup>
<index n="0">0</index> 
<index n="1">1</index> 
</startup>
<shutdown>
<index n="0">9</index> 
</startup>
</checklists>
</sim>
</syntaxhighlight>

=== Execute the checklist sequence ===

For the typical usage of autostart, add a Nasal binding as a menu item and execute the named checklist sequence:

<syntaxhighlight lang="xml">
<item>
<label>Autostart</label>
<binding>
<command>nasal</command>
<script>autochecklist.complete_checklists("startup");</script>
</binding>
</item>
</syntaxhighlight>

Obviously, additional logic can be included in the binding if you want the autostart menu to toggle between autostart and shutdown.

==== Fine tuning checklist bindings ====

Sometimes, a checklist binding will do something like display a dialog, e.g. fuel and payload dialog. It would be irritating to the pilot if these things happened during automated execution. These bindings can make use of the <code>sim/checklists/auto/active</code> property, which will be <tt>true</tt> when the checklist binding is being run by the autochecklist script and <tt>false</tt> otherwise.

<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>
var auto = getprop("sim/checklists/auto/active");
if (!auto) gui.showWeightDialog();
</script>
</binding>
</syntaxhighlight>

==== Expedited checklists ====

For in-air start sequences in some aircraft, you can pass zero as the second argument of the <tt>complete_checklists</tt> function to expedite the sequence. All items in the checklist sequence will be executed without waiting for previous items to complete. Note that this means the checklist sequence is never considered to have failed.

<syntaxhighlight lang="nasal">
if (!getprop("gear/gear/wow")) {
autochecklist.complete_checklists(sequence: "in-air-start", wait: 0);
} else {
autochecklist.complete_checklists("ground-start");
}
</syntaxhighlight>

Clearly the checklist sequence used for in-air start should be different from a ground start and should put the aircraft into a flying state, e.g. gear up, flaps up. Bindings can use the property <code>sim/checklists/auto/expedited</code> to check if the execution is expedited, i.e. there is no wait between items. Note that the expedited flag does not in itself indicate whether a binding is being run as part of an automated checklist. You may need to test both the <code>sim/checklists/auto/active</code> and <code>sim/checklists/auto/expedited</code> properties, e.g.

<syntaxhighlight lang="nasal">
var auto = getprop("sim/checklists/auto/active");
var expedited = getprop("sim/checklists/auto/expedited");

if (auto and expedited) {
...
}
</syntaxhighlight>

=== Customizing execution (optional) ===

The behavior of the <tt>autochecklist.nas</tt> script can be customized by setting properties, either in the aircraft's <tt>-set.xml</tt> file or at runtime. Configuration is under the <tt>sim/checklists/auto</tt> node.

<syntaxhighlight lang="xml">
<sim>
<checklists>
...
<auto>
<startup-message>Running checklists, please wait ...</startup-message>
<completed-message>Checklists complete.</completed-message>
<timeout-message>Some checks failed.</timeout-message>
<timeout-sec>10</timeout-sec>
<wait-sec>3</wait-sec>
<auto>
</checklists>
</sim>
</syntaxhighlight>

* <code>startup-message</code> message displayed prior to automated checklist execution
* <code>completed-message</code> message displayed on successful completion of the checklist
* <code>timeout-message</code> message displayed if checklist execution times out waiting for a checklist condition to be satisfied
* <code>timeout-sec</code> if the previous condition is not satisfied within this timeout, the automated execution fails
* <code>wait-sec</code> time to wait before re-checking the status of the previous item if its condition is false after running the binding (effectively a polling interval).

Messages are displayed as copilot announcements (by setting <tt>sim/messages/copilot</tt>). They can be set empty if messages are not required. Note that messages are never displayed for expedited starts.

Care should be taken with the timeout value. This is the timeout for a single item waiting for the previous condition to be satisfied, not the overall timeout for the checklist sequence. If the timeout is set to a large value and conditions cannot be satisfied, the pilot will have to wait a long time for the failure message to appear.

=== Other features and ideas ===

Automated checklist execution is not restricted to autostart and shutdown. If you have an "After Landing" checklist that switches landing lights off, raises flaps and turns taxi lights on, for example, you could assign that to a keyboard shortcut. Rollout and taxi is a busy time on some aircraft and it's often not easy to find the switches and controls necessary to complete this kind of checklist.

To use the <tt>autochecklist.nas</tt> script, pilots need <tt>FGDATA</tt> v3.5 or greater, otherwise the script will not be available. The availability of automated checklists can be tested by checking whether the <tt>sim/checklists/auto</tt> node is nil and a suitable indication given to the pilot if it is nil.

For an example of using automated checklists, refer to the [[Lockheed Constellation]], for which the script was originally written.

== Development ==
the docs for this particular feature are to be found in {{readme file|checklists}}.
This is also where you can read that the c172p is considered the reference implementation.
The system itself is located in {{fgdata source|path=gui/dialogs/checklist.xml|line=18|pre=$FG_ROOT|post=(embedded Nasal)}}, but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=218209#p218209
| title = <nowiki>Re: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Sep 11th, 2014
| added = Sep 11th, 2014
| script_version = 0.25
}}
</ref>

it would be a good idea to localie any custom Nasal blocks, and instead introduce custom fgcommands using the addcommand() API - basically the reason being that there could be an aircraft-specific API using fgcommands for starting engines, instead of having aircraft-specific "Nasal blobs" in each checklist file. A while ago, this was actually discussed on the devel list, too. In other words, an "fgcommand" (implemented in Nasal) would help better isolate checklists from aircraft specifics.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=241259#p241259
| title = <nowiki>Re: Automated Checklist Execution</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = May 1st, 2015
| added = May 1st, 2015
| script_version = 0.25
}}
</ref>

== Checklist Generation Language ==

== External link ==
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38325.html Aircraft Checklists] (mailing list)
* [https://sourceforge.net/p/flightgear/mailman/message/33904555/ Automated Checklist Execution] (mailing list)

[[Category:Aircraft enhancement]]

Navdata cache

2017-03-18T17:34:55Z

Sanhozay: /* Fixed the note at the top */

{{Out of date}}
{{See also|Fgfs.pid}}

{{Note|On Windows, versions of Flightgear up to 2017.1.1 can have problems restarting if the simulator did not close normally the last time it ran. Typically the error message suggests that there is a problem with a read-only navigation data cache. In fact, the underlying problem is the failure of a previous run to delete a status file. Flightgear then assumes that another instance of the program is running and it makes the [[$FG_HOME]] directory read-only.

The solution is to delete the <code>fgfs.pid</code> file from [[$FG_HOME]] and restart Flightgear. It should '''not''' be necessary to delete any other files or directories.}}

[[File:Fghome-3.7.png|400px|right|Screen shot showing structure of [[$FG_HOME]]]]
[[File:Navcache-schema.png|right|400px|Screen shot showing the SQLite3 schema of the nav cache using a GUI SQLite database editor]]

The '''navdata cache''', '''navdb''', (sometimes also '''navcache''') is automatically built by FlightGear during startup by parsing/processing the gzipped <code>nav.dat</code> file and building a spatial SQLite-based database in [[$FG_HOME]] so that more efficient queries can be run at run-time, but, in particular when starting up/[[Reset & re-init|re-initializing FlightGear]]. Memory consumption is also lower, since we don't keep airports / fixes / taxiways / runways in memory until they're needed.

This feature have been available since [[Changelog 2.10|FlightGear 2.10]] released in February 2013.

== Background ==
[[File:Navcache.png|thumb|Screen shot showing several navcache (SQLite) files in $FG_HOME for various fgfs versions]]

We need a lot of data ''available'' at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling ''availability'' from ''loading''.

== Cache initialization ==
Usually, the navdb will only be compiled once during the first start of the simulator - however, some changes may require rebuilding the cache on disk (see below for details).

Touching the navdata files will cause a rebuild, so rebuilds need to take a 'reasonable' amount of time. Shipping the binary data improves first-launch
perceptions, but many applications do additional work on their first launch after an install, so it's not a top concern for the time being.

When the scenery paths change, we have to rebuild, because Airports XML data (from the <code><scenery>/Airports/</code> tree) is overlaid into the cache, replacing the data from <code>apt.dat</code>. This means when the search paths or order changes, we have to completely rebuild, because there's no way to restore the unmodified (prior to XML overlay) version.

{{FGCquote
|we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

Zakalawe considers the time and fragility to implement such a system much greater than the impact of a rebuild when switching scenery paths, which most people don't do very often.

The rebuild is purely a CPU / disk-bound operation, and for most people, it takes around 60 sec for debug and 30 sec for release times for a complete rebuild. (That time will be dramatically reduced if we get the taxiway data out of <code>apt.dat</code> in the future, since taxiways account for >80% of the lines in the file).

Usually the navdb should be under 200 MB and normally even a rebuild should not take much longer than a few minutes. However, on some platforms/OS the navdb rebuild is known to take exceptionally long, which seems to affect mainly Windows users - some of whom have reported the navcache rebuild taking more than 30 minutes.

== Technical details ==
[[File:Sqliteman-showing-navcache.png|right|400px|sqliteman (Qt based) showing navcache view]]

The nav-cache is versioned, it will be wiped when the cache schema version changes, but right now it’s not wiped when the flightgear version does.

The DB schema version is tracked internally in the file, and if the schema changes during a development version (3.3 or whatever) it will force a drop and rebuild.

The naming scheme is why the first run of a new stable release of FG always does a cache rebuild - which means you can run stable and dev versions side by side without continual cache rebuilds of course.

we /do/ also run a Sqlite verification check on the DB at launch time - this should catch many kinds of file-/index- level corruption (bad commit, etc), and in any case where we detect an issue, the solution is again to drop the cache and rebuild.

The internal format of the cache (for example the fact it's a SQL DB) is deliberately opaque. There are no guarantees made about the format of the file, the SQL scheme or anything. There is a version field of course, and we're not planning or expecting any changes, but we really don't want to be tied to the current scheme if we discover problems or want to add something else in the future.

The cache is stored in <code>[[$FG_HOME]]/navdata.cache</code>, and is rebuilt if the timestamps on any of the data files change (<code>apt.dat</code>, <code>nav.dat</code>, <code>fix.dat</code> and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is ''much'' faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead.

== Troubleshooting ===

{{Note|
A copy of your navdata.cache would be appreciated (the broken one), since of the two copies James was sent so far, neither were corrupted - they both passed the SQLite integrity check.
This has led James to think the issue is permissions, not corruption of the DB. Of course, there could be multiple issues. If you can find the suspect navcache, please upload it to: [https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW] and let James know.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=304747#p304747
|title = <nowiki> Re: sql: attempt to write a read only database </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Feb 3rd, 2017
|added = Feb 3rd, 2017
|script_version = 0.40
}}</ref>

}}

== Known issues ==

{{Note| See also these bug reports:
* {{Issue|1166}}
* {{Issue|894}}
* {{Issue|1398}}
* {{Issue|1774}}
}}

The whole navdb build thing is proving to be the single most problematic feature added in the last couple of years affecting potentially all users, because unlike most additions, it's not an optional thing, i.e. it must be executed, and is needed for FG to work - given that, it would really make sense exploring to ship a pre-built navdb with future FlightGear releases, or at least factor out the corresponding code so that it can be provided as a standalone executable that is shipped as part of fgfs, so that it can be executed by the installer, without fgfs being affected by it inevitably - that way, troubleshooting related issues should also become much easier, in addition, this separation would facilitate having sync'ed navdbs across multiple instances (think virtual ATC, multiplayer, combat simulation, or even just a fsweekend/linuxTag-like setup).

This work would also greatly facilitate turning the navdb into a HLA/IPC-enabled service one day.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293128#p293128
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 25th, 2016
|added = Aug 25th, 2016
|script_version = 0.40
}}</ref>

all startup/repositioning logic needs navdb access - otherwise, it would be possible to also make the whole system optional during startup/runtime, i.e. via some kind of property, so that people could opt-out until certain issues are addressed.
Obviously, that would break any conventional radio-navigation equipped aircraft, but also interactive mapping/charting avionics/dialogs, so may not be desirable ...
Anyway, moving the navdb build into the release process should be possible, and would help address this, until the underlying C++ code has been ironed out<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293203#p293203
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2016
|added = Aug 26th, 2016
|script_version = 0.40
}}</ref>

Unfortunately the cache must be regenerated each time you change scenery paths. So you cannot pre-build it. Recent changes to remove dynamic airports from it should help significantly, but it needs to be made more fail-safe.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293224#p293224
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> bugman </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

the issue has been around for so long, it would be better to recognie that the system needs to be separated/split up, so that a pre-built database can be provided, or so that a central navdb "service" (server) can be used - that way, it could still be a separate executable that doesn't cripple the fgfs experience for >= ~25% of our newcomers
The whole thing started out as a navdb after all, there is no reason why we should be adding so many inter-dependencies to it until some of the key problems have been solved.
Besides, this isn't the first time that fgfs had a cached navdb layer (anybody here remember the original metakit implementation from the early 2000s?)
In its current form, this whole feature contributes to the majority of bug reports, and actual crashes, and is causing tons of support threads on the forum.
Thus, it would definitely make sense to review what's there currently, and see if some things can be changed/re-implemented to make this a less critical feature<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293256#p293256
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

=== Windows Issues ===
As as we know, it's a Windows-specific issue related to SQLite and/or the way $FG_HOME works on Windows: http://wiki.flightgear.org/$FG_HOME
Most core developers, as well as most people who regularly build from source, are using non-Windows OS, i.e. are UNIX-based (MacOS/Linux etc), where the problem usually doesn't show up at all, which makes it hard to reproduce for people able to troubleshoot these things. And unfortunately, we don't really have any Windows-based core developers remaining - the main guy who would handle such compatibility issues on Windows used to be FredB who hasn't been seen in quite a while - and the main guy behind the navcache/navdb is also a Mac user, so not in a good position to reproduce these things, absent some complex VM setup.

Thus, if you are in any position to provide additional feedback/info using development tools (e.g. a debugger) that would indeed be very helpful.
For now, it is even clear if this is related to the location of $FG_HOME on Windows (which has recently changed AFAIK), or if it's related to SQLite itself.
Personally, I've been able to reproduce a handful of SQLite related issues - but I found those difficult to troubleshoot due to the way SQLite is used by FlightGear, i.e. without any logging support/options being exposed currently.

In general, the SQLite-navdb is a great idea - but in practice, it's been crippling FlightGear quite severely since the day it's been added for a number of users, especially those on Windows - simply because we're getting very little action-able feedback/community support, and core contributors who regularly build from source are usually not able to reproduce these issues, while also typically not being very familiar with potential Windows-level issues.

Again, it would really help to file an issue for this - or at least add to any existing (open) ones to raise some awareness of this, and hopefully help improve the situation over time.

{{FGCquote
|1= I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=228533#p228533
| title = <nowiki>Re: FATAL ERROR</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Dec 31st, 2014
| added = Dec 31st, 2014
| script_version = 0.25
}}
}}

=== Read only database ===
On Windows, versions of Flightgear up to 2017.1.1 can have problems restarting if the simulator did not close normally. This usually results in a message about a readonly database, e.g.

* <code>Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge</code>
* <code>Sqlite error : attempt to write a readonly database</code>

The solution is to delete the <code>fgfs.pid</code> file from the [[$FG_HOME]] directory.

Note that this was a long-standing bug and the established solution was to delete the whole [[$FG_HOME]] directory. Although this works, it should '''not''' be necessary to fix the problem; deleting the <code>fgfs.pid</code> file should allow Flightgear to start.

The root cause of the problem should be fixed in Flightgear 2017.1.2.

=== Corruption due to crashes ===
The navcache also seems to get corrupted during segfaults/crashes, especially on Windows, but more recently also on OSX:

{{FGCquote
|1= Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=250389#p250389
| title = <nowiki>Sqlite error</nowiki>
| author = <nowiki>daniel36</nowiki>
| date = Jul 9th, 2015
}}
}}

{{FGCquote
|at least on my 10.7 build, I’m seeing an issue with the nav-cache not initialising. This is actually good, because it gives me a way, finally, to trace down the ‘nav-cache never initialises’ bug that some folks have reported. But it will take a little time. Since the same binary works perfectly on my 10.10 box, I assume it’s something /very/ subtle, probably uninitialised memory or some tiny change in zlib’s gzread functions (since we use the system Zlib library which hence could be different between 10.7 and 10.10).
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33457470/
|title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-18</nowiki>
}}
}}

{{FGCquote
|I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=228533#p228533
|title=<nowiki>Re: FATAL ERROR</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Dec 31</nowiki>
}}
}}

== High Level Architecture ==
{{Main article|High-Level Architecture}}
{{FGCquote
|1= we'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34725710/
| title = <nowiki>[Flightgear-devel] HLA Update</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Dec 29th, 2015
| added = Dec 29th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= I'm looking forward to some feedback and Python code from Jean-Paul to start working on a NavDataCache interface, to create a 'nav_data_cache' or 'navdb' Python C/C++ module. I also had the idea of running this subsystem in a thread. This avoids adding more strain to the main loop, making FGPythonSys even more inconspicuous.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34798001/
| title = <nowiki>Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem.</nowiki>
| author = <nowiki>Edward d'Auvergne</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}
{{FGCquote
|1= it would be possibly to deprecate virtually all the custom Nasal APIs in favour of commands, but much harder to do that solely using properties. (Think about searching the NavDB or appending a waypoint to a flightplan). If we started moving in that direction, we don’t need to create separate APIs for multiple languages, they simply work using the properties + commands system, and the command system already has the exact set of property modification operations you proposed.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34795592/
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...)</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= it would conceptually be the right thing to do to turn the navdb/positioned stuff into a "client/server" subsystem where the navdb acts as a server that can handle client-requests asynchronously. The funny thing is that SQLite itself is obviously based on the whole "server-less" notion.

From a design standpoint, the NavDB is basically an "environmental" subsystem, i.e. heavily reliant on the underlying terrain/scenery because it provides navaids - thus, in a distributed/MP setup it would actually make sense for multi-instance setups to query the same DB to replicate/sync state.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=212346#p212346
| title = <nowiki>Performance: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jun 11th, 2014
| added = Jun 11th, 2014
| script_version = 0.23
}}
}}

{{FGCquote
|1= There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[http://sourceforge.net/p/atlas/feature-requests/10/ http://sourceforge.net/p/atlas/feature-requests/10/]

[http://sourceforge.net/p/atlas/feature-requests/16/ http://sourceforge.net/p/atlas/feature-requests/16/]

|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.23
}}
}}

== Upcoming developments ==
we are looking at making the loading of this data asynchronous so startup is not delayed, but we also lack Windows developers who can investigate the issue, since Linux, Mac and some Windows boxes are absolutely fine.

There's future work to move even more data into the cache — for example parking positions — which will further help performance for FMS / map systems since we
won't need to parse lots of XML data repeatedly.

{{FGCquote
|This makes me think I should do some validation on FG_HOME, i.e that it exists, and is writeable. That would have caught the UTF-8 / windows-local-8-bit encoding screw-up I had for 2.10, too. I think we have all the pieces to do this, will come up with something in the next few days.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192879#p192879
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Wed Oct 30</nowiki>
}}
}}

{{FGCquote
|I need people to track down *why* the cache rebuild is being triggered. The possibilities are: a scenery path reconfiguration (added / removed / re-ordered scenery paths) or that one of the .dat files we build the cache from has been modified. All the .dat files (Navaids/nav.dat.gz, Airports/apt.dat.gz, and similar .dat.gz files) should have a modification timestamp that corresponds to when the program was installed. If people could confirm that's the case, it would be one useful step.<br/>
<br/>
The next step after that is for someone with a debug build (compiled from source) to step through the cache startup code and see which conditional is tripping the rebuild.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=191948#p191948
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 17</nowiki>
}}
}}

{{FGCquote
|Having the option would be awesome, because it would greatly simplify troubleshooting, as you say - so having additional startup options that explicitly override/ignore autosave.xml and ~/.fgfsrc would be '''awesome''' as it would be much more straightforward to exclude a plethora of potential problem sources, we could save '''tons''' of time that way - but I wouldn't make it part of the same option. Ideally, being able to ignore autosave/fgfsrc would be different command-line arguments.Preferably, we would have a "soft ignore" mode (retaining data) and a "delete" mode, which resets any local settings that may interfere with FG.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192621#p192621
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|I'll add a --rebuild-caches option and it can drop the aircraft and terrasync caches too.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192464#p192464
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 24</nowiki>
}}
}}

{{FGCquote
|I mean the update cache which stops us spamming the server with update requests every launch - instead we only check the server once per 24-hour period, which greatly cuts down on nuisance update polls to the server.
The only thing I can't decide if this option should drop is the auto-save file. Then the options becomes a bit more of a 'reset to defaults', which might be more useful since people often end up with old values in their auto-save and again we don't have a UI to drop it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192619#p192619
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|So I think only the following is missing:<br/>
* make --restore-defaults kill the caches (nav-cache, aircraft cache and terrasync update cache)
* add a --ignore-defaults which stops both read *and* writing of autosave.xml
* log any XML config file we process
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

== Discussion ==
{{Note|Also see [[A NavDB Web Service]].}}

{{FGCquote
|We do not currently have a dedicated interface for exchanging internal data structures like the navdb, terrain data or images/video streams. However, something like that would be generally useful for a whole number of purposes and projects, so please feel free to leave a feature request at the tracker: <br/>
[http://flightgear-bugs.googlecode.com/ http://flightgear-bugs.googlecode.com/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=186972#p186972
|title=<nowiki>Re: How to access navigation data in FlightGear ?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Jul 15</nowiki>
}}
}}
{{FGCquote
|the navigation databases<br/>
<br/>
Currently these are gzipped compressed text - they’re not small and currently we change them infrequently but the upstream sources does receive updates relatively often (monthly?). Again there is some code dependency here, since new versions could break things.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

{{FGCquote
|My proposed initial solution, but this is where the discussion starts:
move the category [1] files, and potentially unzipped [2] files, into the main flightgear repository, under, say, ‘flightgear/data’. I don’t think a submodule gains us anything, all the files are tiny so it won’t bloat the repository. (And it avoids the complexity of forgetting to update the submodule - but if that issue can be solved, a submodule also works for me)

(We need to switch to unzipping the category [2] files anyway, for another improvement to startup performance, and once they are text rather than binary, Git will be able to diff them efficiently, hence my thought they can maybe be treated the same way. But I’m not sure. Also there is the option to start getting upstream updates more often, e.g. between FG releases)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

== FGPositioned ==
{{FGCquote
|it will become a base for the following:
* FGAirport
* FGRunway
* FGFix
* FGNavRecord
* ATCData
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

{{FGCquote
|I've been carrying on with my experiments with my FGPositioned idea, and I now have several of my original steps done:
* Fix, NavRecord, Airport and Runway all inherit the base class
* they all live on the heap, where previously Runway and Fix were stack based, and hence rather heavy to work with<br/>
* since the liftetime is now (generally) long, I can use a persistent spatial index (currently not Matthias', but it's an easy, internal change)
* I can query all of the above in a unified fashion, and add more types easily (Jon Stockhill has obstacle data I can add in)
* I've written a bunch of test cases, all of which pass identically on the mainline and with my changes applied
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20257459/
|title=<nowiki>[Flightgear-devel] FGPositioned update</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-09-06</nowiki>
}}
}}

{{FGCquote
|it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

== Access ==
You can use any SQLite editor/browser to access the navcache file and visualize it
There are basically two ways to access this via Nasal 1) the "proper" way is to use/extend the NasalPositioned(_cpbind).cxx file in $FG_SRC/Scripting - with 2), being direct SQLite access using the sqlite module from the Nasal github repo.

Either way, you would need to modify/patch and rebuild fgfs.
In general, I would recommend to file a feature request and/or raise this on the devel list.

{{FGCquote
|1= my suggestion would be to use an SQLite browser/editor and go to $FG_HOME to open the navcache there (see the wiki link above), you can then inspect the whole navcache - what you find in it is basically a mix up different sources (including Xplane data) - and most of it is available at run-time via FGPositioned APIs and their corresponding Nasal equivalents.
So given that we are talking about Python and Java here, you could either turn the FGPositioned C++ stuff into a reusable library for use by OpenRadar/ATC-Pie, or simply read the navcache directly. With the latter having the disadvantage that people need to have fgfs installed locally.

Otherwise, you could also extract the relevant data from the navcache and ship that with both ATC clients.
However, please see the wiki: the main guy behind the navcache is Zakalawe, and he would prefer if people didn't access/process the navcache directly but only use the FG-specific APIs.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= this opens up the question if the navcache should really be an integrated component, or if it might not be better to turn it into a standalone library/program that could be used by multiple processes, regardless of fgfs having to be installed/running, i.e. some form of true database.
Overall that would seem like the best solution to me, because the navcache is a feature that has severely crippled the fg experience for many new users, so that it would make sense to move this to a dedicated/standalone component and use it like a conventional database.
There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[[A NavDB Web Service]]
If in doubt, get in touch with Zakalawe on the devel list, the navcache is his baby after all ...
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

=== Accessing via Nasal ===
{{Move|Nasal library|User talk:Red Leader#Nasal positioned APIs .28navcache.29}}

Several [[Nasal]] functions exist to query the navdata cache of 'positioned' objects, i.e items with a defined location in the simulation world. (These objects all inherit from <tt>FGPositioned</tt> internally). The functions return either one, or a vector, of wrapped Nasal objects. These are efficient, but unlike a hash they cannot simply be <tt>debug.dump()</tt> to view all their members and methods, many of which are computed in a lazy fashion (i.e. on demand).

When the query functions take a position, the default value is the current aircraft location. An alternative location can be supplied by passing two number (lat, lon), a Geo.Coord object, or any positioned object or waypoint retrieved from another query.

;findAirportsWithinRange()
: Find all airports within a specified range (in NM) of the current position or explicit position
;findAirportsByICAO()
: Find airports matching a complete or partial ICAO code. In particular this can search for all airports starting with a two or three letter prefix.
;navinfo()
: Return a list of navaids near a location by type and ident. Type should be 'fix', 'vor', 'ndb', 'dme'
;findNavaidsWithinRange()
: Search for navaids within a particular range (in NM), optionally limited by type. This provides a 'find the closest ILS' function
;findNavaidByFrequency()
: find the closest navaid (of a particular type) matching an exact frequency
;findNavaidsByFrequency()
: find all the navaids matching a particular frequency and optional type, sorted by distance from the search location.

All positioned objects returned by the above methods have the following members:
;id
: Identifier - ICAO code for airports, published ident for navaids and fixes
;lon
: degrees longitude
;lat
: degrees latitude

Depending on type, the following members are also available:
;name
: the full name of the airport or navaid if one is defined
;elevation
: the ASL elevation of the object in feet

For navaids, the following members are available:
;frequency
: the navaid frequency in kHz
;type
: the navaid type as a string: vor, dme, loc, ils, ndb
;course
: the degrees course associated with the navaid, for localiser and ILS stations

{{Appendix}}

[[Category:Core development projects]]

Navdata cache

2017-03-18T17:16:29Z

Sanhozay: /* Read only database */

{{Out of date}}
{{See also|Fgfs.pid}}

{{Caution|This feature is crucial to the FlightGear startup sequence, but is unfortunately infamous for rendering FlightGear non-startable under certain situations. Particularly, after experiencing a FlightGear crash or when installing/running multiple FlightGear instances at the same time<ref>{{cite web
|url = http://sourceforge.net/p/flightgear/mailman/message/33029411/
|title = <nowiki>[Flightgear-devel] Random oddities</nowiki>
|author = Thorsten Renk
| date = Nov 12th, 2014
}}</ref>. It is assumed that this is due to lack of synchronization and missing <code>atexit()</code> handlers<ref>{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=17&t=24998&p=228533&#p228533
|title = <nowiki>FATAL ERROR</nowiki>
|author = Hooray
| date = Wed Dec 31, 2014 9:24 am
}}</ref><ref>{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=17&t=24998&p=228533&#p228533
|title = <nowiki>http://forum.flightgear.org/viewtopic.php?f=35&t=27364&p=261267&hilit=#p261267</nowiki>
|author = Hooray
| date = Wed Oct 21, 2015 1:55 pm
}}</ref>, so that the SQLite database may get corrupted under certain circumstances.

The way to resolve this issue is by renaming/deleting the navdata cache entirely (<code>navdata_''x''_''y''.cache</code>), renaming the folder containing [[$FG_HOME]] so that the cache gets rebuilt during the next start, or to use the powerful yet dangerous <code>--restore-defaults</code> command line option to reset all user settings to their defaults and to rebuild the cache.

On Windows another option is to go to ''yourusername''/AppData/Roaming/flightgear.org, and delete the navdata file inside that folder. If it still crashes, rename the flightgear.org folder to flightgearBAK.orgBAK, which will fix the errors, but you lose your user settings, such as options you have set in sim (ALS, don't show fps / ms, etc), joystick settings, etc ... In case FG starts up well, you can restore these settings by copiing back the files from the backup directory.

Unfortunately, this bug is hard to reproduce. So if you are encountering this bug, please be sure to {{create ticket|create a ticket}}, including instructions for reproducing the bug, so that this can be hopefully fixed.}}

[[File:Fghome-3.7.png|400px|right|Screen shot showing structure of [[$FG_HOME]]]]
[[File:Navcache-schema.png|right|400px|Screen shot showing the SQLite3 schema of the nav cache using a GUI SQLite database editor]]

The '''navdata cache''', '''navdb''', (sometimes also '''navcache''') is automatically built by FlightGear during startup by parsing/processing the gzipped <code>nav.dat</code> file and building a spatial SQLite-based database in [[$FG_HOME]] so that more efficient queries can be run at run-time, but, in particular when starting up/[[Reset & re-init|re-initializing FlightGear]]. Memory consumption is also lower, since we don't keep airports / fixes / taxiways / runways in memory until they're needed.

This feature have been available since [[Changelog 2.10|FlightGear 2.10]] released in February 2013.

== Background ==
[[File:Navcache.png|thumb|Screen shot showing several navcache (SQLite) files in $FG_HOME for various fgfs versions]]

We need a lot of data ''available'' at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling ''availability'' from ''loading''.

== Cache initialization ==
Usually, the navdb will only be compiled once during the first start of the simulator - however, some changes may require rebuilding the cache on disk (see below for details).

Touching the navdata files will cause a rebuild, so rebuilds need to take a 'reasonable' amount of time. Shipping the binary data improves first-launch
perceptions, but many applications do additional work on their first launch after an install, so it's not a top concern for the time being.

When the scenery paths change, we have to rebuild, because Airports XML data (from the <code><scenery>/Airports/</code> tree) is overlaid into the cache, replacing the data from <code>apt.dat</code>. This means when the search paths or order changes, we have to completely rebuild, because there's no way to restore the unmodified (prior to XML overlay) version.

{{FGCquote
|we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

Zakalawe considers the time and fragility to implement such a system much greater than the impact of a rebuild when switching scenery paths, which most people don't do very often.

The rebuild is purely a CPU / disk-bound operation, and for most people, it takes around 60 sec for debug and 30 sec for release times for a complete rebuild. (That time will be dramatically reduced if we get the taxiway data out of <code>apt.dat</code> in the future, since taxiways account for >80% of the lines in the file).

Usually the navdb should be under 200 MB and normally even a rebuild should not take much longer than a few minutes. However, on some platforms/OS the navdb rebuild is known to take exceptionally long, which seems to affect mainly Windows users - some of whom have reported the navcache rebuild taking more than 30 minutes.

== Technical details ==
[[File:Sqliteman-showing-navcache.png|right|400px|sqliteman (Qt based) showing navcache view]]

The nav-cache is versioned, it will be wiped when the cache schema version changes, but right now it’s not wiped when the flightgear version does.

The DB schema version is tracked internally in the file, and if the schema changes during a development version (3.3 or whatever) it will force a drop and rebuild.

The naming scheme is why the first run of a new stable release of FG always does a cache rebuild - which means you can run stable and dev versions side by side without continual cache rebuilds of course.

we /do/ also run a Sqlite verification check on the DB at launch time - this should catch many kinds of file-/index- level corruption (bad commit, etc), and in any case where we detect an issue, the solution is again to drop the cache and rebuild.

The internal format of the cache (for example the fact it's a SQL DB) is deliberately opaque. There are no guarantees made about the format of the file, the SQL scheme or anything. There is a version field of course, and we're not planning or expecting any changes, but we really don't want to be tied to the current scheme if we discover problems or want to add something else in the future.

The cache is stored in <code>[[$FG_HOME]]/navdata.cache</code>, and is rebuilt if the timestamps on any of the data files change (<code>apt.dat</code>, <code>nav.dat</code>, <code>fix.dat</code> and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is ''much'' faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead.

== Troubleshooting ===

{{Note|
A copy of your navdata.cache would be appreciated (the broken one), since of the two copies James was sent so far, neither were corrupted - they both passed the SQLite integrity check.
This has led James to think the issue is permissions, not corruption of the DB. Of course, there could be multiple issues. If you can find the suspect navcache, please upload it to: [https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW] and let James know.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=304747#p304747
|title = <nowiki> Re: sql: attempt to write a read only database </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Feb 3rd, 2017
|added = Feb 3rd, 2017
|script_version = 0.40
}}</ref>

}}

== Known issues ==

{{Note| See also these bug reports:
* {{Issue|1166}}
* {{Issue|894}}
* {{Issue|1398}}
* {{Issue|1774}}
}}

The whole navdb build thing is proving to be the single most problematic feature added in the last couple of years affecting potentially all users, because unlike most additions, it's not an optional thing, i.e. it must be executed, and is needed for FG to work - given that, it would really make sense exploring to ship a pre-built navdb with future FlightGear releases, or at least factor out the corresponding code so that it can be provided as a standalone executable that is shipped as part of fgfs, so that it can be executed by the installer, without fgfs being affected by it inevitably - that way, troubleshooting related issues should also become much easier, in addition, this separation would facilitate having sync'ed navdbs across multiple instances (think virtual ATC, multiplayer, combat simulation, or even just a fsweekend/linuxTag-like setup).

This work would also greatly facilitate turning the navdb into a HLA/IPC-enabled service one day.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293128#p293128
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 25th, 2016
|added = Aug 25th, 2016
|script_version = 0.40
}}</ref>

all startup/repositioning logic needs navdb access - otherwise, it would be possible to also make the whole system optional during startup/runtime, i.e. via some kind of property, so that people could opt-out until certain issues are addressed.
Obviously, that would break any conventional radio-navigation equipped aircraft, but also interactive mapping/charting avionics/dialogs, so may not be desirable ...
Anyway, moving the navdb build into the release process should be possible, and would help address this, until the underlying C++ code has been ironed out<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293203#p293203
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2016
|added = Aug 26th, 2016
|script_version = 0.40
}}</ref>

Unfortunately the cache must be regenerated each time you change scenery paths. So you cannot pre-build it. Recent changes to remove dynamic airports from it should help significantly, but it needs to be made more fail-safe.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293224#p293224
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> bugman </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

the issue has been around for so long, it would be better to recognie that the system needs to be separated/split up, so that a pre-built database can be provided, or so that a central navdb "service" (server) can be used - that way, it could still be a separate executable that doesn't cripple the fgfs experience for >= ~25% of our newcomers
The whole thing started out as a navdb after all, there is no reason why we should be adding so many inter-dependencies to it until some of the key problems have been solved.
Besides, this isn't the first time that fgfs had a cached navdb layer (anybody here remember the original metakit implementation from the early 2000s?)
In its current form, this whole feature contributes to the majority of bug reports, and actual crashes, and is causing tons of support threads on the forum.
Thus, it would definitely make sense to review what's there currently, and see if some things can be changed/re-implemented to make this a less critical feature<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293256#p293256
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

=== Windows Issues ===
As as we know, it's a Windows-specific issue related to SQLite and/or the way $FG_HOME works on Windows: http://wiki.flightgear.org/$FG_HOME
Most core developers, as well as most people who regularly build from source, are using non-Windows OS, i.e. are UNIX-based (MacOS/Linux etc), where the problem usually doesn't show up at all, which makes it hard to reproduce for people able to troubleshoot these things. And unfortunately, we don't really have any Windows-based core developers remaining - the main guy who would handle such compatibility issues on Windows used to be FredB who hasn't been seen in quite a while - and the main guy behind the navcache/navdb is also a Mac user, so not in a good position to reproduce these things, absent some complex VM setup.

Thus, if you are in any position to provide additional feedback/info using development tools (e.g. a debugger) that would indeed be very helpful.
For now, it is even clear if this is related to the location of $FG_HOME on Windows (which has recently changed AFAIK), or if it's related to SQLite itself.
Personally, I've been able to reproduce a handful of SQLite related issues - but I found those difficult to troubleshoot due to the way SQLite is used by FlightGear, i.e. without any logging support/options being exposed currently.

In general, the SQLite-navdb is a great idea - but in practice, it's been crippling FlightGear quite severely since the day it's been added for a number of users, especially those on Windows - simply because we're getting very little action-able feedback/community support, and core contributors who regularly build from source are usually not able to reproduce these issues, while also typically not being very familiar with potential Windows-level issues.

Again, it would really help to file an issue for this - or at least add to any existing (open) ones to raise some awareness of this, and hopefully help improve the situation over time.

{{FGCquote
|1= I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=228533#p228533
| title = <nowiki>Re: FATAL ERROR</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Dec 31st, 2014
| added = Dec 31st, 2014
| script_version = 0.25
}}
}}

=== Read only database ===
On Windows, versions of Flightgear up to 2017.1.1 can have problems restarting if the simulator did not close normally. This usually results in a message about a readonly database, e.g.

* <code>Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge</code>
* <code>Sqlite error : attempt to write a readonly database</code>

The solution is to delete the <code>fgfs.pid</code> file from <code>yourusername/AppData/Roaming/flightgear.org</code>.

Note that this was a long-standing bug and the established solution was to delete the whole <code>yourusername/AppData/Roaming/flightgear.org</code> directory. Although this works, it should not be necessary to fix the problem; deleting the <code>fgfs.pid</code> file should allow Flightgear to start.

The root cause of the problem should be fixed in Flightgear 2017.1.2.

=== Corruption due to crashes ===
The navcache also seems to get corrupted during segfaults/crashes, especially on Windows, but more recently also on OSX:

{{FGCquote
|1= Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=250389#p250389
| title = <nowiki>Sqlite error</nowiki>
| author = <nowiki>daniel36</nowiki>
| date = Jul 9th, 2015
}}
}}

{{FGCquote
|at least on my 10.7 build, I’m seeing an issue with the nav-cache not initialising. This is actually good, because it gives me a way, finally, to trace down the ‘nav-cache never initialises’ bug that some folks have reported. But it will take a little time. Since the same binary works perfectly on my 10.10 box, I assume it’s something /very/ subtle, probably uninitialised memory or some tiny change in zlib’s gzread functions (since we use the system Zlib library which hence could be different between 10.7 and 10.10).
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33457470/
|title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-18</nowiki>
}}
}}

{{FGCquote
|I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=228533#p228533
|title=<nowiki>Re: FATAL ERROR</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Dec 31</nowiki>
}}
}}

== High Level Architecture ==
{{Main article|High-Level Architecture}}
{{FGCquote
|1= we'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34725710/
| title = <nowiki>[Flightgear-devel] HLA Update</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Dec 29th, 2015
| added = Dec 29th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= I'm looking forward to some feedback and Python code from Jean-Paul to start working on a NavDataCache interface, to create a 'nav_data_cache' or 'navdb' Python C/C++ module. I also had the idea of running this subsystem in a thread. This avoids adding more strain to the main loop, making FGPythonSys even more inconspicuous.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34798001/
| title = <nowiki>Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem.</nowiki>
| author = <nowiki>Edward d'Auvergne</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}
{{FGCquote
|1= it would be possibly to deprecate virtually all the custom Nasal APIs in favour of commands, but much harder to do that solely using properties. (Think about searching the NavDB or appending a waypoint to a flightplan). If we started moving in that direction, we don’t need to create separate APIs for multiple languages, they simply work using the properties + commands system, and the command system already has the exact set of property modification operations you proposed.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34795592/
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...)</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= it would conceptually be the right thing to do to turn the navdb/positioned stuff into a "client/server" subsystem where the navdb acts as a server that can handle client-requests asynchronously. The funny thing is that SQLite itself is obviously based on the whole "server-less" notion.

From a design standpoint, the NavDB is basically an "environmental" subsystem, i.e. heavily reliant on the underlying terrain/scenery because it provides navaids - thus, in a distributed/MP setup it would actually make sense for multi-instance setups to query the same DB to replicate/sync state.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=212346#p212346
| title = <nowiki>Performance: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jun 11th, 2014
| added = Jun 11th, 2014
| script_version = 0.23
}}
}}

{{FGCquote
|1= There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[http://sourceforge.net/p/atlas/feature-requests/10/ http://sourceforge.net/p/atlas/feature-requests/10/]

[http://sourceforge.net/p/atlas/feature-requests/16/ http://sourceforge.net/p/atlas/feature-requests/16/]

|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.23
}}
}}

== Upcoming developments ==
we are looking at making the loading of this data asynchronous so startup is not delayed, but we also lack Windows developers who can investigate the issue, since Linux, Mac and some Windows boxes are absolutely fine.

There's future work to move even more data into the cache — for example parking positions — which will further help performance for FMS / map systems since we
won't need to parse lots of XML data repeatedly.

{{FGCquote
|This makes me think I should do some validation on FG_HOME, i.e that it exists, and is writeable. That would have caught the UTF-8 / windows-local-8-bit encoding screw-up I had for 2.10, too. I think we have all the pieces to do this, will come up with something in the next few days.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192879#p192879
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Wed Oct 30</nowiki>
}}
}}

{{FGCquote
|I need people to track down *why* the cache rebuild is being triggered. The possibilities are: a scenery path reconfiguration (added / removed / re-ordered scenery paths) or that one of the .dat files we build the cache from has been modified. All the .dat files (Navaids/nav.dat.gz, Airports/apt.dat.gz, and similar .dat.gz files) should have a modification timestamp that corresponds to when the program was installed. If people could confirm that's the case, it would be one useful step.<br/>
<br/>
The next step after that is for someone with a debug build (compiled from source) to step through the cache startup code and see which conditional is tripping the rebuild.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=191948#p191948
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 17</nowiki>
}}
}}

{{FGCquote
|Having the option would be awesome, because it would greatly simplify troubleshooting, as you say - so having additional startup options that explicitly override/ignore autosave.xml and ~/.fgfsrc would be '''awesome''' as it would be much more straightforward to exclude a plethora of potential problem sources, we could save '''tons''' of time that way - but I wouldn't make it part of the same option. Ideally, being able to ignore autosave/fgfsrc would be different command-line arguments.Preferably, we would have a "soft ignore" mode (retaining data) and a "delete" mode, which resets any local settings that may interfere with FG.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192621#p192621
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|I'll add a --rebuild-caches option and it can drop the aircraft and terrasync caches too.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192464#p192464
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 24</nowiki>
}}
}}

{{FGCquote
|I mean the update cache which stops us spamming the server with update requests every launch - instead we only check the server once per 24-hour period, which greatly cuts down on nuisance update polls to the server.
The only thing I can't decide if this option should drop is the auto-save file. Then the options becomes a bit more of a 'reset to defaults', which might be more useful since people often end up with old values in their auto-save and again we don't have a UI to drop it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192619#p192619
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|So I think only the following is missing:<br/>
* make --restore-defaults kill the caches (nav-cache, aircraft cache and terrasync update cache)
* add a --ignore-defaults which stops both read *and* writing of autosave.xml
* log any XML config file we process
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

== Discussion ==
{{Note|Also see [[A NavDB Web Service]].}}

{{FGCquote
|We do not currently have a dedicated interface for exchanging internal data structures like the navdb, terrain data or images/video streams. However, something like that would be generally useful for a whole number of purposes and projects, so please feel free to leave a feature request at the tracker: <br/>
[http://flightgear-bugs.googlecode.com/ http://flightgear-bugs.googlecode.com/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=186972#p186972
|title=<nowiki>Re: How to access navigation data in FlightGear ?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Jul 15</nowiki>
}}
}}
{{FGCquote
|the navigation databases<br/>
<br/>
Currently these are gzipped compressed text - they’re not small and currently we change them infrequently but the upstream sources does receive updates relatively often (monthly?). Again there is some code dependency here, since new versions could break things.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

{{FGCquote
|My proposed initial solution, but this is where the discussion starts:
move the category [1] files, and potentially unzipped [2] files, into the main flightgear repository, under, say, ‘flightgear/data’. I don’t think a submodule gains us anything, all the files are tiny so it won’t bloat the repository. (And it avoids the complexity of forgetting to update the submodule - but if that issue can be solved, a submodule also works for me)

(We need to switch to unzipping the category [2] files anyway, for another improvement to startup performance, and once they are text rather than binary, Git will be able to diff them efficiently, hence my thought they can maybe be treated the same way. But I’m not sure. Also there is the option to start getting upstream updates more often, e.g. between FG releases)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

== FGPositioned ==
{{FGCquote
|it will become a base for the following:
* FGAirport
* FGRunway
* FGFix
* FGNavRecord
* ATCData
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

{{FGCquote
|I've been carrying on with my experiments with my FGPositioned idea, and I now have several of my original steps done:
* Fix, NavRecord, Airport and Runway all inherit the base class
* they all live on the heap, where previously Runway and Fix were stack based, and hence rather heavy to work with<br/>
* since the liftetime is now (generally) long, I can use a persistent spatial index (currently not Matthias', but it's an easy, internal change)
* I can query all of the above in a unified fashion, and add more types easily (Jon Stockhill has obstacle data I can add in)
* I've written a bunch of test cases, all of which pass identically on the mainline and with my changes applied
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20257459/
|title=<nowiki>[Flightgear-devel] FGPositioned update</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-09-06</nowiki>
}}
}}

{{FGCquote
|it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

== Access ==
You can use any SQLite editor/browser to access the navcache file and visualize it
There are basically two ways to access this via Nasal 1) the "proper" way is to use/extend the NasalPositioned(_cpbind).cxx file in $FG_SRC/Scripting - with 2), being direct SQLite access using the sqlite module from the Nasal github repo.

Either way, you would need to modify/patch and rebuild fgfs.
In general, I would recommend to file a feature request and/or raise this on the devel list.

{{FGCquote
|1= my suggestion would be to use an SQLite browser/editor and go to $FG_HOME to open the navcache there (see the wiki link above), you can then inspect the whole navcache - what you find in it is basically a mix up different sources (including Xplane data) - and most of it is available at run-time via FGPositioned APIs and their corresponding Nasal equivalents.
So given that we are talking about Python and Java here, you could either turn the FGPositioned C++ stuff into a reusable library for use by OpenRadar/ATC-Pie, or simply read the navcache directly. With the latter having the disadvantage that people need to have fgfs installed locally.

Otherwise, you could also extract the relevant data from the navcache and ship that with both ATC clients.
However, please see the wiki: the main guy behind the navcache is Zakalawe, and he would prefer if people didn't access/process the navcache directly but only use the FG-specific APIs.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= this opens up the question if the navcache should really be an integrated component, or if it might not be better to turn it into a standalone library/program that could be used by multiple processes, regardless of fgfs having to be installed/running, i.e. some form of true database.
Overall that would seem like the best solution to me, because the navcache is a feature that has severely crippled the fg experience for many new users, so that it would make sense to move this to a dedicated/standalone component and use it like a conventional database.
There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[[A NavDB Web Service]]
If in doubt, get in touch with Zakalawe on the devel list, the navcache is his baby after all ...
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

=== Accessing via Nasal ===
{{Move|Nasal library|User talk:Red Leader#Nasal positioned APIs .28navcache.29}}

Several [[Nasal]] functions exist to query the navdata cache of 'positioned' objects, i.e items with a defined location in the simulation world. (These objects all inherit from <tt>FGPositioned</tt> internally). The functions return either one, or a vector, of wrapped Nasal objects. These are efficient, but unlike a hash they cannot simply be <tt>debug.dump()</tt> to view all their members and methods, many of which are computed in a lazy fashion (i.e. on demand).

When the query functions take a position, the default value is the current aircraft location. An alternative location can be supplied by passing two number (lat, lon), a Geo.Coord object, or any positioned object or waypoint retrieved from another query.

;findAirportsWithinRange()
: Find all airports within a specified range (in NM) of the current position or explicit position
;findAirportsByICAO()
: Find airports matching a complete or partial ICAO code. In particular this can search for all airports starting with a two or three letter prefix.
;navinfo()
: Return a list of navaids near a location by type and ident. Type should be 'fix', 'vor', 'ndb', 'dme'
;findNavaidsWithinRange()
: Search for navaids within a particular range (in NM), optionally limited by type. This provides a 'find the closest ILS' function
;findNavaidByFrequency()
: find the closest navaid (of a particular type) matching an exact frequency
;findNavaidsByFrequency()
: find all the navaids matching a particular frequency and optional type, sorted by distance from the search location.

All positioned objects returned by the above methods have the following members:
;id
: Identifier - ICAO code for airports, published ident for navaids and fixes
;lon
: degrees longitude
;lat
: degrees latitude

Depending on type, the following members are also available:
;name
: the full name of the airport or navaid if one is defined
;elevation
: the ASL elevation of the object in feet

For navaids, the following members are available:
;frequency
: the navaid frequency in kHz
;type
: the navaid type as a string: vor, dme, loc, ils, ndb
;course
: the degrees course associated with the navaid, for localiser and ILS stations

{{Appendix}}

[[Category:Core development projects]]

Navdata cache

2017-03-18T17:11:53Z

Sanhozay: /* Read only database */

{{Out of date}}
{{See also|Fgfs.pid}}

{{Caution|This feature is crucial to the FlightGear startup sequence, but is unfortunately infamous for rendering FlightGear non-startable under certain situations. Particularly, after experiencing a FlightGear crash or when installing/running multiple FlightGear instances at the same time<ref>{{cite web
|url = http://sourceforge.net/p/flightgear/mailman/message/33029411/
|title = <nowiki>[Flightgear-devel] Random oddities</nowiki>
|author = Thorsten Renk
| date = Nov 12th, 2014
}}</ref>. It is assumed that this is due to lack of synchronization and missing <code>atexit()</code> handlers<ref>{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=17&t=24998&p=228533&#p228533
|title = <nowiki>FATAL ERROR</nowiki>
|author = Hooray
| date = Wed Dec 31, 2014 9:24 am
}}</ref><ref>{{cite web
|url = http://forum.flightgear.org/viewtopic.php?f=17&t=24998&p=228533&#p228533
|title = <nowiki>http://forum.flightgear.org/viewtopic.php?f=35&t=27364&p=261267&hilit=#p261267</nowiki>
|author = Hooray
| date = Wed Oct 21, 2015 1:55 pm
}}</ref>, so that the SQLite database may get corrupted under certain circumstances.

The way to resolve this issue is by renaming/deleting the navdata cache entirely (<code>navdata_''x''_''y''.cache</code>), renaming the folder containing [[$FG_HOME]] so that the cache gets rebuilt during the next start, or to use the powerful yet dangerous <code>--restore-defaults</code> command line option to reset all user settings to their defaults and to rebuild the cache.

On Windows another option is to go to ''yourusername''/AppData/Roaming/flightgear.org, and delete the navdata file inside that folder. If it still crashes, rename the flightgear.org folder to flightgearBAK.orgBAK, which will fix the errors, but you lose your user settings, such as options you have set in sim (ALS, don't show fps / ms, etc), joystick settings, etc ... In case FG starts up well, you can restore these settings by copiing back the files from the backup directory.

Unfortunately, this bug is hard to reproduce. So if you are encountering this bug, please be sure to {{create ticket|create a ticket}}, including instructions for reproducing the bug, so that this can be hopefully fixed.}}

[[File:Fghome-3.7.png|400px|right|Screen shot showing structure of [[$FG_HOME]]]]
[[File:Navcache-schema.png|right|400px|Screen shot showing the SQLite3 schema of the nav cache using a GUI SQLite database editor]]

The '''navdata cache''', '''navdb''', (sometimes also '''navcache''') is automatically built by FlightGear during startup by parsing/processing the gzipped <code>nav.dat</code> file and building a spatial SQLite-based database in [[$FG_HOME]] so that more efficient queries can be run at run-time, but, in particular when starting up/[[Reset & re-init|re-initializing FlightGear]]. Memory consumption is also lower, since we don't keep airports / fixes / taxiways / runways in memory until they're needed.

This feature have been available since [[Changelog 2.10|FlightGear 2.10]] released in February 2013.

== Background ==
[[File:Navcache.png|thumb|Screen shot showing several navcache (SQLite) files in $FG_HOME for various fgfs versions]]

We need a lot of data ''available'' at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling ''availability'' from ''loading''.

== Cache initialization ==
Usually, the navdb will only be compiled once during the first start of the simulator - however, some changes may require rebuilding the cache on disk (see below for details).

Touching the navdata files will cause a rebuild, so rebuilds need to take a 'reasonable' amount of time. Shipping the binary data improves first-launch
perceptions, but many applications do additional work on their first launch after an install, so it's not a top concern for the time being.

When the scenery paths change, we have to rebuild, because Airports XML data (from the <code><scenery>/Airports/</code> tree) is overlaid into the cache, replacing the data from <code>apt.dat</code>. This means when the search paths or order changes, we have to completely rebuild, because there's no way to restore the unmodified (prior to XML overlay) version.

{{FGCquote
|we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

Zakalawe considers the time and fragility to implement such a system much greater than the impact of a rebuild when switching scenery paths, which most people don't do very often.

The rebuild is purely a CPU / disk-bound operation, and for most people, it takes around 60 sec for debug and 30 sec for release times for a complete rebuild. (That time will be dramatically reduced if we get the taxiway data out of <code>apt.dat</code> in the future, since taxiways account for >80% of the lines in the file).

Usually the navdb should be under 200 MB and normally even a rebuild should not take much longer than a few minutes. However, on some platforms/OS the navdb rebuild is known to take exceptionally long, which seems to affect mainly Windows users - some of whom have reported the navcache rebuild taking more than 30 minutes.

== Technical details ==
[[File:Sqliteman-showing-navcache.png|right|400px|sqliteman (Qt based) showing navcache view]]

The nav-cache is versioned, it will be wiped when the cache schema version changes, but right now it’s not wiped when the flightgear version does.

The DB schema version is tracked internally in the file, and if the schema changes during a development version (3.3 or whatever) it will force a drop and rebuild.

The naming scheme is why the first run of a new stable release of FG always does a cache rebuild - which means you can run stable and dev versions side by side without continual cache rebuilds of course.

we /do/ also run a Sqlite verification check on the DB at launch time - this should catch many kinds of file-/index- level corruption (bad commit, etc), and in any case where we detect an issue, the solution is again to drop the cache and rebuild.

The internal format of the cache (for example the fact it's a SQL DB) is deliberately opaque. There are no guarantees made about the format of the file, the SQL scheme or anything. There is a version field of course, and we're not planning or expecting any changes, but we really don't want to be tied to the current scheme if we discover problems or want to add something else in the future.

The cache is stored in <code>[[$FG_HOME]]/navdata.cache</code>, and is rebuilt if the timestamps on any of the data files change (<code>apt.dat</code>, <code>nav.dat</code>, <code>fix.dat</code> and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is ''much'' faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead.

== Troubleshooting ===

{{Note|
A copy of your navdata.cache would be appreciated (the broken one), since of the two copies James was sent so far, neither were corrupted - they both passed the SQLite integrity check.
This has led James to think the issue is permissions, not corruption of the DB. Of course, there could be multiple issues. If you can find the suspect navcache, please upload it to: [https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW https://swanson.kdab.com/owncloud/index.php/s/P0DMwvV6TdQR5CW] and let James know.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=304747#p304747
|title = <nowiki> Re: sql: attempt to write a read only database </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Feb 3rd, 2017
|added = Feb 3rd, 2017
|script_version = 0.40
}}</ref>

}}

== Known issues ==

{{Note| See also these bug reports:
* {{Issue|1166}}
* {{Issue|894}}
* {{Issue|1398}}
* {{Issue|1774}}
}}

The whole navdb build thing is proving to be the single most problematic feature added in the last couple of years affecting potentially all users, because unlike most additions, it's not an optional thing, i.e. it must be executed, and is needed for FG to work - given that, it would really make sense exploring to ship a pre-built navdb with future FlightGear releases, or at least factor out the corresponding code so that it can be provided as a standalone executable that is shipped as part of fgfs, so that it can be executed by the installer, without fgfs being affected by it inevitably - that way, troubleshooting related issues should also become much easier, in addition, this separation would facilitate having sync'ed navdbs across multiple instances (think virtual ATC, multiplayer, combat simulation, or even just a fsweekend/linuxTag-like setup).

This work would also greatly facilitate turning the navdb into a HLA/IPC-enabled service one day.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293128#p293128
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 25th, 2016
|added = Aug 25th, 2016
|script_version = 0.40
}}</ref>

all startup/repositioning logic needs navdb access - otherwise, it would be possible to also make the whole system optional during startup/runtime, i.e. via some kind of property, so that people could opt-out until certain issues are addressed.
Obviously, that would break any conventional radio-navigation equipped aircraft, but also interactive mapping/charting avionics/dialogs, so may not be desirable ...
Anyway, moving the navdb build into the release process should be possible, and would help address this, until the underlying C++ code has been ironed out<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293203#p293203
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 26th, 2016
|added = Aug 26th, 2016
|script_version = 0.40
}}</ref>

Unfortunately the cache must be regenerated each time you change scenery paths. So you cannot pre-build it. Recent changes to remove dynamic airports from it should help significantly, but it needs to be made more fail-safe.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293224#p293224
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> bugman </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

the issue has been around for so long, it would be better to recognie that the system needs to be separated/split up, so that a pre-built database can be provided, or so that a central navdb "service" (server) can be used - that way, it could still be a separate executable that doesn't cripple the fgfs experience for >= ~25% of our newcomers
The whole thing started out as a navdb after all, there is no reason why we should be adding so many inter-dependencies to it until some of the key problems have been solved.
Besides, this isn't the first time that fgfs had a cached navdb layer (anybody here remember the original metakit implementation from the early 2000s?)
In its current form, this whole feature contributes to the majority of bug reports, and actual crashes, and is causing tons of support threads on the forum.
Thus, it would definitely make sense to review what's there currently, and see if some things can be changed/re-implemented to make this a less critical feature<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=293256#p293256
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 27th, 2016
|added = Aug 27th, 2016
|script_version = 0.40
}}</ref>

=== Windows Issues ===
As as we know, it's a Windows-specific issue related to SQLite and/or the way $FG_HOME works on Windows: http://wiki.flightgear.org/$FG_HOME
Most core developers, as well as most people who regularly build from source, are using non-Windows OS, i.e. are UNIX-based (MacOS/Linux etc), where the problem usually doesn't show up at all, which makes it hard to reproduce for people able to troubleshoot these things. And unfortunately, we don't really have any Windows-based core developers remaining - the main guy who would handle such compatibility issues on Windows used to be FredB who hasn't been seen in quite a while - and the main guy behind the navcache/navdb is also a Mac user, so not in a good position to reproduce these things, absent some complex VM setup.

Thus, if you are in any position to provide additional feedback/info using development tools (e.g. a debugger) that would indeed be very helpful.
For now, it is even clear if this is related to the location of $FG_HOME on Windows (which has recently changed AFAIK), or if it's related to SQLite itself.
Personally, I've been able to reproduce a handful of SQLite related issues - but I found those difficult to troubleshoot due to the way SQLite is used by FlightGear, i.e. without any logging support/options being exposed currently.

In general, the SQLite-navdb is a great idea - but in practice, it's been crippling FlightGear quite severely since the day it's been added for a number of users, especially those on Windows - simply because we're getting very little action-able feedback/community support, and core contributors who regularly build from source are usually not able to reproduce these issues, while also typically not being very familiar with potential Windows-level issues.

Again, it would really help to file an issue for this - or at least add to any existing (open) ones to raise some awareness of this, and hopefully help improve the situation over time.

{{FGCquote
|1= I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=228533#p228533
| title = <nowiki>Re: FATAL ERROR</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Dec 31st, 2014
| added = Dec 31st, 2014
| script_version = 0.25
}}
}}

=== Read only database ===
On Windows, versions of Flightgear up to 2017.1.1 can have problems restarting if the simulator did not close normally. This usually results in a message about a readonly database, e.g.

* <code>Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge</code>
* <code>Sqlite error : attempt to write a readonly database</code>

The solution is to delete the <code>fgfs.pid</code> file from [[$FG_HOME]]. On Windows, this will usually be <code>C:\Users\yourname\Documents\FlightGear</code>.

Note that this was a long-standing bug and the established solution was to delete all the contents of [[$FG_HOME]] or the whole directory. Although this works, it should not be necessary to fix the problem; deleting the <code>fgfs.pid</code> file should allow Flightgear to start.

The root cause of the problem should be fixed in Flightgear 2017.1.2.

=== Corruption due to crashes ===
The navcache also seems to get corrupted during segfaults/crashes, especially on Windows, but more recently also on OSX:

{{FGCquote
|1= Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=250389#p250389
| title = <nowiki>Sqlite error</nowiki>
| author = <nowiki>daniel36</nowiki>
| date = Jul 9th, 2015
}}
}}

{{FGCquote
|at least on my 10.7 build, I’m seeing an issue with the nav-cache not initialising. This is actually good, because it gives me a way, finally, to trace down the ‘nav-cache never initialises’ bug that some folks have reported. But it will take a little time. Since the same binary works perfectly on my 10.10 box, I assume it’s something /very/ subtle, probably uninitialised memory or some tiny change in zlib’s gzread functions (since we use the system Zlib library which hence could be different between 10.7 and 10.10).
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33457470/
|title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-18</nowiki>
}}
}}

{{FGCquote
|I'd sugest to review the atexit() handlers in $FG_SRC/Main to ensure that the SQLite/navcache properly cleans up all resources there, i.e. by closing files etc - as far as I remember, the navcache is not an actual/proper "SGSubsystem" - so maybe the corresponding ctors aren't getting called during segfaults/crashes - IIRC, it's implemented as a singleton:
{{flightgear url|commit=49ce7cd318d00be44c43cffea028a6556104fe18|path=src/Main/fg_init.cxx|line=570}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=228533#p228533
|title=<nowiki>Re: FATAL ERROR</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Dec 31</nowiki>
}}
}}

== High Level Architecture ==
{{Main article|High-Level Architecture}}
{{FGCquote
|1= we'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34725710/
| title = <nowiki>[Flightgear-devel] HLA Update</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Dec 29th, 2015
| added = Dec 29th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= I'm looking forward to some feedback and Python code from Jean-Paul to start working on a NavDataCache interface, to create a 'nav_data_cache' or 'navdb' Python C/C++ module. I also had the idea of running this subsystem in a thread. This avoids adding more strain to the main loop, making FGPythonSys even more inconspicuous.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34798001/
| title = <nowiki>Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem.</nowiki>
| author = <nowiki>Edward d'Auvergne</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}
{{FGCquote
|1= it would be possibly to deprecate virtually all the custom Nasal APIs in favour of commands, but much harder to do that solely using properties. (Think about searching the NavDB or appending a waypoint to a flightplan). If we started moving in that direction, we don’t need to create separate APIs for multiple languages, they simply work using the properties + commands system, and the command system already has the exact set of property modification operations you proposed.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34795592/
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...)</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= it would conceptually be the right thing to do to turn the navdb/positioned stuff into a "client/server" subsystem where the navdb acts as a server that can handle client-requests asynchronously. The funny thing is that SQLite itself is obviously based on the whole "server-less" notion.

From a design standpoint, the NavDB is basically an "environmental" subsystem, i.e. heavily reliant on the underlying terrain/scenery because it provides navaids - thus, in a distributed/MP setup it would actually make sense for multi-instance setups to query the same DB to replicate/sync state.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=212346#p212346
| title = <nowiki>Performance: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jun 11th, 2014
| added = Jun 11th, 2014
| script_version = 0.23
}}
}}

{{FGCquote
|1= There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[http://sourceforge.net/p/atlas/feature-requests/10/ http://sourceforge.net/p/atlas/feature-requests/10/]

[http://sourceforge.net/p/atlas/feature-requests/16/ http://sourceforge.net/p/atlas/feature-requests/16/]

|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.23
}}
}}

== Upcoming developments ==
we are looking at making the loading of this data asynchronous so startup is not delayed, but we also lack Windows developers who can investigate the issue, since Linux, Mac and some Windows boxes are absolutely fine.

There's future work to move even more data into the cache — for example parking positions — which will further help performance for FMS / map systems since we
won't need to parse lots of XML data repeatedly.

{{FGCquote
|This makes me think I should do some validation on FG_HOME, i.e that it exists, and is writeable. That would have caught the UTF-8 / windows-local-8-bit encoding screw-up I had for 2.10, too. I think we have all the pieces to do this, will come up with something in the next few days.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192879#p192879
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Wed Oct 30</nowiki>
}}
}}

{{FGCquote
|I need people to track down *why* the cache rebuild is being triggered. The possibilities are: a scenery path reconfiguration (added / removed / re-ordered scenery paths) or that one of the .dat files we build the cache from has been modified. All the .dat files (Navaids/nav.dat.gz, Airports/apt.dat.gz, and similar .dat.gz files) should have a modification timestamp that corresponds to when the program was installed. If people could confirm that's the case, it would be one useful step.<br/>
<br/>
The next step after that is for someone with a debug build (compiled from source) to step through the cache startup code and see which conditional is tripping the rebuild.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=191948#p191948
|title=<nowiki>Re: Loading forever: "loading navigation data"</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 17</nowiki>
}}
}}

{{FGCquote
|Having the option would be awesome, because it would greatly simplify troubleshooting, as you say - so having additional startup options that explicitly override/ignore autosave.xml and ~/.fgfsrc would be '''awesome''' as it would be much more straightforward to exclude a plethora of potential problem sources, we could save '''tons''' of time that way - but I wouldn't make it part of the same option. Ideally, being able to ignore autosave/fgfsrc would be different command-line arguments.Preferably, we would have a "soft ignore" mode (retaining data) and a "delete" mode, which resets any local settings that may interfere with FG.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192621#p192621
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|I'll add a --rebuild-caches option and it can drop the aircraft and terrasync caches too.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192464#p192464
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Thu Oct 24</nowiki>
}}
}}

{{FGCquote
|I mean the update cache which stops us spamming the server with update requests every launch - instead we only check the server once per 24-hour period, which greatly cuts down on nuisance update polls to the server.
The only thing I can't decide if this option should drop is the auto-save file. Then the options becomes a bit more of a 'reset to defaults', which might be more useful since people often end up with old values in their auto-save and again we don't have a UI to drop it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192619#p192619
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

{{FGCquote
|So I think only the following is missing:<br/>
* make --restore-defaults kill the caches (nav-cache, aircraft cache and terrasync update cache)
* add a --ignore-defaults which stops both read *and* writing of autosave.xml
* log any XML config file we process
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sat Oct 26</nowiki>
}}
}}

== Discussion ==
{{Note|Also see [[A NavDB Web Service]].}}

{{FGCquote
|We do not currently have a dedicated interface for exchanging internal data structures like the navdb, terrain data or images/video streams. However, something like that would be generally useful for a whole number of purposes and projects, so please feel free to leave a feature request at the tracker: <br/>
[http://flightgear-bugs.googlecode.com/ http://flightgear-bugs.googlecode.com/]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=186972#p186972
|title=<nowiki>Re: How to access navigation data in FlightGear ?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Jul 15</nowiki>
}}
}}
{{FGCquote
|the navigation databases<br/>
<br/>
Currently these are gzipped compressed text - they’re not small and currently we change them infrequently but the upstream sources does receive updates relatively often (monthly?). Again there is some code dependency here, since new versions could break things.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

{{FGCquote
|My proposed initial solution, but this is where the discussion starts:
move the category [1] files, and potentially unzipped [2] files, into the main flightgear repository, under, say, ‘flightgear/data’. I don’t think a submodule gains us anything, all the files are tiny so it won’t bloat the repository. (And it avoids the complexity of forgetting to update the submodule - but if that issue can be solved, a submodule also works for me)

(We need to switch to unzipping the category [2] files anyway, for another improvement to startup performance, and once they are text rather than binary, Git will be able to diff them efficiently, hence my thought they can maybe be treated the same way. But I’m not sure. Also there is the option to start getting upstream updates more often, e.g. between FG releases)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33492344/
|title=<nowiki>[Flightgear-devel] FGData splitting / assembling the base package</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-25</nowiki>
}}
}}

== FGPositioned ==
{{FGCquote
|it will become a base for the following:
* FGAirport
* FGRunway
* FGFix
* FGNavRecord
* ATCData
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

{{FGCquote
|I've been carrying on with my experiments with my FGPositioned idea, and I now have several of my original steps done:
* Fix, NavRecord, Airport and Runway all inherit the base class
* they all live on the heap, where previously Runway and Fix were stack based, and hence rather heavy to work with<br/>
* since the liftetime is now (generally) long, I can use a persistent spatial index (currently not Matthias', but it's an easy, internal change)
* I can query all of the above in a unified fashion, and add more types easily (Jon Stockhill has obstacle data I can add in)
* I've written a bunch of test cases, all of which pass identically on the mainline and with my changes applied
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20257459/
|title=<nowiki>[Flightgear-devel] FGPositioned update</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-09-06</nowiki>
}}
}}

{{FGCquote
|it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2008-08-16</nowiki>
}}
}}

== Access ==
You can use any SQLite editor/browser to access the navcache file and visualize it
There are basically two ways to access this via Nasal 1) the "proper" way is to use/extend the NasalPositioned(_cpbind).cxx file in $FG_SRC/Scripting - with 2), being direct SQLite access using the sqlite module from the Nasal github repo.

Either way, you would need to modify/patch and rebuild fgfs.
In general, I would recommend to file a feature request and/or raise this on the devel list.

{{FGCquote
|1= my suggestion would be to use an SQLite browser/editor and go to $FG_HOME to open the navcache there (see the wiki link above), you can then inspect the whole navcache - what you find in it is basically a mix up different sources (including Xplane data) - and most of it is available at run-time via FGPositioned APIs and their corresponding Nasal equivalents.
So given that we are talking about Python and Java here, you could either turn the FGPositioned C++ stuff into a reusable library for use by OpenRadar/ATC-Pie, or simply read the navcache directly. With the latter having the disadvantage that people need to have fgfs installed locally.

Otherwise, you could also extract the relevant data from the navcache and ship that with both ATC clients.
However, please see the wiki: the main guy behind the navcache is Zakalawe, and he would prefer if people didn't access/process the navcache directly but only use the FG-specific APIs.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

{{FGCquote
|1= this opens up the question if the navcache should really be an integrated component, or if it might not be better to turn it into a standalone library/program that could be used by multiple processes, regardless of fgfs having to be installed/running, i.e. some form of true database.
Overall that would seem like the best solution to me, because the navcache is a feature that has severely crippled the fg experience for many new users, so that it would make sense to move this to a dedicated/standalone component and use it like a conventional database.
There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
[[A NavDB Web Service]]
If in doubt, get in touch with Zakalawe on the devel list, the navcache is his baby after all ...
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=264700#p264700
| title = <nowiki>Re: Improving stability: No-scenery-emergency mode</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 16th, 2015
| added = Nov 16th, 2015
| script_version = 0.25
}}
}}

=== Accessing via Nasal ===
{{Move|Nasal library|User talk:Red Leader#Nasal positioned APIs .28navcache.29}}

Several [[Nasal]] functions exist to query the navdata cache of 'positioned' objects, i.e items with a defined location in the simulation world. (These objects all inherit from <tt>FGPositioned</tt> internally). The functions return either one, or a vector, of wrapped Nasal objects. These are efficient, but unlike a hash they cannot simply be <tt>debug.dump()</tt> to view all their members and methods, many of which are computed in a lazy fashion (i.e. on demand).

When the query functions take a position, the default value is the current aircraft location. An alternative location can be supplied by passing two number (lat, lon), a Geo.Coord object, or any positioned object or waypoint retrieved from another query.

;findAirportsWithinRange()
: Find all airports within a specified range (in NM) of the current position or explicit position
;findAirportsByICAO()
: Find airports matching a complete or partial ICAO code. In particular this can search for all airports starting with a two or three letter prefix.
;navinfo()
: Return a list of navaids near a location by type and ident. Type should be 'fix', 'vor', 'ndb', 'dme'
;findNavaidsWithinRange()
: Search for navaids within a particular range (in NM), optionally limited by type. This provides a 'find the closest ILS' function
;findNavaidByFrequency()
: find the closest navaid (of a particular type) matching an exact frequency
;findNavaidsByFrequency()
: find all the navaids matching a particular frequency and optional type, sorted by distance from the search location.

All positioned objects returned by the above methods have the following members:
;id
: Identifier - ICAO code for airports, published ident for navaids and fixes
;lon
: degrees longitude
;lat
: degrees latitude

Depending on type, the following members are also available:
;name
: the full name of the airport or navaid if one is defined
;elevation
: the ASL elevation of the object in feet

For navaids, the following members are available:
;frequency
: the navaid frequency in kHz
;type
: the navaid type as a string: vor, dme, loc, ils, ndb
;course
: the degrees course associated with the navaid, for localiser and ILS stations

{{Appendix}}

[[Category:Core development projects]]

Cessna 337G Skymaster

2017-01-14T13:27:53Z

Sanhozay: /* Avionics */

{{:{{PAGENAME}}/info}}
The '''Cessna 337''' is a twin-engine [[aircraft]] built in a push-pull configuration. Instead of the engines being mounted on the wings, one is mounted on the nose and the other at the rear of the pod-style fuselage. The stabilizers are mounted on booms that extend from the wings. The Skymaster has a retractable undercarriage that gives it that little bit of extra speed.

The combination of a tractor and a pusher engine produces a unique sound.

== Aircraft help ==

=== Aircraft keys ===
{| class="keytable"
! Key !! Function
|-
| {{key press|d}} || Open/close cockpit door
|-
| {{key press|c}} || Open/close front cowl flaps
|-
| {{key press|C}} || Open/close rear cowl flaps
|-
| {{key press|m}}/{{key press|Shift|M}} || Adjust fuel mixture
|-
| {{key press|n}}/{{key press|Shift|N}} || Adjust speed governor (propeller pitch)
|}

=== Limits ===

* '''V<sub>NE</sub>:''' 198 KIAS ''(Never exceed speed)''
* '''V<sub>NO</sub>:''' 167 KIAS ''(Max. speed for normal operations)''
* '''V<sub>A</sub>:''' 140 KIAS ''(Design maneuvering speed)''
* '''V<sub>FE</sub>:''' 109 KIAS ''(Max. full flap extended speed)''
* '''V<sub>LE</sub>:''' 200 KIAS ''(Max. landing gear extended speed)''
* '''V<sub>LO</sub>:''' 140 KIAS ''(Max. landing gear extend/retract speed)''
* '''Stall''' speed, full flaps: 61 KIAS
* '''Stall''' speed, zero flaps: 70 KIAS
* '''Max. weight:''' 4630 lbs. ''(2100 kg)''
* '''Service ceiling (two engines):''' 18,000 ft
* '''Ground run for takeoff:''' 1,000 ft
* '''Ground roll for landing''' 700 ft

== Normal procedures==
[[File:Cessna337-details.png|thumb|250px|The model is pretty detailed, and users can select between 5 HQ liveries]]
[[File:Cessna337-night.png|thumb|250px|Nice view of the Skymaster cockpit at night]]

=== Startup ===
* Turn ON battery and front and rear generators
* Turn ON master avionics button (left wall panel)
* Turn ON the avionics (NAV/COMM Radios, DME, ADF...)
* Turn ON fuel pumps (not implemented yet)
* Turn ON required lights and pitot heat
* Open front and rear cowl flaps
* Turn ON rear magnetos (mouse wheel), continue turning the knob for starter (left button)
* Turn ON front magnetos, continue turning the knob for starter

=== Takeoff ===
* Check open front & rear cowl flaps to avoid overheating
* Check rich mixture and high RPM speed governor (propeller pitch)
* Full trhottle, release brakes
* Rotate at 60 KIAS
* Retract gear

=== Cruise ===
The Cessna 337 Skymaster has a constant-speed propeller; so, you can increase propeller pitch to get more airspeed, but with a loss of engine RPM and power.
* Decrease throttle to desired power
* Decrease RPM with speed governor (propeller pitch)
* Adjust mixture depending on flight altitude (for 5000ft or more). Check EGT for best mixture.
* Close cowl flaps

=== Landing ===
* Open cowl flaps
* Increase RPM with speed governor (propeller pitch) to maximum
* Reduce power with throttle
* Open landing gear
* Deploy flaps gradually under 110 KIAS
* Touchdown at 75/60 KIAS, depending on aircraft weight

== Systems ==
[[File:Cessna337-avionics.png|thumb|250px|Detail of the avionics panel]]

The Cessna 337 still in development, but it has some suitable systems. Electrical, vacuum and fuel system are working, but they have no failure system modelled yet. Users can adjust the weight of each seat on the plane and fuel amount. Almost all buttons, knobs and levers are functional and properly animated, and all instruments are labeled for a properly identification.

About knobs, use scroll mouse for gross adjustments, and left-central buttons for fine tunning. When setting radio frequencies, the mouse scroll will adjust integral numbers, and buttons will tune decimals. Try that method with instruments, cowl flap switches, trim levers, magnetos, etc.

=== Avionics ===

The Skymaster release is provided with a working Bendix/King avionics pack, capable of full IFR/night navigation:

* 2 KX-155 COMM/NAV Radios, attached to a pair of KI-206 VOR locators
* KN-62A DME receiver with internal frequency hold and NAV1 remote operation
* KR-87 ADF receiver, attached to a KI-227 ADF locator
* KMA-24 Audio panel
* KT-76A Transponder, with radar sweep simulation
* KI-250 Radar altimeter, capable to mark decision height for low-visibility landings
* Hobbs Meter

{{Note|A full KMA24 audio panel implementation was added in January 2017. The knob on the right of the unit switches the speaker amplifier on and off and also controls the marker beacon receiver. To hear ATIS broadcasts, either switch the comm radio output using the COMM phone switch, or use the COMM speaker switch with the knob in any position other than off. To hear marker beacon idents, the knob must be in any other position than off and one of the MKR switches selected on the panel.}}

Radio stack instruments are modelled according to the Bendix King pilot guides. Refer to those guides for operating instructions. [http://www.bendixking.com/HWL/media/Pilot-Guides/006-18110-0000_5.pdf]

=== Autopilot ===

The [[Cessna 337G Skymaster/Navomatic 400A]] autopilot has a fully working 3D panel and dialog.

=== ELT ===

The [[ELT]] (Emergency Locator Transmitter) is a device which send a message in case of aircraft crash. That message contains info about aircraft model, owner and approximate coordinates of the crashed plane, and it is made to request SAR (Search and Rescue) services. The Cessna Skymaster is the first plane equiped with a functional ELT on FlightGear.

== External links ==
* [http://forum.flightgear.org/viewtopic.php?f=4&t=12733 Cessna 337G official forum post]
* [http://www.youtube.com/watch?v=-ijJa0G5NgQ Video Cessna 337G MPG HD]
* [http://www.bendixking.com/HWL/media/Pilot-Guides/006-18110-0000_5.pdf Bendix King Silver Crown Plus Avionics Systems Pilot’s Guide]

{{Cessna}}

[[de:Cessna 337G Skymaster]]
[[es:Cessna 337G Skymaster]]
[[fr:Cessna 337G Skymaster]]

Cessna 337G Skymaster

2017-01-14T13:26:38Z

Sanhozay: /* Avionics */

{{:{{PAGENAME}}/info}}
The '''Cessna 337''' is a twin-engine [[aircraft]] built in a push-pull configuration. Instead of the engines being mounted on the wings, one is mounted on the nose and the other at the rear of the pod-style fuselage. The stabilizers are mounted on booms that extend from the wings. The Skymaster has a retractable undercarriage that gives it that little bit of extra speed.

The combination of a tractor and a pusher engine produces a unique sound.

== Aircraft help ==

=== Aircraft keys ===
{| class="keytable"
! Key !! Function
|-
| {{key press|d}} || Open/close cockpit door
|-
| {{key press|c}} || Open/close front cowl flaps
|-
| {{key press|C}} || Open/close rear cowl flaps
|-
| {{key press|m}}/{{key press|Shift|M}} || Adjust fuel mixture
|-
| {{key press|n}}/{{key press|Shift|N}} || Adjust speed governor (propeller pitch)
|}

=== Limits ===

* '''V<sub>NE</sub>:''' 198 KIAS ''(Never exceed speed)''
* '''V<sub>NO</sub>:''' 167 KIAS ''(Max. speed for normal operations)''
* '''V<sub>A</sub>:''' 140 KIAS ''(Design maneuvering speed)''
* '''V<sub>FE</sub>:''' 109 KIAS ''(Max. full flap extended speed)''
* '''V<sub>LE</sub>:''' 200 KIAS ''(Max. landing gear extended speed)''
* '''V<sub>LO</sub>:''' 140 KIAS ''(Max. landing gear extend/retract speed)''
* '''Stall''' speed, full flaps: 61 KIAS
* '''Stall''' speed, zero flaps: 70 KIAS
* '''Max. weight:''' 4630 lbs. ''(2100 kg)''
* '''Service ceiling (two engines):''' 18,000 ft
* '''Ground run for takeoff:''' 1,000 ft
* '''Ground roll for landing''' 700 ft

== Normal procedures==
[[File:Cessna337-details.png|thumb|250px|The model is pretty detailed, and users can select between 5 HQ liveries]]
[[File:Cessna337-night.png|thumb|250px|Nice view of the Skymaster cockpit at night]]

=== Startup ===
* Turn ON battery and front and rear generators
* Turn ON master avionics button (left wall panel)
* Turn ON the avionics (NAV/COMM Radios, DME, ADF...)
* Turn ON fuel pumps (not implemented yet)
* Turn ON required lights and pitot heat
* Open front and rear cowl flaps
* Turn ON rear magnetos (mouse wheel), continue turning the knob for starter (left button)
* Turn ON front magnetos, continue turning the knob for starter

=== Takeoff ===
* Check open front & rear cowl flaps to avoid overheating
* Check rich mixture and high RPM speed governor (propeller pitch)
* Full trhottle, release brakes
* Rotate at 60 KIAS
* Retract gear

=== Cruise ===
The Cessna 337 Skymaster has a constant-speed propeller; so, you can increase propeller pitch to get more airspeed, but with a loss of engine RPM and power.
* Decrease throttle to desired power
* Decrease RPM with speed governor (propeller pitch)
* Adjust mixture depending on flight altitude (for 5000ft or more). Check EGT for best mixture.
* Close cowl flaps

=== Landing ===
* Open cowl flaps
* Increase RPM with speed governor (propeller pitch) to maximum
* Reduce power with throttle
* Open landing gear
* Deploy flaps gradually under 110 KIAS
* Touchdown at 75/60 KIAS, depending on aircraft weight

== Systems ==
[[File:Cessna337-avionics.png|thumb|250px|Detail of the avionics panel]]

The Cessna 337 still in development, but it has some suitable systems. Electrical, vacuum and fuel system are working, but they have no failure system modelled yet. Users can adjust the weight of each seat on the plane and fuel amount. Almost all buttons, knobs and levers are functional and properly animated, and all instruments are labeled for a properly identification.

About knobs, use scroll mouse for gross adjustments, and left-central buttons for fine tunning. When setting radio frequencies, the mouse scroll will adjust integral numbers, and buttons will tune decimals. Try that method with instruments, cowl flap switches, trim levers, magnetos, etc.

=== Avionics ===

The Skymaster release is provided with a working Bendix/King avionics pack, capable of full IFR/night navigation:

* 2 KX-155 COMM/NAV Radios, attached to a pair of KI-206 VOR locators
* KN-62A DME receiver with internal frequency hold and NAV1 remote operation
* KR-87 ADF receiver, attached to a KI-227 ADF locator
* KMA-24 Audio panel
* KT-76A Transponder, with radar sweep simulation
* KI-250 Radar altimeter, capable to mark decision height for low-visibility landings
* Hobbs Meter

{{Note|A full KMA24 audio panel implementation was added in January 2017. The knob on the right of the unit switches the speaker amplifier on and off and also controls the marker beacon receiver. To hear ATIS broadcasts, either switch the comm radio output using the COMM phone switch, or use the COMM speaker switch with the knob in any position other than off. To hear marker beacon idents, the knob must be in any other position than off and one of the MKR switches selected on the panel.}}

Radio stack instruments are modelled according to the Bendix King pilot guides. Refer to those guides for operating instructions.

=== Autopilot ===

The [[Cessna 337G Skymaster/Navomatic 400A]] autopilot has a fully working 3D panel and dialog.

=== ELT ===

The [[ELT]] (Emergency Locator Transmitter) is a device which send a message in case of aircraft crash. That message contains info about aircraft model, owner and approximate coordinates of the crashed plane, and it is made to request SAR (Search and Rescue) services. The Cessna Skymaster is the first plane equiped with a functional ELT on FlightGear.

== External links ==
* [http://forum.flightgear.org/viewtopic.php?f=4&t=12733 Cessna 337G official forum post]
* [http://www.youtube.com/watch?v=-ijJa0G5NgQ Video Cessna 337G MPG HD]
* [http://www.bendixking.com/HWL/media/Pilot-Guides/006-18110-0000_5.pdf Bendix King Silver Crown Plus Avionics Systems Pilot’s Guide]

{{Cessna}}

[[de:Cessna 337G Skymaster]]
[[es:Cessna 337G Skymaster]]
[[fr:Cessna 337G Skymaster]]

Cessna 337G Skymaster

2017-01-14T13:20:30Z

Sanhozay: /* External links */

{{:{{PAGENAME}}/info}}
The '''Cessna 337''' is a twin-engine [[aircraft]] built in a push-pull configuration. Instead of the engines being mounted on the wings, one is mounted on the nose and the other at the rear of the pod-style fuselage. The stabilizers are mounted on booms that extend from the wings. The Skymaster has a retractable undercarriage that gives it that little bit of extra speed.

The combination of a tractor and a pusher engine produces a unique sound.

== Aircraft help ==

=== Aircraft keys ===
{| class="keytable"
! Key !! Function
|-
| {{key press|d}} || Open/close cockpit door
|-
| {{key press|c}} || Open/close front cowl flaps
|-
| {{key press|C}} || Open/close rear cowl flaps
|-
| {{key press|m}}/{{key press|Shift|M}} || Adjust fuel mixture
|-
| {{key press|n}}/{{key press|Shift|N}} || Adjust speed governor (propeller pitch)
|}

=== Limits ===

* '''V<sub>NE</sub>:''' 198 KIAS ''(Never exceed speed)''
* '''V<sub>NO</sub>:''' 167 KIAS ''(Max. speed for normal operations)''
* '''V<sub>A</sub>:''' 140 KIAS ''(Design maneuvering speed)''
* '''V<sub>FE</sub>:''' 109 KIAS ''(Max. full flap extended speed)''
* '''V<sub>LE</sub>:''' 200 KIAS ''(Max. landing gear extended speed)''
* '''V<sub>LO</sub>:''' 140 KIAS ''(Max. landing gear extend/retract speed)''
* '''Stall''' speed, full flaps: 61 KIAS
* '''Stall''' speed, zero flaps: 70 KIAS
* '''Max. weight:''' 4630 lbs. ''(2100 kg)''
* '''Service ceiling (two engines):''' 18,000 ft
* '''Ground run for takeoff:''' 1,000 ft
* '''Ground roll for landing''' 700 ft

== Normal procedures==
[[File:Cessna337-details.png|thumb|250px|The model is pretty detailed, and users can select between 5 HQ liveries]]
[[File:Cessna337-night.png|thumb|250px|Nice view of the Skymaster cockpit at night]]

=== Startup ===
* Turn ON battery and front and rear generators
* Turn ON master avionics button (left wall panel)
* Turn ON the avionics (NAV/COMM Radios, DME, ADF...)
* Turn ON fuel pumps (not implemented yet)
* Turn ON required lights and pitot heat
* Open front and rear cowl flaps
* Turn ON rear magnetos (mouse wheel), continue turning the knob for starter (left button)
* Turn ON front magnetos, continue turning the knob for starter

=== Takeoff ===
* Check open front & rear cowl flaps to avoid overheating
* Check rich mixture and high RPM speed governor (propeller pitch)
* Full trhottle, release brakes
* Rotate at 60 KIAS
* Retract gear

=== Cruise ===
The Cessna 337 Skymaster has a constant-speed propeller; so, you can increase propeller pitch to get more airspeed, but with a loss of engine RPM and power.
* Decrease throttle to desired power
* Decrease RPM with speed governor (propeller pitch)
* Adjust mixture depending on flight altitude (for 5000ft or more). Check EGT for best mixture.
* Close cowl flaps

=== Landing ===
* Open cowl flaps
* Increase RPM with speed governor (propeller pitch) to maximum
* Reduce power with throttle
* Open landing gear
* Deploy flaps gradually under 110 KIAS
* Touchdown at 75/60 KIAS, depending on aircraft weight

== Systems ==
[[File:Cessna337-avionics.png|thumb|250px|Detail of the avionics panel]]

The Cessna 337 still in development, but it has some suitable systems. Electrical, vacuum and fuel system are working, but they have no failure system modelled yet. Users can adjust the weight of each seat on the plane and fuel amount. Almost all buttons, knobs and levers are functional and properly animated, and all instruments are labeled for a properly identification.

About knobs, use scroll mouse for gross adjustments, and left-central buttons for fine tunning. When setting radio frequencies, the mouse scroll will adjust integral numbers, and buttons will tune decimals. Try that method with instruments, cowl flap switches, trim levers, magnetos, etc.

=== Avionics ===

The Skymaster release is provided with a working Bendix/King avionics pack, capable of full IFR/night navigation:

* 2 KX-155 COMM/NAV Radios, attached to a pair of KI-206 VOR locators
* KN-62A DME receiver with internal frequency hold and NAV1 remote operation
* KR-87 ADF receiver, attached to a KI-227 ADF locator
* KMA-24 Audio panel
* KT-76A Transponder, with radar sweep simulation
* KI-250 Radar altimeter, capable to mark decision height for low-visibility landings
* Hobbs Meter

Radio stack instruments are modelled according to the Bendix King pilot guides. Refer to those guides for operating instructions.

=== Autopilot ===

The [[Cessna 337G Skymaster/Navomatic 400A]] autopilot has a fully working 3D panel and dialog.

=== ELT ===

The [[ELT]] (Emergency Locator Transmitter) is a device which send a message in case of aircraft crash. That message contains info about aircraft model, owner and approximate coordinates of the crashed plane, and it is made to request SAR (Search and Rescue) services. The Cessna Skymaster is the first plane equiped with a functional ELT on FlightGear.

== External links ==
* [http://forum.flightgear.org/viewtopic.php?f=4&t=12733 Cessna 337G official forum post]
* [http://www.youtube.com/watch?v=-ijJa0G5NgQ Video Cessna 337G MPG HD]
* [http://www.bendixking.com/HWL/media/Pilot-Guides/006-18110-0000_5.pdf Bendix King Silver Crown Plus Avionics Systems Pilot’s Guide]

{{Cessna}}

[[de:Cessna 337G Skymaster]]
[[es:Cessna 337G Skymaster]]
[[fr:Cessna 337G Skymaster]]

Cessna 337G Skymaster

2017-01-14T13:19:27Z

Sanhozay: /* Avionics */

{{:{{PAGENAME}}/info}}
The '''Cessna 337''' is a twin-engine [[aircraft]] built in a push-pull configuration. Instead of the engines being mounted on the wings, one is mounted on the nose and the other at the rear of the pod-style fuselage. The stabilizers are mounted on booms that extend from the wings. The Skymaster has a retractable undercarriage that gives it that little bit of extra speed.

The combination of a tractor and a pusher engine produces a unique sound.

== Aircraft help ==

=== Aircraft keys ===
{| class="keytable"
! Key !! Function
|-
| {{key press|d}} || Open/close cockpit door
|-
| {{key press|c}} || Open/close front cowl flaps
|-
| {{key press|C}} || Open/close rear cowl flaps
|-
| {{key press|m}}/{{key press|Shift|M}} || Adjust fuel mixture
|-
| {{key press|n}}/{{key press|Shift|N}} || Adjust speed governor (propeller pitch)
|}

=== Limits ===

* '''V<sub>NE</sub>:''' 198 KIAS ''(Never exceed speed)''
* '''V<sub>NO</sub>:''' 167 KIAS ''(Max. speed for normal operations)''
* '''V<sub>A</sub>:''' 140 KIAS ''(Design maneuvering speed)''
* '''V<sub>FE</sub>:''' 109 KIAS ''(Max. full flap extended speed)''
* '''V<sub>LE</sub>:''' 200 KIAS ''(Max. landing gear extended speed)''
* '''V<sub>LO</sub>:''' 140 KIAS ''(Max. landing gear extend/retract speed)''
* '''Stall''' speed, full flaps: 61 KIAS
* '''Stall''' speed, zero flaps: 70 KIAS
* '''Max. weight:''' 4630 lbs. ''(2100 kg)''
* '''Service ceiling (two engines):''' 18,000 ft
* '''Ground run for takeoff:''' 1,000 ft
* '''Ground roll for landing''' 700 ft

== Normal procedures==
[[File:Cessna337-details.png|thumb|250px|The model is pretty detailed, and users can select between 5 HQ liveries]]
[[File:Cessna337-night.png|thumb|250px|Nice view of the Skymaster cockpit at night]]

=== Startup ===
* Turn ON battery and front and rear generators
* Turn ON master avionics button (left wall panel)
* Turn ON the avionics (NAV/COMM Radios, DME, ADF...)
* Turn ON fuel pumps (not implemented yet)
* Turn ON required lights and pitot heat
* Open front and rear cowl flaps
* Turn ON rear magnetos (mouse wheel), continue turning the knob for starter (left button)
* Turn ON front magnetos, continue turning the knob for starter

=== Takeoff ===
* Check open front & rear cowl flaps to avoid overheating
* Check rich mixture and high RPM speed governor (propeller pitch)
* Full trhottle, release brakes
* Rotate at 60 KIAS
* Retract gear

=== Cruise ===
The Cessna 337 Skymaster has a constant-speed propeller; so, you can increase propeller pitch to get more airspeed, but with a loss of engine RPM and power.
* Decrease throttle to desired power
* Decrease RPM with speed governor (propeller pitch)
* Adjust mixture depending on flight altitude (for 5000ft or more). Check EGT for best mixture.
* Close cowl flaps

=== Landing ===
* Open cowl flaps
* Increase RPM with speed governor (propeller pitch) to maximum
* Reduce power with throttle
* Open landing gear
* Deploy flaps gradually under 110 KIAS
* Touchdown at 75/60 KIAS, depending on aircraft weight

== Systems ==
[[File:Cessna337-avionics.png|thumb|250px|Detail of the avionics panel]]

The Cessna 337 still in development, but it has some suitable systems. Electrical, vacuum and fuel system are working, but they have no failure system modelled yet. Users can adjust the weight of each seat on the plane and fuel amount. Almost all buttons, knobs and levers are functional and properly animated, and all instruments are labeled for a properly identification.

About knobs, use scroll mouse for gross adjustments, and left-central buttons for fine tunning. When setting radio frequencies, the mouse scroll will adjust integral numbers, and buttons will tune decimals. Try that method with instruments, cowl flap switches, trim levers, magnetos, etc.

=== Avionics ===

The Skymaster release is provided with a working Bendix/King avionics pack, capable of full IFR/night navigation:

* 2 KX-155 COMM/NAV Radios, attached to a pair of KI-206 VOR locators
* KN-62A DME receiver with internal frequency hold and NAV1 remote operation
* KR-87 ADF receiver, attached to a KI-227 ADF locator
* KMA-24 Audio panel
* KT-76A Transponder, with radar sweep simulation
* KI-250 Radar altimeter, capable to mark decision height for low-visibility landings
* Hobbs Meter

Radio stack instruments are modelled according to the Bendix King pilot guides. Refer to those guides for operating instructions.

=== Autopilot ===

The [[Cessna 337G Skymaster/Navomatic 400A]] autopilot has a fully working 3D panel and dialog.

=== ELT ===

The [[ELT]] (Emergency Locator Transmitter) is a device which send a message in case of aircraft crash. That message contains info about aircraft model, owner and approximate coordinates of the crashed plane, and it is made to request SAR (Search and Rescue) services. The Cessna Skymaster is the first plane equiped with a functional ELT on FlightGear.

== External links ==
* [http://forum.flightgear.org/viewtopic.php?f=4&t=12733 Cessna 337G official forum post]
* [http://www.youtube.com/watch?v=-ijJa0G5NgQ Video Cessna 337G MPG HD]

{{Cessna}}

[[de:Cessna 337G Skymaster]]
[[es:Cessna 337G Skymaster]]
[[fr:Cessna 337G Skymaster]]

Autopilot configuration reference

2016-12-18T12:34:39Z

Sanhozay: /* State Machine <state-machine> */

{{Systems_Modeling_Disclaimer}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

to the

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

<autopilot>
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path>
</autopilot>
</systems>
</sim>
</syntaxhighlight>

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

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

To achieve this load your filters configuration by adding:

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

to the :

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

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

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

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

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

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



</PropertyList>
</syntaxhighlight>

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

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

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

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

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

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

== Common elements used by all elements ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The shortcut syntax is also valid:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example: simple RS flip flop

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

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

Example: simple JK flip flop with negative edge clock

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

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

Example: simple D flip flop with inverted output

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

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

Example: simple T flip flop

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

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

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

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

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

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

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

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

== Filters <filter> ==

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

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

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

Example: a 1Hz first order low pass filter

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

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

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

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

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

Example: a 1Hz first order high pass filter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example: compute derivative of static port pressure

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

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

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

Legal elements are:

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

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

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

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

Legal elements are:

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

Example: compute estimated speed 5 seconds ahead

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

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

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

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

Legal elements for the state machine are:

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

Legal elements for the state element are:

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

Legal elements for the transition element are:

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

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

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

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

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

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

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

[[Category:Aircraft enhancement]]

Beagle Pup

2016-12-06T15:50:34Z

Sanhozay: /* Icing Simulation */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 60 knots. Raise flaps around 300ft AGL and trim for steady climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 80 knots, with power reduction to around 1800rpm and the first step of flaps lowered prior to the base turn. Mixture full rich and carb heat hot. Landing speed is around 70 knots with landing flaps lowered on final to bring the nose down for a better view of the runway.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Table of V Speeds ===

{| class="wikitable"
! Designator !! Description !! IAS (knots)
|-
| V<sub>S0</sub> || Stall speed in landing configuration (landing flaps) || style="text-align:right;" | 54
|-
| V<sub>S</sub> || Stall speed in cruise configuration (no flaps) || style="text-align:right;" | 63
|-
| V<sub>Ref</sub> || Landing reference speed (1.3 x V<sub>S0</sub>) || style="text-align:right;" | 70
|-
| V<sub>FE</sub> || Maximum flap extension speed || style="text-align:right;" | 100
|-
| V<sub>NO</sub> || Maximum speed for normal operations || style="text-align:right;" | 120
|-
| V<sub>NE</sub> || Never exceed speed || style="text-align:right;" | 150
|}

== Icing Simulation ==

=== Carburettor Temperature ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

=== Pitot Temperature ===

''Available from aircraft version 0.28.0 onwards''

As per the carburettor icing, this feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. The same comments apply regarding turning off the simulation when the tube is iced.

Pitot heat should be applied when flying in freezing conditions with high levels of moisture present. Icing is most likely to occur when descending from freezing temperatures through warmer moist air, so remember to apply pitot heat before descent. The pitot heater is switched on using the rightmost circuit breaker on the electrical panel.

The symptom of pitot ice is a steady reduction in indicated airspeed. The simulation reduces the pressure reported by the pitot system which in turn affects the airspeed indicator. When icing reaches its maximum level, the tube is simulated as blocked, i.e. the water drain hole is plugged as well as the tube. This causes the pressure reported by the pitot system to remain constant and the airspeed indicator, driven only by the static system, behaves like an altimeter. Applying pitot heat clears the ice in a couple of minutes and the airspeed indicator should return to normal. Pitot heat should be turned off when moving slowly, i.e. when taxiing, to avoid overheating the pitot tube, but this is not yet simulated.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]
* [https://www.flightglobal.com/FlightPDFArchive/1968/1968%20-%200659.PDF Beagle Pup Performance]

Beagle Pup

2016-12-06T13:58:33Z

Sanhozay:

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 60 knots. Raise flaps around 300ft AGL and trim for steady climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 80 knots, with power reduction to around 1800rpm and the first step of flaps lowered prior to the base turn. Mixture full rich and carb heat hot. Landing speed is around 70 knots with landing flaps lowered on final to bring the nose down for a better view of the runway.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Table of V Speeds ===

{| class="wikitable"
! Designator !! Description !! IAS (knots)
|-
| V<sub>S0</sub> || Stall speed in landing configuration (landing flaps) || style="text-align:right;" | 54
|-
| V<sub>S</sub> || Stall speed in cruise configuration (no flaps) || style="text-align:right;" | 63
|-
| V<sub>Ref</sub> || Landing reference speed (1.3 x V<sub>S0</sub>) || style="text-align:right;" | 70
|-
| V<sub>FE</sub> || Maximum flap extension speed || style="text-align:right;" | 100
|-
| V<sub>NO</sub> || Maximum speed for normal operations || style="text-align:right;" | 120
|-
| V<sub>NE</sub> || Never exceed speed || style="text-align:right;" | 150
|}

== Icing Simulation ==

=== Carburettor Temperature ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]
* [https://www.flightglobal.com/FlightPDFArchive/1968/1968%20-%200659.PDF Beagle Pup Performance]

Beagle Pup

2016-12-04T11:08:23Z

Sanhozay: /* Flight Notes */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 60 knots. Raise flaps around 300ft AGL and trim for steady climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 80 knots, with power reduction to around 1800rpm and the first step of flaps lowered prior to the base turn. Mixture full rich and carb heat hot. Landing speed is around 70 knots with landing flaps lowered on final to bring the nose down for a better view of the runway.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Table of V Speeds ===

{| class="wikitable"
! Designator !! Description !! IAS (knots)
|-
| V<sub>S0</sub> || Stall speed in landing configuration (landing flaps) || style="text-align:right;" | 54
|-
| V<sub>S</sub> || Stall speed in cruise configuration (no flaps) || style="text-align:right;" | 63
|-
| V<sub>Ref</sub> || Landing reference speed (1.3 x V<sub>S0</sub>) || style="text-align:right;" | 70
|-
| V<sub>FE</sub> || Maximum flap extension speed || style="text-align:right;" | 100
|-
| V<sub>NO</sub> || Maximum speed for normal operations || style="text-align:right;" | 120
|-
| V<sub>NE</sub> || Never exceed speed || style="text-align:right;" | 150
|}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]
* [https://www.flightglobal.com/FlightPDFArchive/1968/1968%20-%200659.PDF Beagle Pup Performance]

Beagle Pup

2016-12-04T11:07:28Z

Sanhozay: /* Table of V Speeds */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 60 knots. Raise flaps around 300ft AGL and trim for steady climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 80 knots, with power reduction to around 1800rpm and the first step of flaps lowered prior to the base turn. Mixture full rich and carb heat hot. Landing speed is around 70 knots with landing flaps lowered on final to bring the nose down for a better view of the runway.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Table of V Speeds ===

{| class="wikitable"
! Designator !! Description !! IAS (knots)
|-
| V<sub>S0</sub> || Stall speed in landing configuration (landing flaps) || style="text-align:right;" | 54
|-
| V<sub>S</sub> || Stall speed in cruise configuration (no flaps) || style="text-align:right;" | 63
|-
| V<sub>Ref</sub> || Landing reference speed (1.3 x V<sub>S0</sub>) || style="text-align:right;" | 70
|-
| V<sub>FE</sub> || Maximum flap extension speed || style="text-align:right;" | 100
|-
| V<sub>NO</sub> || Maximum speed for normal operations || style="text-align:right;" | 120
|-
| V<sub>NE</sub> || Never exceed speed || style="text-align:right;" | 150
|}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]
* [https://www.flightglobal.com/FlightPDFArchive/1968/1968%20-%200659.PDF Beagle Pup Performance]

Beagle Pup

2016-11-26T18:10:01Z

Sanhozay: /* External links */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 65 knots. Raise flaps on positive climb and trim for climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 70-80 knots, with the first step of flaps lowered during the downwind leg. Mixture full rich and carb heat full. Landing speed is around 60-65 knots and landing flaps can be lowered to bring the nose down for a better view of the runway. Stall speed with flaps is around 50 knots.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]
* [https://www.flightglobal.com/FlightPDFArchive/1968/1968%20-%200659.PDF Beagle Pup Performance]

Beagle Pup

2016-11-26T18:07:51Z

Sanhozay: /* Development Status/Issues/Todo */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 65 knots. Raise flaps on positive climb and trim for climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 70-80 knots, with the first step of flaps lowered during the downwind leg. Mixture full rich and carb heat full. Landing speed is around 60-65 knots and landing flaps can be lowered to bring the nose down for a better view of the runway. Stall speed with flaps is around 50 knots.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues ==

=== FDM ===

There are some issues with keyboard control and flight characteristics outside of the normal flight envelope. Stalls near the ground are lethal. Behaviour in moderate to fresh crosswinds and above (> 15kts) is troublesome on the ground.

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Beagle Pup

2016-11-26T17:59:31Z

Sanhozay: /* Sperry SP3 in the Beagle Pup */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 65 knots. Raise flaps on positive climb and trim for climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 70-80 knots, with the first step of flaps lowered during the downwind leg. Mixture full rich and carb heat full. Landing speed is around 60-65 knots and landing flaps can be lowered to bring the nose down for a better view of the runway. Stall speed with flaps is around 50 knots.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Ctrl-z toggles the main autopilot on/off switch and Ctrl-a toggles the altitude hold button, which will only work iff the pitch wheel is at its center detent position. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Beagle Pup

2016-11-26T17:57:48Z

Sanhozay: /* Flight Notes */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants and the 3D cockpit, while having many of the correct instruments, has a temporary layout.

Systems are relatively mature, including fuel and electrical systems. Autostart executes the startup checklists and puts the aircraft in a ready for taxi or takeoff state, depending on starting location. Some basic cockpit lighting is provided for night flying.

Takeoff with the first step of flaps, full power and rotate at around 65 knots. Raise flaps on positive climb and trim for climb rates of around 500fpm for the Pup 100 and 800fpm for the Pup 150 and 160. Adjust mixture for maximum RPM to maximize rate of climb. When approaching cruise altitude, lean mixture to 50*F rich of peak (which should be where the asterisk is on the EGT gauge), level off and adjust throttle for 2500rpm.

Approach at around 70-80 knots, with the first step of flaps lowered during the downwind leg. Mixture full rich and carb heat full. Landing speed is around 60-65 knots and landing flaps can be lowered to bring the nose down for a better view of the runway. Stall speed with flaps is around 50 knots.

The checklists are 95% accurate with respect to normal operating procedures. Performance, including fuel consumption, is within 10% of quoted at level speeds at various altitudes and RPMs. The FDM is a stock Aeromatic++ FDM tuned to performance specifications.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Beagle Pup

2016-11-26T17:41:26Z

Sanhozay: /* Series 2 (Beagle Pup 150) */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots (TAS). Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Beagle Pup

2016-11-26T17:40:23Z

Sanhozay: /* Series 1 (Beagle Pup 100) */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of 90-95 knots (TAS). Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Beagle Pup

2016-11-22T13:19:08Z

Sanhozay: /* Flight Notes */

{{:{{PAGENAME}}/info}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

{{Note|A bug introduced in v0.22.2 caused incorrect adjustment of payload weights. This is fixed in 0.23.1 but it is recommended to delete the saved state in FG_HOME/aircraft-data/pup*.xml to avoid unexpected changes to center of gravity and aircraft stability.}}

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

Changelog 2016.2

2016-05-08T09:03:18Z

Sanhozay: /* Highlighted new and improved aircraft */

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.2 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}




=== Changed default location ===
In line with the release adopted in FlightGear v2016.1, this release has been named after its default airport, [[Barcelona–El Prat Airport|Barcelona Airport]] (LEBL).

=== Major enhancements in this release ===
==== Core ====
* Video configuration can be saved.<ref>http://forum.flightgear.org/viewtopic.php?f=37&t=29122</ref><ref>https://sourceforge.net/p/flightgear/fgdata/ci/0d623d/</ref>
* The [[TerraSync]] server has been switched to using HTTP instead of SVN.
* All scenery models have been cleaned up and moved to TerraSync.

==== Aircraft Modeling ====

==== ATIS and METAR ====
* Various improvements in the reporting of wind, atmospheric pressure, and sky cover.
* Custom ATIS formats for the US/Canada/Pacific region and the UK based on real recordings.
* Bug fixes and data updates to reduce occurrence of NIL weather.

==== JSBSim ====

==== Atmospheric Light Scattering ====
* Filters have been added, enabling infrared and night-vision views
* [[ALS technical notes#ALS procedural lights|ALS procedural lights]]

==== Environment Rendering ====

* A bug that prevented precipitation from appearing has been fixed.

==== Performance ====

==== Multiplayer ====
* A bug in the multiplayer protocol has been {{flightgear commit|4f8cbb|t=fixed}}.

==== Misc/Uncategorized ====

==== Usability ====

* Route manager now allows entry of a space separated list of waypoints.

==== Internationalization ====
* The Italian translation for menus, loading messages and help for command line switches has been updated.

==== Scenery ====
* Further improvements to regional textures.
* New buildings for London Heathrow

==== Canvas System ====

==== Nasal Scripting ====
* A bug in {{func link|math.clamp()|page=Nasal library/math}} has been {{fgdata commit|bba11c|t=fixed}}.

==== Documentation ====

==== Highlighted new and improved aircraft ====
* [[Parachutist]]
* [[Piper J3 Cub]]
* [[Boeing 757]]
* [[Extra EA-500]]
* [[Saab JA-37 Viggen]]
* [https://forum.flightgear.org/viewtopic.php?f=4&t=28475 Cessna 182S Skylane]
* [[Space Shuttle]]
* Boeing 757
* [[Beagle Pup]]

==== Other ====
===== FGPromo: A FlightGear Promotional Video =====
After more than 5 months of hard work, FGPromo, a video showing off FlightGear at its finest, has been released!
{{#ev:youtube|yPBdJT2Pkdc||center}}

==== Bug fixes ====
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=%21ticket_num%3A437+AND+status%3AFixed+AND+mod_date%3A%5B2016-02-17T00%3A00%3A00Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Changelog 2016.2

2016-05-06T07:06:27Z

Sanhozay: /* Usability */

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.2 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}




=== Changed default location ===
In line with the release adopted in FlightGear v2016.1, this release has been named after its default airport, [[Barcelona–El Prat Airport|Barcelona Airport]] (LEBL).

=== Major enhancements in this release ===
==== Core ====
* Video configuration can be saved.<ref>http://forum.flightgear.org/viewtopic.php?f=37&t=29122</ref><ref>https://sourceforge.net/p/flightgear/fgdata/ci/0d623d/</ref>
* The [[TerraSync]] server has been switched to using HTTP instead of SVN.
* All scenery models have been cleaned up and moved to TerraSync.

==== Aircraft Modeling ====

==== ATIS and METAR ====
* Various improvements in the reporting of wind, atmospheric pressure, and sky cover.
* Custom ATIS formats for the US/Canada/Pacific region and the UK based on real recordings.
* Bug fixes and data updates to reduce occurrence of NIL weather.

==== JSBSim ====

==== Atmospheric Light Scattering ====
* Filters have been added, enabling infrared and night-vision views

==== Environment Rendering ====

* A bug that prevented precipitation from appearing has been fixed.

==== Performance ====

==== Multiplayer ====
* A bug in the multiplayer protocol has been {{flightgear commit|4f8cbb|t=fixed}}.

==== Misc/Uncategorized ====

==== Usability ====

* Route manager now allows entry of a space separated list of waypoints.

==== Internationalization ====
* The Italian translation for menus, loading messages and help for command line switches has been updated.

==== Scenery ====

==== Canvas System ====

==== Nasal Scripting ====
* A bug in {{func link|math.clamp()|page=Nasal library/math}} has been {{fgdata commit|bba11c|t=fixed}}.

==== Documentation ====

==== Highlighted new and improved aircraft ====
* [[Parachutist]]
* [[Piper J3 Cub]]
* [[Boeing 757]]
* [[Extra EA-500]]

==== Other ====

==== Bug fixes ====
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=ticket_num%3A%5B1000+TO+*%5D+AND+%21ticket_num%3A437+AND+status%3AFixed+AND+mod_date%3A%5B2016-02-17T00%3A00%3A00Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Changelog 2016.2

2016-05-06T07:05:54Z

Sanhozay: /* Usability */

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.2 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}




=== Changed default location ===
In line with the release adopted in FlightGear v2016.1, this release has been named after its default airport, [[Barcelona–El Prat Airport|Barcelona Airport]] (LEBL).

=== Major enhancements in this release ===
==== Core ====
* Video configuration can be saved.<ref>http://forum.flightgear.org/viewtopic.php?f=37&t=29122</ref><ref>https://sourceforge.net/p/flightgear/fgdata/ci/0d623d/</ref>
* The [[TerraSync]] server has been switched to using HTTP instead of SVN.
* All scenery models have been cleaned up and moved to TerraSync.

==== Aircraft Modeling ====

==== ATIS and METAR ====
* Various improvements in the reporting of wind, atmospheric pressure, and sky cover.
* Custom ATIS formats for the US/Canada/Pacific region and the UK based on real recordings.
* Bug fixes and data updates to reduce occurrence of NIL weather.

==== JSBSim ====

==== Atmospheric Light Scattering ====
* Filters have been added, enabling infrared and night-vision views

==== Environment Rendering ====

* A bug that prevented precipitation from appearing has been fixed.

==== Performance ====

==== Multiplayer ====
* A bug in the multiplayer protocol has been {{flightgear commit|4f8cbb|t=fixed}}.

==== Misc/Uncategorized ====

==== Usability ====

* Route manager allows entry of a space separated list of waypoints

==== Internationalization ====
* The Italian translation for menus, loading messages and help for command line switches has been updated.

==== Scenery ====

==== Canvas System ====

==== Nasal Scripting ====
* A bug in {{func link|math.clamp()|page=Nasal library/math}} has been {{fgdata commit|bba11c|t=fixed}}.

==== Documentation ====

==== Highlighted new and improved aircraft ====
* [[Parachutist]]
* [[Piper J3 Cub]]
* [[Boeing 757]]
* [[Extra EA-500]]

==== Other ====

==== Bug fixes ====
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=ticket_num%3A%5B1000+TO+*%5D+AND+%21ticket_num%3A437+AND+status%3AFixed+AND+mod_date%3A%5B2016-02-17T00%3A00%3A00Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Changelog 2016.2

2016-05-05T08:14:59Z

Sanhozay: /* Environment Rendering */

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.2 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}




=== Changed default location ===
In line with the release adopted in FlightGear v2016.1, this release has been named after its default airport, [[Barcelona–El Prat Airport|Barcelona Airport]] (LEBL).

=== Major enhancements in this release ===
==== Core ====
* Video configuration can be saved.<ref>http://forum.flightgear.org/viewtopic.php?f=37&t=29122</ref><ref>https://sourceforge.net/p/flightgear/fgdata/ci/0d623d/</ref>
* The [[TerraSync]] server has been switched to using HTTP instead of SVN.
* All scenery models have been cleaned up and moved to TerraSync.

==== Aircraft Modeling ====

==== ATIS and METAR ====
* Various improvements in the reporting of wind, atmospheric pressure, and sky cover.
* Custom ATIS formats for the US/Canada/Pacific region and the UK based on real recordings.
* Bug fixes and data updates to reduce occurrence of NIL weather.

==== JSBSim ====

==== Atmospheric Light Scattering ====
* Filters have been added, enabling infrared and night-vision views

==== Environment Rendering ====

* A bug that prevented precipitation from appearing has been fixed.

==== Performance ====

==== Multiplayer ====
* A bug in the multiplayer protocol has been {{flightgear commit|4f8cbb|t=fixed}}.

==== Misc/Uncategorized ====

==== Usability ====

==== Internationalization ====
* The Italian translation for menus, loading messages and help for command line switches has been updated.

==== Scenery ====

==== Canvas System ====

==== Nasal Scripting ====
* A bug in {{func link|math.clamp()|page=Nasal library/math}} has been {{fgdata commit|bba11c|t=fixed}}.

==== Documentation ====

==== Highlighted new and improved aircraft ====
* [[Parachutist]]
* [[Piper J3 Cub]]
* [[Boeing 757]]
* [[Extra EA-500]]

==== Other ====

==== Bug fixes ====
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=ticket_num%3A%5B1000+TO+*%5D+AND+%21ticket_num%3A437+AND+status%3AFixed+AND+mod_date%3A%5B2016-02-17T00%3A00%3A00Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Changelog 2016.2

2016-05-03T14:42:38Z

Sanhozay: ATIS / METAR

{{draft|changelog|This changelog is currently being written for the FlightGear v2016.2 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}



=== Changed default location ===
In line with the release adopted in FlightGear v2016.1, this release has been named after the default airport, [[Barcelona–El Prat Airport|Barcelona Airport]] (LEBL).

=== Major enhancements in this release ===
'''Core'''
* Support for [[Graphics Card Profiles|GPU Profiles]]<ref>http://forum.flightgear.org/viewtopic.php?f=37&t=29122</ref>

'''Aircraft Modeling'''
[[File:Parachutist.png|thumb|right]]
[[File:Pose01-skydiving-by-curt.jpg|thumb|right]]
* A new parachutist "aircraft" has been added. See [[Skydiving]] for more information.

'''ATIS and METAR'''

* Various improvements in reporting; specifically wind, QNH and sky cover.
* Custom ATIS formats for the US/Canada/Pacific region and the UK based on real recordings.
* Bug fixes and data updates to reduce occurrence of NIL weather.

'''JSBSim'''

'''Atmospheric Light Scattering'''

'''Environment Rendering'''

'''Performance'''

'''Multiplayer'''
* A bug in the multiplayer protocol has been fixed.<ref>https://sourceforge.net/p/flightgear/codetickets/1851/</ref>

'''Misc/Uncategorized'''

'''Usability'''

'''Internationalization'''
* The Italian translation for menus, loading messages and help for command line switches has been updated.

'''Scenery'''

'''Canvas System'''

'''Nasal Scripting'''

'''Documentation'''

'''Highlighted new and improved aircraft'''

'''Other'''

'''Bug fixes'''
* See [https://sourceforge.net/p/flightgear/codetickets/search/?q=status%3AFixed+AND+created_date%3A%5B2016-02-17T23%3A31%3A35Z+TO+*%5D our bugtracker] for a list, albeit incomplete, of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]
[[Category:New Versioning Scheme]]

Beagle Pup

2016-04-06T11:22:19Z

Sanhozay: Autopilot notes

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes less than 2 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot, and particularly before attempting roll trim. Currently the only way to do centre the rudder is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-06T11:13:25Z

Sanhozay: Note on power reduction from application of carb heat

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply just enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Applying carb heat reduces engine power so only apply as much as is required to prevent icing.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T16:55:42Z

Sanhozay: /* Development Status/Issues/Todo */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== Liveries ===

Each variant has a handful of liveries for testing purposes. If you want to make your own liveries for this aircraft, be aware that the exterior model is unfinished and likely to be remapped. Any existing liveries will become invalid at that point.

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T16:48:05Z

Sanhozay: /* Sperry SP Series Autopilot */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T16:38:02Z

Sanhozay: /* Carburettor Temperature and Icing Simulation */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Note that if you use autostart for a runway start, the carb heat control will be in the off position ready for immediate takeoff. If you sit on the runway with idle throttle for a more than a few seconds, the carburettor is likely to ice up and reduce your takeoff power.

Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity. Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:17:40Z

Sanhozay: /* Sperry SP3 in the Beagle Pup */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-g do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:17:14Z

Sanhozay: /* External Model */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Model || Model exterior lights (taxi and landing) || {{pending}}
|-
| Model || Temperature probe || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:15:59Z

Sanhozay: /* Systems */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Support serviceable and failures || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:15:02Z

Sanhozay: /* External Model */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model aerials and fins || {{progressbar|80}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|50}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:13:52Z

Sanhozay: /* Cockpit */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|50}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Stall warning || {{pending}}
|-
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:12:46Z

Sanhozay: /* Systems */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|90}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|30}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:12:06Z

Sanhozay: /* FDM */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|30}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-04-05T13:08:32Z

Sanhozay: Carb icing notes

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

=== Performance ===

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70kts and aim to land at 60kts with full flaps.

=== Carburettor Temperature and Icing Simulation ===

''Available from aircraft version 0.17.0 onwards''

This feature is off by default and enabled through the ''Beagle Pup | Preferences'' menu. Without the checkbox checked, carburettor temperature is simulated and displayed on the cockpit gauge but no icing will occur. Checking the checkbox turns the icing simulation on. Note that ice is not cleared by unchecking the box; if you turn the icing simulation off while you have carb ice, it will not thaw! The setting is saved on exit, but note that the Pup 100, 150 and 160 are different aircraft and each have their own setting.

The checklists guide you through the process of introducing carb heat to prevent icing. In short, this means applying carb heat when idling on the ground and during taxi, turning off when full power is applied prior to takeoff, and re-applying when power is reduced for descent. Carb icing may occur during cruise if weather is cool and damp, so watch the carb temperature gauge and apply enough carb heat to keep the temperature above the yellow zone. The outside air temperature gauge gives an indication of the likelihood of icing conditions and you should pay attention to the dewpoint from enroute weather observations as an indication of humidity.

Reduced performance from excess carb heat is not yet simulated.

Continental engines, as fitted to the Pup 100, are more prone to carb icing than the Lycoming engines fitted to the Pup 150 and 160. This is because of the mounting position of the carburettor relative to the engine. With the Pup 100, you are more likely to need carb heat during cruise. For both engines, once the engine is warm, the likelihood of carb ice is reduced, but less so with the Continental engine.

The symptom of carb icing is reduced power as the ice buildup constricts the air intake of the carburettor. It has the same effect as closing the throttle. To clear the ice, you need to increase the temperature of the carburettor above freezing, usually by applying carb heat. This diverts hot exhaust gases to heat the carburettor. You can also prevent or clear carb ice to some extent by warming the carburettor in other ways; increased throttle to reduce the venturi effect that causes carb cooling, or proper leaning of the mixture.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|30}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Aircraft checklists

2016-04-03T20:11:39Z

Sanhozay: Remove automated quoting because it makes no sense in the context of the paragraph. Please don't add it back.

{{infobox subsystem
|image =Aircraft Checklists dialog.jpg
|name = Generic Aircraft Checklists
|started= 03/2010
|description = Centralized checklist management
|status = Under active development as of 05/2015
|maintainers = {{usr|Stuart}}
|developers = * {{usr|Stuart}}
* {{usr|Sanhozay}}
|changelog = * {{Git File History|project=flightgear|sub-project=fgdata|path=/Nasal/checklist.nas}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/gui/dialogs/checklist.xml}}
* {{Git File History|project=flightgear|sub-project=fgdata|path=/Aircraft/Generic/autochecklist.nas}}
}}

{{Startup}}
{{Checklists}}

As of version 2.9, [[FlightGear]] can display '''aircraft checklists''' in a standardized way, under Help > Aircraft Checklists.

== Adding checklists ==
To learn more about creating custom checklists, see {{readme file|checklists}} and the [[Cessna 172P]] as the reference implementation. Increasingly, the [[tutorials]] system is also extended such that it may make use of aircraft checklists.

Checklists are situated under <tt>/sim/checklists</tt>. As the checklists may be quite long, it is recommended that they are put in a separate file using the following entry in the <tt>-set.xml</tt> file of the aircraft:

<syntaxhighlight lang="xml">
<checklists include="c172-checklists.xml"/>
</syntaxhighlight>

Each individual checklist is created under a <checklist> XML tag, with the following sub-properties:

* <code><title></code> The name of the checklist
* <code><page></code> One or more pages from the checklist, containing one or more of the following:
** <code><item></code> A checklist item, containing
*** <code><name></code> The item name, to appear on the left hand side of the checklist
*** <code><value></code> One or more values, to appear on the right hand side of the checklist. Second and and subsequent <value> tags are displayed underneath each other. It is recommended that the <value> tags are kept short, to minimize the size of the displayed checklist.
*** <code><condition></code> An optional [[Howto:Animate models#Conditions|condition node]] that evaluates when the checklist item is complete. Incomplete checklist items are shown in yellow, while completed items are shown in green.
*** <code><marker></code> An optional marker node that is used to display a circle around a control when the user clicks a "?" button next to the item. This contains <x-m>, <y-m>, <z-m> and <scale> sub-elements and uses the [[Tutorials#Marker|tutorial marker]]. Note that this requires the marker model to be included in the aircraft model, as explained in the aforementioned article.
*** <code><binding></code> Zero or more XML bindings that are used by the simulator to execute the checklist item if the user clicks on a ">" button next to the item.

For simple checklists the <page> element can be omitted and <item> entries placed directly under the <checklist>.

The following example shows a simple checklists XML file:

<syntaxhighlight lang="xml">
<PropertyList>
<checklist>
<title>After Landing</title>
<item>
<name>Carburetor Heat</name>
<value>COLD</value>
<condition>
<equals>
<property>/controls/anti-ice/engine[0]/carb-heat</property>
<value>0</value>
</equals>
</condition>
<marker>
<x-m>-0.3225</x-m>
<y-m>-0.0850</y-m>
<z-m>-0.2117</z-m>
<scale>2.0500</scale>
</marker>
<binding>
<command>property-assign</command>
<value>0</value>
</binding>
</item>
<item>
<name>Wing Flaps</name>
<value>UP</value>
</item>
</checklist>
<checklist>
<title>Getting hamburger</title>
<page>
<item>
...
</item>
</page>
</checklist>
</PropertyList>
</syntaxhighlight>

See the Cessna 172P for an example of how this all fits together.

=== Bindings ===
One or more [[Bindings|binding elements]] can be added to a checklist item. Conceptually, these are the actions that the user should execute to complete the item. The checklist GUI displays items with such <binding> elements with an additional [>] button. Clicking on the button executes the bindings, allowing the user to watch as the computer/co-pilot/instructor executes the checklist item.

The <binding> element is exactly as you would expect - so property-assign, nasal etc. works.

The plan is to extend this function so that checklists with one or more items containing a <binding> element can have an (optional) button
to execute the entire checklist.

== Reloading checklists ==
Cut and paste this little code snippet in the [[Nasal Console]] and excecute it:

<syntaxhighlight lang="nasal">
var reload_checklist = func(filename) {
var checklist_path=sprintf("%s/%s",getprop("/sim/aircraft-dir"),filename);
var data = io.read_properties(checklist_path,"/sim/checklists");
}

reload_checklist(filename: "777-200-checklists.xml");
</syntaxhighlight>

Change the filename to the name of the file you are editing. Make sure to monitor the startup window and/or the [[Nasal Console]] loglist widget for any XML related warnings (e.g. parsing errors).

== Automated checklist execution ==

As of version 3.5, [[FlightGear]] can automate the execution of various sequences of aircraft checklists using the <tt>autochecklist.nas</tt> script in <tt>$FGDATA/Aircraft/Generic</tt>. The advantage of this approach is that the checklist files become the source of checklists, tutorials and autostart; if the checklists change, so does the autostart (see {{Wikipedia|Don't repeat yourself}}).

The <tt>autochecklist.nas</tt> script can be used to create an autostart menu but is not restricted to autostart; any checklist sequence can be run from any piece of Nasal code.

Automated checklists may not work for more complex aircraft startup sequences, but they are so easy to set up that it's worth trying alongside the development of the aircraft startup process. If it works, great! If it doesn't, you haven't wasted your time because you have at least made a start on your checklists.

=== Background ===

The <tt>autochecklist.nas</tt> script relies on the aircraft having a set of checklists that have complete sets of [[Bindings|bindings]] to take the aircraft from one state to another. For autostart, for example, you need to be able to start the aircraft solely by pressing the binding buttons on the right side of the checklist.

Using the script is a simple three step process involving a few lines of XML and as little as one line of [[Nasal]] code:

# Add the script to your aircraft
# Define one or more named checklist sequences
# Call the script to execute a checklist sequence

For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.

When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the {{readme file|conditions}} associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.

In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.

=== Add the script ===

Add <tt>autochecklist.nas</tt> to the aircraft's <tt>-set.xml</tt> file (or equivalent):

<syntaxhighlight lang="xml">
<nasal>
...
<autochecklist>
<file>Aircraft/Generic/autochecklist.nas</file>
</autochecklist>
</nasal>
</syntaxhighlight>

=== Define checklist sequences ===

In the aircraft's <tt>-set.xml</tt> file, create one or more named checklist sequences that specify ordered lists of checklists to execute. The names can be anything you like as long as they are valid XML tags. The names are never displayed within the simulator.

For example, to run checklists with indexes 0 and 1 for startup and checklist 9 for shutdown:

<syntaxhighlight lang="xml">
<sim>
<checklists>
<checklist include="Checklists/before-starting-engines.xml"/>
<checklist include="Checklists/start-engines.xml"/>

<checklist include="Checklists/parking.xml"/>
<startup>
<index n="0">0</index> 
<index n="1">1</index> 
</startup>
<shutdown>
<index n="0">9</index> 
</startup>
</checklists>
</sim>
</syntaxhighlight>

=== Execute the checklist sequence ===

For the typical usage of autostart, add a Nasal binding as a menu item and execute the named checklist sequence:

<syntaxhighlight lang="xml">
<item>
<label>Autostart</label>
<binding>
<command>nasal</command>
<script>autochecklist.complete_checklists("startup");</script>
</binding>
</item>
</syntaxhighlight>

Obviously, additional logic can be included in the binding if you want the autostart menu to toggle between autostart and shutdown.

==== Fine tuning checklist bindings ====

Sometimes, a checklist binding will do something like display a dialog, e.g. fuel and payload dialog. It would be irritating to the pilot if these things happened during automated execution. These bindings can make use of the <code>sim/checklists/auto/active</code> property, which will be <tt>true</tt> when the checklist binding is being run by the autochecklist script and <tt>false</tt> otherwise.

<syntaxhighlight lang="xml">
<binding>
<command>nasal</command>
<script>
var auto = getprop("sim/checklists/auto/active");
if (!auto) gui.showWeightDialog();
</script>
</binding>
</syntaxhighlight>

==== Expedited checklists ====

For in-air start sequences in some aircraft, you can pass zero as the second argument of the <tt>complete_checklists</tt> function to expedite the sequence. All items in the checklist sequence will be executed without waiting for previous items to complete. Note that this means the checklist sequence is never considered to have failed.

<syntaxhighlight lang="nasal">
if (!getprop("gear/gear/wow")) {
autochecklist.complete_checklists(sequence: "in-air-start", wait: 0);
} else {
autochecklist.complete_checklists("ground-start");
}
</syntaxhighlight>

Clearly the checklist sequence used for in-air start should be different from a ground start and should put the aircraft into a flying state, e.g. gear up, flaps up. Bindings can use the property <code>sim/checklists/auto/expedited</code> to check if the execution is expedited, i.e. there is no wait between items. Note that the expedited flag does not in itself indicate whether a binding is being run as part of an automated checklist. You may need to test both the <code>sim/checklists/auto/active</code> and <code>sim/checklists/auto/expedited</code> properties, e.g.

<syntaxhighlight lang="nasal">
var auto = getprop("sim/checklists/auto/active");
var expedited = getprop("sim/checklists/auto/expedited");

if (auto and expedited) {
...
}
</syntaxhighlight>

=== Customizing execution (optional) ===

The behavior of the <tt>autochecklist.nas</tt> script can be customized by setting properties, either in the aircraft's <tt>-set.xml</tt> file or at runtime. Configuration is under the <tt>sim/checklists/auto</tt> node.

<syntaxhighlight lang="xml">
<sim>
<checklists>
...
<auto>
<startup-message>Running checklists, please wait ...</startup-message>
<completed-message>Checklists complete.</completed-message>
<timeout-message>Some checks failed.</timeout-message>
<timeout-sec>10</timeout-sec>
<wait-sec>3</wait-sec>
<auto>
</checklists>
</sim>
</syntaxhighlight>

* <code>startup-message</code> message displayed prior to automated checklist execution
* <code>completed-message</code> message displayed on successful completion of the checklist
* <code>timeout-message</code> message displayed if checklist execution times out waiting for a checklist condition to be satisfied
* <code>timeout-sec</code> if the previous condition is not satisfied within this timeout, the automated execution fails
* <code>wait-sec</code> time to wait before re-checking the status of the previous item if its condition is false after running the binding (effectively a polling interval).

Messages are displayed as copilot announcements (by setting <tt>sim/messages/copilot</tt>). They can be set empty if messages are not required. Note that messages are never displayed for expedited starts.

Care should be taken with the timeout value. This is the timeout for a single item waiting for the previous condition to be satisfied, not the overall timeout for the checklist sequence. If the timeout is set to a large value and conditions cannot be satisfied, the pilot will have to wait a long time for the failure message to appear.

=== Other features and ideas ===

Automated checklist execution is not restricted to autostart and shutdown. If you have an "After Landing" checklist that switches landing lights off, raises flaps and turns taxi lights on, for example, you could assign that to a keyboard shortcut. Rollout and taxi is a busy time on some aircraft and it's often not easy to find the switches and controls necessary to complete this kind of checklist.

To use the <tt>autochecklist.nas</tt> script, pilots need <tt>FGDATA</tt> v3.5 or greater, otherwise the script will not be available. The availability of automated checklists can be tested by checking whether the <tt>sim/checklists/auto</tt> node is nil and a suitable indication given to the pilot if it is nil.

For an example of using automated checklists, refer to the [[Lockheed Constellation]], for which the script was originally written.

== Development ==
the docs for this particular feature are to be found in {{readme file|checklists}}.
This is also where you can read that the c172p is considered the reference implementation.
The system itself is located in {{fgdata source|path=gui/dialogs/checklist.xml|line=18|pre=$FG_ROOT|post=(embedded Nasal)}}, but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=218209#p218209
| title = <nowiki>Re: </nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Sep 11th, 2014
| added = Sep 11th, 2014
| script_version = 0.25
}}
</ref>

it would be a good idea to localie any custom Nasal blocks, and instead introduce custom fgcommands using the addcommand() API - basically the reason being that there could be an aircraft-specific API using fgcommands for starting engines, instead of having aircraft-specific "Nasal blobs" in each checklist file. A while ago, this was actually discussed on the devel list, too. In other words, an "fgcommand" (implemented in Nasal) would help better isolate checklists from aircraft specifics.
<ref> {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=241259#p241259
| title = <nowiki>Re: Automated Checklist Execution</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = May 1st, 2015
| added = May 1st, 2015
| script_version = 0.25
}}
</ref>

== External link ==
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38325.html Aircraft Checklists] (mailing list)
* [https://sourceforge.net/p/flightgear/mailman/message/33904555/ Automated Checklist Execution] (mailing list)

[[Category:Aircraft enhancement]]

Beagle Pup

2016-03-31T12:21:19Z

Sanhozay: /* Cockpit */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70-80kts.

The aircraft has not been tested with any launcher, official or otherwise.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|30}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-03-31T12:19:35Z

Sanhozay: /* Development Status/Issues/Todo */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70-80kts.

The aircraft has not been tested with any launcher, official or otherwise.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{progressbar|33}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{done}}
|-
| Gear || Animate wheel rotation || {{done}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{done}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Add reflection and chrome shaders || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-03-26T13:05:22Z

Sanhozay: /* External Model */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70-80kts.

The aircraft has not been tested with any launcher, official or otherwise.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{pending}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{pending}}
|-
| Gear || Animate wheel rotation || {{pending}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{pending}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{done}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{done}}
|-
| MP || Verify replay || {{done}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-03-26T13:01:36Z

Sanhozay: /* FDM */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70-80kts.

The aircraft has not been tested with any launcher, official or otherwise.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{progressbar|80}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{pending}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{pending}}
|-
| Gear || Animate wheel rotation || {{pending}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{pending}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{progressbar|20}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Lights || Add taxi light and landing lights || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{pending}}
|-
| MP || Verify replay || {{pending}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Beagle Pup

2016-03-24T16:35:59Z

Sanhozay: /* Development Status/Issues/Todo */

{{infobox Aircraft
|image=Beagle Pup 100.png
|name = Beagle Pup
|type = Light Sport / General Aviation
|fdm = JSBSim
|status-fdm = 2
|status-systems = 2
|status-cockpit = 2
|status-model = 2
|authors = Richard Senior
|fgname = pup100, pup150, pup160
}}
The Beagle 121, better known as the '''Beagle Pup''' is a light sport and general aviation aircraft designed and built during the 1960s by Beagle Aircraft Ltd at Shoreham and Rearsby in the United Kingdom.

== Variants ==

=== Series 1 (Beagle Pup 100) ===

Powered by a 100hp Rolls-Royce Continental 0-200 engine, the original Beagle Pup has modest climb rates of around 500 ft/min and a cruise speed of just over 100 knots. Fuel capacity 24 imperial gallons (29 US gallons).

=== Series 2 (Beagle Pup 150) ===

The Pup 150 retains the same airframe as the Pup 100 with an enlarged and reshaped engine cowl to accommodate a 150hp Lycoming 0-320-A2B engine. The extra power allowed for additional passenger seating in the rear and produced climb rates of around 800 ft/min and a cruise speed of around 115 knots. Fuel tanks were unchanged from the Pup 100, although there was an option for additional tanks to increase the capacity to 34 imperial gallons (41 US gallons).

=== Series 3 (Beagle Pup 160) ===

The Pup 160 has exactly the same airframe and cowl as the Pup 150, but was fitted with fuel tanks totalling 34 imperial gallons (41 US gallons) as standard and powered by a 160hp Lycoming 0-320-D2C engine. Cruise speed and climb rates are comparable to the Pup 150, the Pup 160 is really about increased range and carrying capacity.

The most common aircraft currently in use is the Pup 150. Only a handful or Pup 160s were made before Beagle went into liquidation and most were exported from the UK. The Pup 100 is considered to be slightly underpowered.

== Flight Notes ==

The aircraft is still in an alpha state but completely flyable from the 3D cockpit. The external model is currently of a Pup 100 for all three variants.

For a model this new, systems are relatively mature. Startup sequence is modelled ... but no controls in the 3D cockpit. Autostart executes the startup checklists and puts the aircraft in a ready for takeoff state with takeoff flaps set. Some basic cockpit lighting is provided for night flying. Overall, it is quite flyable.

There is a continuous fuel simulation, i.e. it saves the fuel levels on exit. Check fuel before you fly.

Performance has been roughly tuned on the Pup 100 for cruise below 5000ft. The Pup 150/160 fall into the right ballpark of cruise speed but appear overpowered at low altitude. Generally speaking, relieve the weight on the nose by 50kts and use the rudder, rotate at 70kts and flaps up on positive climb. There is a keyboard shortcut to set cruise power, lean the mixture (the EGT major tick scale is 100*F, and typical leaning is 50*F rich of peak). Approach at 70-80kts.

The aircraft has not been tested with any launcher, official or otherwise.

== Sperry SP Series Autopilot ==

{{WIP}}

The Sperry SP autopilots consisted of a series of modules that could be added individually to an aircraft to provide different degrees of autopilot control. Note the white blanking plates at the bottom of the autopilot controller, which are placeholders for a series of control buttons.

The most basic configuration -- the SP1 -- is simply a yaw stabilizer, controlling only the rudder. The SP2 systems are two-axis autopilots, controlling aileron and elevator. The full set -- designated the SP3 -- is a three-axis autopilot with altitude hold and automatic heading hold. I have seen photographs of later units with a complete set of four buttons on the controller: HDG HLD, ALT HLD, NAV LOC and GLD HLD but I am not aware of Beagle having fitted these to any aircraft.

=== Sperry SP3 in the Beagle Pup ===

Judging by photographs, publicity material and existing aircraft, Beagle did not fit an autopilot to the Beagle Pup as standard. During the time the Beagle Pup was being manufactured, they were fitting Sperry SP3 autopilots to the Beagle 206 (Basset). Rather than use the generic Flightgear autopilot, I've taken the opportunity to satisfy my appetite for obscure autopilot controllers by modelling the Sperry SP3 for the Beagle Pup.

The SP3 is a three axis autopilot, controlling pitch, roll and yaw. If you are flying the Beagle Pup with auto-coordination turned on, the autopilot does not attempt to control the rudder, so technically you are flying with a Sperry SP2A and Flightgear is dealing with coordinated turns.

Controls are basic. There is a pitch wheel to control pitch, a turn knob to control roll, an altitude hold button and an on off switch. Trim controls are also provided for the pitch and roll channels. Note that these are not direct controls of aileron or elevator trim, these are autopilot trims. There is no button or switch for heading hold, and no heading bug; heading hold is automatic when a neutral turn is selected. There is no automatic tracking of a VOR radial, no glideslope coupling and the autopilot does not follow a route-manager route.

Control of pitch is fairly self-explanatory. When the autopilot is turned on, it will attempt to stabilize the aircraft at the pitch that is set on the wheel. So if you turn the autopilot on during climb, you will want to preset a positive pitch on the pitch wheel of about 4-5 degrees. With the pitch wheel at zero detent (use the help text in the bottom left corner of the screen) the idea is that the aircraft should fly level. It probably won't, which is why there is an "Elev. Trim" knob. With the aircraft at a typical cruise altitude and power (leaned if necessary), adjust the elev trim knob so that a selection of zero pitch on the main pitch wheel produces level flight. This trim setting is saved when you exit Flightgear but may need adjusting based on fuel and payload. Once the pitch axis is trimmed, with the pitch wheel centered, you can press the "ALT HLD" button to hold the current altitude. Altitude hold is cleared when you rotate the pitch wheel away from center and needs to be pressed again to hold a different level.

Control of roll is also quite simple. As with the pitch channel, trimming may be necessary. The turn knob allows left/right turns up to 20 degrees of bank, which produces a standard rate turn. With the turn knob centered, the aircraft is supposed to fly wings level and, if the heading is stable, will lock onto the stable heading. If you center the turn knob and the aircraft doesn't lock onto the heading, use the roll trim wheel to cancel out any turn due to imbalance of the aircraft. Again, the trim is saved on exit and screen help indicates the amount of turn you have selected and also the heading hold. It takes 3-5 seconds to lock the heading after selecting zero bank.

There are no controls on the controller for the yaw channel. Coordinated turns are handled by the autopilot if auto-coordination is turned off. If you are flying with mouse or keyboard control and the autopilot is controlling yaw, you will want to center the rudder before engaging the autopilot. Currently the only way to do this is by using the HUD.

Without a heading bug, establishing a heading takes a little practice. The key is that the autopilot is tuned to roll level from half the bank angle from your target. So, for example, if you are flying at 270 and you want to fly a heading of 360, establish a full right turn with the turn knob (20 degrees of bank) and, just before 10 degrees from your target, i.e. 350 degrees, center the turn knob. The turn knob uses a standard knob/slider animation, so holding down the shift key and left-clicking banks right in 10 degree increments. Shift middle-click banks left. The controls are heavily filtered to keep these turns smooth. Fine-tuning a heading, e.g. when tracking a NAV radial, is easily achieved by clicking the turn knob a couple of times to bank slightly left, then middle-clicking a couple of times to center again.

Note that Ctrl-z toggles the main autopilot on/off switch. Other conventional autopilot shortcuts, e.g. Ctrl-h, Ctrl-h do not work with this autopilot.

== Development Status/Issues/Todo ==

=== FDM ===

Information limited. Aerodynamic knowledge limited. Advice welcomed ;)

{| class="wikitable"
!Category !! Description !! Progress
|-
| Weights || Refine limits from type certificate || {{done}}
|-
| Balance || Position fuel tanks more accurately || {{done}}
|-
| Balance || Develop a more accurate estimate of COG || {{done}}
|-
| Control || Refine surface position travel || {{progressbar|50}}
|-
| Control || Look at flap lift (flaps tend to balloon) || {{progressbar|50}}
|-
| Propulsion || Tune engine rpm, mp and hp || {{pending}}
|-
| Propulsion || Adjust performance variation with altitude || {{pending}}
|-
| Reactions || Add contact points and crash detect || {{done}}
|-
| Reactions || Fix bouncing at startup || {{pending}}
|-
|}

=== Systems ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Electrical || Research and simulate circuit breaker panel switches || {{pending}}
|-
| Electrical || Add basic current simulation || {{pending}}
|-
| Icing || Add carb temperature simulation || {{progressbar|20}}
|-
| Icing || Add pitot heat simulation || {{pending}}
|-
| Fuel || Add fuel pressure simulation || {{pending}}
|-
| Fuel || Refine manifold simulation || {{pending}}
|-
| Fuel || Create refuelling dialog || {{pending}}
|-
| Fuel || Filter EGT for instrument display || {{done}}
|-
| Fuel || Model unusable fuel and full quantities || {{pending}}
|-
| Other || Verify pitot/static and suction || {{pending}}
|-
| Checklists || Complete to match POH || {{progressbar|30}}
|-
| Autopilot || Heading hold doesn't properly respect gyro precession || {{done}}
|}

=== Cockpit ===

Cockpit is currently a placeholder only, populated with instruments from the Cessna 337.

{| class="wikitable"
!Category !! Description !! Progress
|-
| Model || Create seats || {{pending}}
|-
| Model || Create and select animate rear seats || {{pending}}
|-
| Model || Model centre pedestal || {{pending}}
|-
| Model || Model panel || {{pending}}
|-
| Model || Model and animate fuel tank selector || {{pending}}
|-
| Model || Reinstate missing window sills || {{done}}
|-
| Instruments || Model KR-86 ADF receiver and display || {{pending}}
|-
| Instruments || Model KX-175B comm/nav || {{pending}}
|-
| Instruments || Model and drive Sperry SP3 Autopilot || {{progressbar|90}}
|-
| Instruments || Create Transponder || {{pending}}
|-
| Instruments || Legacy DME? || {{pending}}
|-
| Panel || Recreate panel instrument dials - various || {{pending}}
|-
| Effects || Add ALS shadows (cube map) || {{pending}}
|-
| Effects || Create lightmaps for pilot/copilot flood || {{pending}}
|-
| Effects || Add internal glass effects || {{pending}}
|-
| Sound || Switch clicks || {{progressbar|80}}
|-
| Sound || Stall warning || {{pending}}
|-
| Sound || Environment sounds (rain, thunder) || {{done}}
|}

=== External Model ===

{| class="wikitable"
!Category !! Description !! Progress
|-
| Gear || Add fuselage cowls (main gear strut housings) || {{done}}
|-
| Gear || Animate main gear compression || {{pending}}
|-
| Gear || Animate wheel rotation || {{pending}}
|-
| Gear || Model oleo strut and animate (review compression and length) || {{pending}}
|-
| Gear || Model main gear brakes and cables || {{pending}}
|-
| Gear || Add or texture tyre treads || {{pending}}
|-
| Lights || Add navigation, strobe and beacon lights || {{progressbar|20}}
|-
| Lights || Add ALS landing and taxi lights || {{done}}
|-
| Lights || Add taxi light and landing lights || {{pending}}
|-
| Model || Create 150/160 engine cowl variant || {{pending}}
|-
| Model || Model and texture transparent window glass || {{done}}
|-
| Model || Model aerials and fins || {{progressbar|70}}
|-
| Model || Model pitot tube || {{done}}
|-
| Model || Model and animate control surface hinges || {{pending}}
|-
| Model || Model tie down points || {{pending}}
|-
| Model || Model exhaust and air intake || {{progressbar|40}}
|-
| Model || Create paint kit with construction lines || {{pending}}
|-
| Model || Add livery support || {{done}}
|-
| Model || Improve ambient occlusion map || {{pending}}
|-
| MP || Verify multiplayer properties || {{pending}}
|-
| MP || Verify replay || {{pending}}
|-
| MP || Fix livery over MP || {{done}}
|-
| Sound || Improve consistency between 100 and 150/160 || {{progressbar|40}}
|}

== External links ==
* [https://en.wikipedia.org/wiki/Beagle_Pup Wikipedia]
* [http://austerhg.org/beagle_mags/ Historic Beagle Magazines]
* [http://www.pilotfriend.com/aircraft%20performance/Beagle/beagle.htm Beagle Aircraft History]
* [http://easa.europa.eu/system/files/dfu/SAS%20A%20082%20Iss%205%20final.pdf Beagle Pup Airworthiness Certificate]
* [https://www.flightglobal.com/FlightPDFArchive/1961/1961%20-%201325.PDF Sperry SP3 Review]

[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]