Board index FlightGear Development Weather

Improving glider realism

Everything related to weather simulation, visuals should be discussed in the shader subforum.

Improving glider realism

Postby WooT » Mon Apr 20, 2009 3:58 pm

Starting this thread to (try to) answer some questions that were raised by the new wiki page on:
http://wiki.flightgear.org/index.php/Im ... er_Realism,
and a devel list reply by Ian :

I'll see if I can help a bit with the FG ridgelift implementation.

Which glider has the best flight model and instruments? Ridgelift only really pays off when you have a decent glider.

I've expanded the wiki stub http://wiki.flightgear.org/index.php/Im ... er_Realism to at least create a section for each area
that needs a decent solution to have a competitive soaring capability in FlightGear.

The bits I worked on for FSX were ridgelift, the TE and netto variometers, the IGC logger, and the flight model to upgrade the stock
glider (DG808S). The default capabilities of FSX for soaring were very poor (unrealistic glider flight model, no ridge lift, only an
uncompensated rate-of-climb vario). Peter Luerkens programmed CumulusX! which provides the thermals.

Cheers,
B21 / Ian Forster-Lewis

p.s. can you link directly to external images in the wiki, or do you have to upload all images to the actual wiki server?


In my honnest opinion, the gliders in FG still need a lot of improvements, but the ASK21 is yet in a good, usable state. It has a compensated, audio variometer, that works quite well. I don't know if it i really realistic, but this audio vario helps me a lot in thermals and ridge.
http://wiki.flightgear.org/index.php/Schleicher_ASK_21

Gauges

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


You could check in the flight gear sources, in "(fg-source-path)/data/Aircraft/Instruments-3d/" , and in each glider implementation, to see what currently exist as instruments.

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


I don't know of a FG graphic one, but the ASK21 has an audio one ( see above )

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


This one would be quite easy to simulate, just by using "wind-from-down-fps" as driving property. this would make a perfect one. Probably too perfect, even.

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


I don't know what format is used internally, but flightgear currently features this :
http://fgfs.i-net.hu/modules/fgtracker/

For instance, this is one of my flights with the new ridge lift
http://fgfs.i-net.hu/modules/fgtracker/ ... TID=759405 ( flight details )
http://fgfs.i-net.hu/modules/fgtracker/ ... TID=759405 ( to be seen in google-earth )

As far as I know, every flight made on a public multiplayer server is logged here.

Peter Luerkens programmed CumulusX! which provides the thermals


Do you think Peter would be interested in contributing to FG too ? Or maybe let us see his code ?
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: Improving glider realism

Postby Hooray » Mon Apr 20, 2009 5:47 pm

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

FlightGear has a generic I/O protocol and capability which is XML configurable, it might be possible to use this to some extent and if necessary enhance the protocol slightly so that it can also create log files in IGC format.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby MyName » Mon Apr 20, 2009 7:27 pm

FlightGear has a generic I/O protocol and capability which is XML configurable, it might be possible to use this to some extent and if necessary enhance the protocol slightly so that it can also create log files in IGC format.

FG is almost as flexible as a microcontroller is, you can create interfaces for almost everything! :D
MyName
 
Posts: 660
Joined: Sun Mar 01, 2009 4:57 am

Re: Improving glider realism

Postby Hooray » Mon Apr 20, 2009 8:34 pm

Well, I was hoping to create a minimal IGC protocol using an XML protocol, so I was looking into the specs file at http://www.fai.org/gliding/system/files ... c_gnss.pdf to see how the required IGC output could possibly be created with an XML protocol.

But it seems this is really a pretty big protocol, which also didn't seem particularly intuitive or logical to me, "convoluted" would be an understatement ;-)

http://www.fai.org/gliding/system/files/wpformat.pdf
http://www.edavies.nildram.co.uk/ew/ewa-igc.htm
http://www.edavies.nildram.co.uk/ew/ewa-igc-charmap.htm

So I still don't know what subset (fields) of the protocol needs to be minimally supported to create valid IGC files, but I think it might be easier to just use a Nasal script to write certain properties to an ASCII file following the protocol specs, this would be more flexible than the XML system and wouldn't require any additions to the XML protocol system.

There are also various open source tools that support the IGC format, some of which are GPL:

http://freshmeat.net/projects/kflog
http://sourceforge.net/projects/freshmeat_gpligc/
http://sourceforge.net/projects/gpligc/
http://sourceforge.net/projects/speedbird/


I don't know if supporting the IGC format should be a priority or not at the moment, but doing so would be surely simplified by knowing the minimum fields required in a valid IGC file, so that we can try to actually create such an IGC file and inspect it using any of the above IGC viewer tools (kflog).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby B21 » Mon Apr 20, 2009 11:04 pm

re the IGC file, my wiki update http://wiki.flightgear.org/index.php/Im ... er_Realism includes a workable subset of a file. The reality is the format has got wayyyy more complicated than really necessary and most software looks for the 'B' records (timestamp-lat-long-alt) and ignores anything else it doesn't understand. The basic file format is actually pretty simple, with one-line-per-record, and all the header stuff being followed by a sequence of 'B' records, and the last 'G' record is a checksum. Here's come comments from memory:

Code: Select all
AXXXb21_sim_probe 2.55  // manufacturer code I think - just put AXXX<anything>
HFDTE070608                   // DATE of the log DDMMYY - this is important to create the full timestamp of each B record
HFFXA035                        // I forget what this is - not important - just keep the same
HFPLTPILOTINCHARGE: not recorded // comment
HFCM2CREW2: not recorded // comment
HFGTYGLIDERTYPE:DG         // comment
HFGIDGLIDERID:B21             // just a comment, but usually used to identify trace when multiple traces loaded
HFDTM100GPSDATUM: WGS-1984   // gives datum used by GPS - just leave this line as is
HFRFWFIRMWAREVERSION: 2.55     // comment
HFRHWHARDWAREVERSION: 2008   // comment
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis             // comment
HFGPSGPS:Microsoft Flight Simulator                          // comment
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator     // comment
HFCIDCOMPETITIONID:B21  // comment, but also may be used to identify trace on map (vs HFGIDGLIDERID)                     
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator  // comment
I013638FXA                          // this line is important for some software, modifies B record format with fix accuracy in last 3 digits
B1658174040958N07737022WA0094000940000     // this is the actual GPS fix
^
B = means this is a fix record
 165817 = fix taken at 16:58:17 (as HHMMSS)
            4040958N = fix was 40 degrees 40.958 minutes North
                          07737022W = and 77 degrees 37.022 West
                                           A = valid altitude
                                             00940 meters altitude (from pressure sensor)
                                                     00940 meters altitude (from GPS sensor)
                                                              000 (GPS accuracy)
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
                             // ... and more B records for the rest of the file
G123456789           // G record is any security string chosen by manufacturer (checksum) that can later be tested


If you are *reading* an IGC file, the basic trick is to discard any records you don't recognise, and only read the 'B' records as far as the time-lat-long-alt if you don't need the complex 'I-record' extenders.
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Re: Improving glider realism

Postby B21 » Mon Apr 20, 2009 11:22 pm

re Peter Luerkens - I'll ask him but I think he's fairly committed to Visual Basic - managed code - dotNet which makes sense for FSX but wouldn't work for FG. His latest CumulusX project re-invents thermals (+ Cumulus clouds) as AI objects in FSX which are independently 'launched' and drift downwind plus of course include their life-cycle.

B21
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Re: Improving glider realism

Postby B21 » Mon Apr 20, 2009 11:32 pm

re netto from "wind-from-down-fps" - this analysis is 100% correct, i.e. you can 'cheat' with internal knowledge of the sim and the netto vario is as easy to build as a plain reate-of-climb.

*But* a TE vario is only a few lines of code (you just have to understand the physics - potential energy = mass x G x height, kinetic energy = 0.5 x mass x velocity squared) and a netto vario means just adding a section that interpolates the polar of the glider - again just a few lines of code. Then you have an instrument that behaves in a pleasingly accurate way - e.g. it shows a bit of sink as you pull up (and increase the g-loading on the wings), and shows massive sink if you open the airbrakes, or the needle just sags a bit if you leave the wheel down.

Anyway I've written both a TE and netto vario for FSX so you've got no excuses.

B21
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Re: Improving glider realism

Postby Natovr » Tue Apr 21, 2009 1:10 pm

I don't think this sould be on the wiki.. the mailing list would be a much better place
Callsign: ZS-NVR (mil/priv)IVA-003 (com)
Part of Island Virtual Airways, one of Flightgear's
Natovr
 
Posts: 958
Joined: Fri Feb 22, 2008 12:11 pm
Location: United Queendom

Re: Improving glider realism

Postby Hooray » Tue Apr 21, 2009 5:24 pm

Okay, that makes the whole thing a bit more tangible.

Lots of documentation on customizing FlightGear is available in the base package which is the "data" folder that contains all resources related to the data package, commonly referred to as "FG_ROOT". So, most docs can be found in $FG_ROOT/Docs

There's a file named "README.protocol"

This describes how the generic XML protocol system can be used to create simple I/O protocols very easily, without having to modify FlightGear source code.


I looked into this, and much of it can already be done with the XML protocol system, for example by just ommitting any field separators between chunks:
Code: Select all
<PropertyList>
 <generic>

  <output>
   <line_separator>newline</line_separator>
   <var_separator></var_separator> <!-- none -->
</output>
</generic>



This lacks however some flexibility in various areas, for example the protocol "preamble" and "postamble" (see Readme.protocol) is currently defined statically and cannot be based on dynamic values (property tree).

This would however be required for things like the date timestamp that you mentioned.
But this would be pretty easy to fix by also supporting the "chunk" syntax directly within the preamble tag, so that the preamble or postamble can also be made up of chunks that are based on properties.

Without such a modification, we would be restricted to having a statically defined preamble, that would be the same for each saved flight:

Code: Select all
<preamble>AXXXFlightGear Simple IGC Test
HFDTE101010                   <!-- FIXME: DATE of the log DDMMYY - this is important to create the full timestamp of each B record -->
HFFXA035                       
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG       
HFGIDGLIDERID:B21             <!-- just a comment, but usually used to identify trace when multiple traces loaded-->
HFDTM100GPSDATUM: WGS-1984   <!-- gives datum used by GPS - just leave this line as is-->
HFRFWFIRMWAREVERSION: 2.55   
HFRHWHARDWAREVERSION: 2008   
HFFTYFRTYPE: FlightGear Simple IGC Test
HFGPSGPS:FlightGear Flight Simulator
HFPRSPRESSALTSENSOR: FlightGear Flight Simulator
HFCIDCOMPETITIONID:B21  <!-- comment, but also may be used to identify trace on map (vs HFGIDGLIDERID)                      -->
HFCCLCOMPETITIONCLASS:fgfs
I013638FXA                          <!-- this line is important for some software, modifies B record format with fix accuracy in last 3 digits -->
</preamble>
   <postamble>G00000</postamble> <!-- checksum -->


For example, in order to write out a valid timestamp using the IGC syntax, one could use something like the following:
Code: Select all
<!-- FIXME: uses UTC time -->
   <chunk>
    <name>timestamp:hh</name>
    <type>int</type>
    <format>B%d</format>
    <node>/sim/time/utc/hour</node>
   </chunk>

   <chunk>
    <name>timestamp:mm</name>
    <type>int</type>
    <format>%d</format>
    <node>/sim/time/utc/minute</node>
   </chunk>

   <chunk>
    <name>timestamp:ss</name>
    <type>int</type>
    <format>%d</format>
    <node>/sim/time/utc/second</node>
   </chunk>


This would write out the UTC time in the HHMMSS format required, directly after the initial B.

Apart from that, these chunks support C-format like specifiers in order to format values from the property tree, so this is already fairly powerful.

The lat/lon values are specified differently in IGC, because they use a suffix to indicate NORTH/SOUTH, EAST/WEST, while in FG the lat/lon strings use a slightly different format. Also, they don't use any decimal notation in IGC format.

So these properties cannot be directly used, but it would be possible to use a separate nasal script to convert the property format into a different notation and publish that using another property, or directly also publish such properties in an IGC-compatible format in the property tree from C++ (the altitude is currently not provided in feet but in meters, but these can be easily converted by making use of the <factor> tag to convert feet to meters).

Thus, it seem that implementing full support for IGC-like protocols in the XML property system would mostly require a handful of enhancements to the XML protocol system. Directly publishing some additional properties in valid IGC format would simplify the whole thing.

But another viable option would be to provide support for Nasal scripts to be embedded in XML protocols, so that XML protocols can have their own scripts to massage properties into different formats. This would be consistent with the way Nasal scripting is increasingly supported in other XML files such as those config files related to GUI, joystick, or object animations.

The generic XML protocol is implemented in $FG_SRC/Network/generic.cxx.

Of course it's possible to implement IGC support from scratch, but that seems much more complicated than it needs to be, especially because the XML protocol system could either by somewhat enhanced, or a separate Nasal script could be used to completely implement IGC support without relying on the XML protocol system.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby Hooray » Tue Apr 21, 2009 5:34 pm

B21 wrote:*But* a TE vario is only a few lines of code (you just have to understand the physics - potential energy = mass x G x height, kinetic energy = 0.5 x mass x velocity squared) and a netto vario means just adding a section that interpolates the polar of the glider - again just a few lines of code. Then you have an instrument that behaves in a pleasingly accurate way - e.g. it shows a bit of sink as you pull up (and increase the g-loading on the wings), and shows massive sink if you open the airbrakes, or the needle just sags a bit if you leave the wheel down.


Most instrument backend implementations are to be found in the $FG_SRC/Instrumentation folder, these are all implemented in C++.

But according to your descriptions, it seems that one could also just use a Nasal script to provide the properties required for a more accurate vario readout and instrument behavior for gliders (most instruments in FG follow the MVC pattern in that their visual appearance and control logics are separately implemented, so that you can indeed easily take existing instruments and simply make them refer to different input sources that are provided by the property tree, so that their behavior is largely modeled by the backend).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby B21 » Tue Apr 21, 2009 7:14 pm

the mailing list would be a much better place


sure - I'm just getting the hang of the wiki -- forums -- mailing list. As a newbie each of those pieces seem fragmented.

From this bulletin board I can't find a link to http://www.flightgear.org, and I absolutely can't work out how you would collect ridgelift calculation or IGC file generation information on a single mailing list (FlightGear-Devel?) - Do you store that stuff purely in an email archive without using a wiki to hold development info at all ?

cheers,
B21 @ noob
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Re: Improving glider realism

Postby Hooray » Tue Apr 21, 2009 8:37 pm

sure - I'm just getting the hang of the wiki -- forums -- mailing list. As a newbie each of those pieces seem fragmented.


Actually, I think you did a pretty good job finding the right places for everything so far ;-)

Natovr wrote:I don't think this sould be on the wiki.. the mailing list would be a much better place


I think you are probably referring to this discussion in general because it's development related, and not so much to the information that was posted to the wiki?
If that's wrong, I disagree - the wiki is certainly a much better place to collect and maintain such information and documents than the mailing lists, or even than these forums.

From this bulletin board I can't find a link to http://www.flightgear.org, and I absolutely can't work out how you would collect ridgelift calculation or IGC file generation information on a single mailing list (FlightGear-Devel?) - Do you store that stuff purely in an email archive without using a wiki to hold development info at all ?


No, that's clearly a misconception: the wiki is definitely the right place to store such documentation, information and anything else that isn't directly related to actually "discussing" things in the literal sense, which is supposed to happen using these forums and the mailing lists, it's however important to keep in mind that these forums are mostly used and driven by users and base package contributors and that they are not the primary means to conduct core development related discussions, which are supposed to take place on the FlightGear developer's mailing list, where discussions are usually more technical and feedback in general more reliable (these forums are mostly user-driven and you get to see few core developers regularly participating here, most core developers consider the mailing lists the primary and official means of support and community interaction).

The wiki is another thing that is mostly community driven.
So if you find some questions or issues insufficiently dealt with or completely unanswered on the forums or the wiki, you are well advised to check back with the developer's mailing list first.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby Hooray » Wed Apr 22, 2009 10:43 pm

B21 wrote:*But* a TE vario is only a few lines of code (you just have to understand the physics - potential energy = mass x G x height, kinetic energy = 0.5 x mass x velocity squared) and a netto vario means just adding a section that interpolates the polar of the glider - again just a few lines of code. Then you have an instrument that behaves in a pleasingly accurate way - e.g. it shows a bit of sink as you pull up (and increase the g-loading on the wings), and shows massive sink if you open the airbrakes, or the needle just sags a bit if you leave the wheel down.

Anyway I've written both a TE and netto vario for FSX so you've got no excuses.


I just looked at your wiki page and the descriptions/formula you put there for a TE vario.

That seemed pretty interesting and intuitive.
So for testing purposes, I implemented your formula as a simple Nasal script (Nasal is FlightGear's integrated scripting language).
The script is much more bloated and verbose than normally required, it could probably be downstripped to just 10% of it once it's verified to work properly. At the moment, it's pretty excessive (and performance-wise unoptimized) about writing everything to the property tree for debugging purposes.

The script computes all required variables and publishes all of them into the property tree at /instrumentation/te-vario - you can browse to that branch of the property tree using the property browser that is available in the main menu in FlightGear.

If you want to check it out, you only need to save the script nto $FG_ROOT/Nasal with a filename that has a ".nas" extension, for example "te-vario.nas", then you can see all values updated dynamically in the property browser, so that they could be used to drive arbitrary FlightGear instruments (assuming I didn't mess up your formula anywhere!).



Code: Select all
_setlistener("/sim/signals/nasal-dir-initialized", func {

 var FT2M = 0.30480;
 var KT2M = 1852/3600;
 var square = func(x) {return x*x};
 
 var location = "/instrumentation/te-vario/";
 ##
 # expose all variables to the property tree for inspection and debugging
 var current_height_meters_prop      = location ~ "current-height-m";
 var previous_height_meters_prop   = location ~ "previous-height-m";
 
 var current_airspeed_mps_prop      = location ~ "current-airspeed-mps";
 var previous_airspeed_mps_prop      = location ~ "previous-airspeed-mps";
 
 var current_systime_prop         = location ~ "current-systime";
 var previous_systime_prop         = location ~ "previous-systime"; #OMIT: wrong err msg line no
 var update_rate_sec_prop         = location ~ "delta-secs";
 var te_reading_prop            = location ~ "te-reading-mps";
 
 # initialize all properties with some defaults:
 setprop(current_height_meters_prop, getprop("/position/altitude-ft") * FT2M);
 setprop(previous_height_meters_prop,getprop("/position/altitude-ft") * FT2M);
 setprop(current_airspeed_mps_prop,  getprop("/velocities/airspeed-kt") * KT2M);
 setprop(previous_airspeed_mps_prop,  getprop("/velocities/airspeed-kt") * KT2M);
 setprop(current_systime_prop,systime() );
 setprop(previous_systime_prop,systime() );
 setprop(update_rate_sec_prop, getprop(current_systime_prop)-getprop(previous_systime_prop));
 
 ####
 # callback function that is invoked to update all properties
 var update_te_reading = func {
 
  setprop(previous_airspeed_mps_prop,  getprop(current_airspeed_mps_prop));
  setprop(previous_systime_prop,getprop(current_systime_prop) );
  setprop(previous_height_meters_prop, getprop(current_height_meters_prop));
  setprop(current_systime_prop,systime() );
  setprop(update_rate_sec_prop, getprop(current_systime_prop)-getprop(previous_systime_prop));
  setprop(current_height_meters_prop, getprop("/position/altitude-ft") * FT2M);
  setprop(current_airspeed_mps_prop,  getprop("/velocities/airspeed-kt") * KT2M);
 

 ## formula:
 # TE reading = (h2-h1)/t + (v2^2 - v1^2) / 19.62
  var uncompensated = (getprop(current_height_meters_prop)-getprop(previous_height_meters_prop)) / getprop(update_rate_sec_prop);
  var adjustment = (square(getprop(current_airspeed_mps_prop))-square(getprop(previous_airspeed_mps_prop))) / 19.62;#FIXME
  var te_reading = uncompensated + adjustment;
  # publish value to property tree
  setprop(te_reading_prop,te_reading);
  settimer(update_te_reading, 1/3 );
 };
 
 update_te_reading();
});
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Improving glider realism

Postby HHS » Wed Apr 22, 2009 10:58 pm

WooT wrote:In my honnest opinion, the gliders in FG still need a lot of improvements, but the ASK21 is yet in a good, usable state. It has a compensated, audio variometer, that works quite well. I don't know if it i really realistic, but this audio vario helps me a lot in thermals and ridge.
http://wiki.flightgear.org/index.php/Schleicher_ASK_21



I did this gauge, but I'm not a real glider pilot. I could only remember the principe and the sound from two of my flights as pax and I used some videos in the Internet I found as reference.
I'm not sure about if the real thing works like that and I'm very sure it can be enhanced.
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: Improving glider realism

Postby B21 » Sat Apr 25, 2009 3:52 pm

Thanks Hooray this looks pretty good.

It is *easy* to tell whether you have a TE-compensated vario versus a simple rate-of-climb: just speed up to 80 knots (either vario would show sink ~2 or 3 knots) and PULL-UP into a steep climb. The uncompensated vario will swing into a strong POSITIVE (i.e. CLIMB) reading whereas the TE vario will be clever and work out your TOTAL energy has not increased and continue to show a sink reading.

On this basis I can say with 100% certainty the current ASK21 has an uncompensated vario, but with Hooray's code it looks a snap to put in a real instrument. The audio is uncompensated as well but also has quite a high averaging factor which introduces a lag so it's harder to spot what's going on.

I'll be able to plug this stuff together soon but I'm still at the very basics of understanding the FG config. I have FG plus the ASK21 running on a non-flightsim machine that has a fast internet connection for the download (but I'm flying the sim with the keyboard and have no graphics card) and I haven't transferred the large install files to my home flightsim machine that has the suitable config.

FYI the 'delay' factor for instruments (i.e. particularly the vario) is something that has to be explicitly designed for (the 'instantaneous' vario reading could have spikes for any reason, depending on how the variables it's depending upon are implemented). E.g. in FSX the windspeed shifts in gusts are instantaneous, which would drive a vario with a simple formula bonkers. For the flight model this is rarely an issue because 'spikes' can be very short and the mass of the aircraft features in the formula somewhere and ths damps out the inputs. In an instrument though, you could see spikey needle movements. The general technique is to use a formula like "TE_needle = TE_needle * 0.9 + te_reading-mps * 0.1".

Cool stuff,

B21
B21
 
Posts: 12
Joined: Mon Apr 20, 2009 10:42 pm

Next

Return to Weather

Who is online

Users browsing this forum: No registered users and 2 guests