I would also prefer the "old" behaviour of the final glide bar and support Evans point of view.
I use MC-Values for two different purposes: 1) Estimating task arrival time (can I still make the task or should I abort) I use the estimated average strength of the thermals I expect to encounter. 2) To set my own "pace" using it as an information for which speed to fly at the current sink. For this I use much lower values than "mode" 1 and I adjust constantly depending on the overall situation. In the final glide Im using "mode" 2 to as a safety margin and for the applicable STF to burn the margin slowly in a continous way. If I'm slightly below glidepath and theres hope for a climb ahead the set MC value (and therefore STF!) will be much lower than the expected climb rate. Depending on the overall situation (altitude, time of day, see "2") In this situation I DO NOT want to see any hypothetical altitude difference base on, lets say MC 0.5 and 15km/h headwind. I want to know how many meters am I below Glidepath with the set margin (MC 0.5) in this very moment. When the thermal I encounter is to weak to make up for the headwind, I see this quickly by a while circling and watching the arr-alt decrease further... - I am sure most pilots have a similar approach to that, and this is the way all the gliding computers behave. - The new approach is fine for estimates but confusing in the final glide. - I think Evans idea for an advanced feature to set two different MC values sounds interesting. Thank you all for your work ! Henrik PS: Which is the last xcs version, that is behaving the old way? Am 21.11.2011 23:50, schrieb John Wharington: > XCSoar allows you to fly according to your stated preferences. > On task, set a low Mc if that's how you want to go. Once you reach final > glide > (FG bar goes green, in positive), there are two ways to proceed: > - with auto mc on, keep climbing until MC has increased to the value > you would like to > conduct your final glide, then commence the final glide. If the MC > winds back down to below > your desired climb mc setting, you know you need to climb again. > - with auto mc off, set your higher MC and keep climbing until the FG > bar goes green, then > commence your final glide. If the final glide bar goes red/orange, > you know you need to climb again. > > > On Tue, Nov 22, 2011 at 9:40 AM, Evan Ludeman<[email protected]> wrote: >> Sorry John, no sale. We need height relative to glide slope at a pilot >> selectable Mc setting for final glide. If that's being eliminated in >> preference wind dependent height of climb required, that's a poor choice. >> >> The fact that you can't see the logic in my proposal is of no account. This >> is, in fact, the way a great number of champions fly in real life. >> >> -Evan >> >> >> On Mon, Nov 21, 2011 at 5:33 PM, John Wharington<[email protected]> >> wrote: >>> Thermal strength and wind are inherently uncertain, but are not entirely >>> random. >>> Having an estimate is better than assuming zero for each. >>> >>> For reasons described in my previous email, simply adding more >>> configuration options does not help. I fail to see the logic behind >>> having separate MC values for cruise-climb and final glide cycles and >>> shudder at the thought of how this would further confuse pilots. >>> >>> On Tue, Nov 22, 2011 at 9:26 AM, Evan Ludeman<[email protected]> >>> wrote: >>> >>>> As long as I can turn it off.... >>>> >>>> Here's the thing: thermal strength is inherently uncertain, therefore so >>>> is >>>> the wind drift and hence the total climb required. I see no purpose to >>>> this >>>> additional functionality that you propose on the screen final glide >>>> screen. >>>> It merely tells me what I already know intuitively. It could be used to >>>> calculate arrival time as John pointed out, but this leads back to my >>>> earlier point that there are a *lot* of pilots who effectively use >>>> different >>>> Mc values for speed to fly vs final glide calculations, for a whole >>>> bunch of >>>> good reasons. If you want to complicate XCS, this is my suggestion for >>>> doing so in a fashion that might be useful to advanced XC& racing >>>> pilots: >>>> give us the option of setting independent Mc values for final glide and >>>> speed to cruise. I promise you: this will get noticed. John Cochrane >>>> would >>>> be all over this in a minute. >>>> >>>> regards, >>>> >>>> Evan Ludeman / T8 >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> All the data continuously generated in your IT infrastructure >>>> contains a definitive record of customers, application performance, >>>> security threats, fraudulent activity, and more. Splunk takes this >>>> data and makes sense of it. IT sense. And common sense. >>>> http://p.sf.net/sfu/splunk-novd2d >>>> _______________________________________________ >>>> Xcsoar-user mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >>>> >>>> >> > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Xcsoar-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xcsoar-user
