Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
On 08/28/2008 12:04 PM, Torsten Dreyer wrote: > Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag > for indicators like the HSI when getting outside the range of the VOR > station. > The benefit is: > - No more jitter for flag and needles That's not a benefit. The real instrument exhibits flicker when marginally out of range. Getting rid of the flicker is a Bad Idea. > - Ability to animate the OFF-Flag with a smooth transition. That's not very important, far less important than getting the previous item right. In many situations, the real flag exhibits a fast transition, faster than the blink of an eye. > - CDI and GS needle deflection shows correct values when in range That's not new. That should go without saying. > and show some wrong indication when the range is > exceeded Pilots don't like it when instruments "show some wrong indication", particularly when the flag is not clearly in the OFF state. Wrong GS indications can be fatal. > - CDI and GS needle start to move, even when the OFF flag is visible OK, but there are better ways to achieve this. The existing model of random flicker is _mostly_ a good idea, albeit imperfectly implemented. The real instrument exhibits flicker. 1) Slowing down the model's rate of flicker would be an improvement in realism. Right now it flickers at frame rate, whereas a coherence time on the order of a tenth of a second would be more realistic and more esthetically attractive. The patch to do this is vastly simpler *and* results in vastly more realism than trying to get rid of the flicker entirely. 2) Putting a time-based (not position-based) low-pass filter on the needle motion would be a good idea for multiple reasons, even when in range. This by itself would remove almost all of the esthetic objections to the flicker model. 3) Flag flicker by itself is much less of a problem, but if you really want smooth animation of the flag, again a time-based low-pass filter does the job. It should be asymmetric (fast-OFF, slow-ON). Also note that many instruments do *not* just attenuate the GS signal toward zero when out of range; for very good reasons they drive the needle to a full fly-up indication when out of range. Yes, there are some old, dumb instruments that do park the needle at zero, but it is a Bad Idea to assume that all instruments are old and dumb. Code to allow the instrument designer to implement whichever "parking" behavior is desired -- dumb or smart -- has been in the _Sport Model_ for years. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
> Hi Torsten, > > Does this patch work with any aircraft and nav radio, or do the individual > aircraft need to be updated to match. I did a quick test in the default > c172 flying from SJC to SFO, but the SFO 28R ILS seemed to have rock solid > needle response even on the ground at SJC (26+ miles away) and the "TO" > flag is showing. This will be a nice addition, but I just want to make > sure the default behavior scales fairly close to reality. > > Thanks, > > Curt. > Hi Curt I didn't test every aircraft we have in the repository, but it should work, since it does not change the properties from the models point of view. Thanks for committing Torsten - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
On Thu, Aug 28, 2008 at 3:03 PM, James Turner wrote: > I suspect there's lots of debate over decay functions - Torsten's > computation is cheap and seems reasonable, but I'll let people with > more aeronautical experience comment in detail. > > However, the use of random() in the existing code is much worse - > ultimately some semi-random model would be nice, but that would random > over much, much longer timer periods (hours or days) - the current > code causes the dreaded 'strobing' of reception (and in the dme code > as well), as the random() call is evaluated every update, i.e frame. > Hence random seems plain wrong to me (despite being motivated by a > worthwhile goal) so anything that replaces it with a stable decay > function gets my vote. Ok, I have committed this patch, we can always adjust the service volume later. Thanks, this is one thing that has been visually annoying for quite some time. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
On 28 Aug 2008, at 20:51, Curtis Olson wrote: > Does this patch work with any aircraft and nav radio, or do the > individual aircraft need to be updated to match. I did a quick test > in the default c172 flying from SJC to SFO, but the SFO 28R ILS > seemed to have rock solid needle response even on the ground at SJC > (26+ miles away) and the "TO" flag is showing. This will be a nice > addition, but I just want to make sure the default behavior scales > fairly close to reality. I suspect there's lots of debate over decay functions - Torsten's computation is cheap and seems reasonable, but I'll let people with more aeronautical experience comment in detail. However, the use of random() in the existing code is much worse - ultimately some semi-random model would be nice, but that would random over much, much longer timer periods (hours or days) - the current code causes the dreaded 'strobing' of reception (and in the dme code as well), as the random() call is evaluated every update, i.e frame. Hence random seems plain wrong to me (despite being motivated by a worthwhile goal) so anything that replaces it with a stable decay function gets my vote. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
Hi Torsten, Does this patch work with any aircraft and nav radio, or do the individual aircraft need to be updated to match. I did a quick test in the default c172 flying from SJC to SFO, but the SFO 28R ILS seemed to have rock solid needle response even on the ground at SJC (26+ miles away) and the "TO" flag is showing. This will be a nice addition, but I just want to make sure the default behavior scales fairly close to reality. Thanks, Curt. On Thu, Aug 28, 2008 at 2:04 PM, Torsten Dreyer wrote: > Here is a little patch that changes the behaviour of the VOR CDI and > OFF-flag > for indicators like the HSI when getting outside the range of the VOR > station. > > Currently, when flying at a distance between the effective_range and twice > the > effective_range of a VOR station, the in-range property is computed based > on > a random value, causing the OFF Flag and the CDI bar to perform an ugly > jitter. > > The attached patch introduces a new property signal-quality-norm which is > computed based on the distance to the station and the range. It is 1.0 when > the distance is less than the range and decreases by 1/x^2 for distances > greater than the range leading to a signal-quality-norm of 0.25 for > distances > two times the range, 0.125 for three times the range and so on. > The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed > squelch). > The CDI and GS needle deflection is multiplied with the > signal-quality-norm. > > The benefit is: > - Ability to animate the OFF-Flag with a smooth transition. > - CDI and GS needle deflection shows correct values when in range > (signal-quality-norm=1.0) and show some wrong indication when the range is > exceeded > - CDI and GS needle start to move, even when the OFF flag is visible > - No more jitter for flag and needles > > See the new SenecaII ki525a hsi as an example at > http://www.t3r.de/fg/navpatch.jpg > The numbers on the image are: > (1) the new property signal-quality-norm > (2) distance exceeds the effective-range by 30% > (3) NAV flag has a rotation animation bound to signal-quality-norm and is > partially visible > (4) CDI is partially deflected even with NAV flag shown > > This implementation better matches reality - at least, how I observed it > ;-) > > The attached patch is agains current HEAD. > > I hope the patch gets into CVS with the help of some kind commiter. > > Greetings, Torsten > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag
for indicators like the HSI when getting outside the range of the VOR
station.
Currently, when flying at a distance between the effective_range and twice the
effective_range of a VOR station, the in-range property is computed based on
a random value, causing the OFF Flag and the CDI bar to perform an ugly
jitter.
The attached patch introduces a new property signal-quality-norm which is
computed based on the distance to the station and the range. It is 1.0 when
the distance is less than the range and decreases by 1/x^2 for distances
greater than the range leading to a signal-quality-norm of 0.25 for distances
two times the range, 0.125 for three times the range and so on.
The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed
squelch).
The CDI and GS needle deflection is multiplied with the signal-quality-norm.
The benefit is:
- Ability to animate the OFF-Flag with a smooth transition.
- CDI and GS needle deflection shows correct values when in range
(signal-quality-norm=1.0) and show some wrong indication when the range is
exceeded
- CDI and GS needle start to move, even when the OFF flag is visible
- No more jitter for flag and needles
See the new SenecaII ki525a hsi as an example at
http://www.t3r.de/fg/navpatch.jpg
The numbers on the image are:
(1) the new property signal-quality-norm
(2) distance exceeds the effective-range by 30%
(3) NAV flag has a rotation animation bound to signal-quality-norm and is
partially visible
(4) CDI is partially deflected even with NAV flag shown
This implementation better matches reality - at least, how I observed it ;-)
The attached patch is agains current HEAD.
I hope the patch gets into CVS with the help of some kind commiter.
Greetings, Torsten
Index: navradio.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/navradio.cxx,v
retrieving revision 1.29
diff -u -p -r1.29 navradio.cxx
--- navradio.cxx 3 Aug 2008 14:34:42 - 1.29
+++ navradio.cxx 28 Aug 2008 18:28:08 -
@@ -35,6 +35,7 @@
#include
#include
+#include
#include "navradio.hxx"
using std::string;
@@ -68,6 +69,7 @@ FGNavRadio::FGNavRadio(SGPropertyNode *n
to_flag_node(NULL),
from_flag_node(NULL),
inrange_node(NULL),
+signal_quality_norm_node(NULL),
cdi_deflection_node(NULL),
cdi_xtrack_error_node(NULL),
cdi_xtrack_hdg_err_node(NULL),
@@ -176,6 +178,7 @@ FGNavRadio::init ()
to_flag_node = node->getChild("to-flag", 0, true);
from_flag_node = node->getChild("from-flag", 0, true);
inrange_node = node->getChild("in-range", 0, true);
+signal_quality_norm_node = node->getChild("signal-quality-norm", 0, true);
cdi_deflection_node = node->getChild("heading-needle-deflection", 0, true);
cdi_xtrack_error_node = node->getChild("crosstrack-error-m", 0, true);
cdi_xtrack_hdg_err_node
@@ -314,6 +317,8 @@ FGNavRadio::update(double dt)
bool has_gs = has_gs_node->getBoolValue();
bool is_loc = loc_node->getBoolValue();
double loc_dist = loc_dist_node->getDoubleValue();
+double effective_range_m;
+double signal_quality_norm = signal_quality_norm_node->getDoubleValue();
double az1, az2, s;
@@ -418,18 +423,32 @@ FGNavRadio::update(double dt)
effective_range
= adjustNavRange( nav_elev, pos.getElevationM(), range );
}
+
+effective_range_m = effective_range * SG_NM_TO_METER;
+
// cout << "nav range = " << effective_range
// << " (" << range << ")" << endl;
- if ( loc_dist < effective_range * SG_NM_TO_METER ) {
- inrange = true;
- } else if ( loc_dist < 2 * effective_range * SG_NM_TO_METER ) {
- inrange = sg_random() < ( 2 * effective_range * SG_NM_TO_METER
- - loc_dist )
- / (effective_range * SG_NM_TO_METER);
- } else {
- inrange = false;
- }
+//
+// compute signal quality
+// 100% within effective_range
+// decreases 1/x^2 further out
+//
+{
+double last_signal_quality_norm = signal_quality_norm;
+
+ if ( loc_dist < effective_range_m ) {
+ signal_quality_norm = 1.0;
+} else {
+ double range_exceed_norm = loc_dist/effective_range_m;
+ signal_quality_norm = 1/(range_exceed_norm*range_exceed_norm);
+}
+
+signal_quality_norm = fgGetLowPass( last_signal_quality_norm,
+ signal_quality_norm, dt );
+}
+signal_quality_norm_node->setDoubleValue( signal_quality_norm );
+inrange = signal_quality_norm > 0.2;
inrange_node->setBoolValue( inrange );
if ( !is_loc ) {
@@ -507,6 +526,7 @@ FGNavRadio::update(doub
