That is a valid question and by reading both feature requests it seems that people are actually requesting both independently. My personal opinion would favor the L/D relative to the airmass. If I understand correctly that version would take the wind into account, right? I don't think the geometric L/D is particularly useful as it doesn't even take the wind drift in cruise into account. Not sure how the others do it but if I remember right LK8000 shows the geometric value.
Turbo 2011/11/22 John Wharington <jwharing...@gmail.com>: > Tobias, > > Is that request for required L/D relative to ground or relative to air > mass? There's a big difference as you know. > > On Tue, Nov 22, 2011 at 10:29 PM, Tobias Bieniek <tobias.bien...@gmx.de> > wrote: >> Nothing to add, exactly what I meant. There is a request to show the >> required L/D on the airport labels instead and we would want to make >> this configurable anyway. I don't think it would be too hard to also >> provide an additional option to differentiate between the two options >> I mentioned in the last post. >> >> Turbo >> >> >> 2011/11/22 Sascha Haffner <s_haff...@yahoo.com>: >>> Hi Tobias, >>> >>> thank you ... I can only support your suggestion. >>> >>> You probably meant it, but just to make it clear the Arrival Altitude would >>> include: >>> - Height above ground of the selected waypoint also displayed in the >>> waypoint label >>> - Considering, wind, bugs, MC setting or at least safety MC setting (and >>> even the recently discussed degradation % value) >>> - Also considering safety altitude? (for me not neccessary, I can decide >>> depending on the situation if 0m, 200m or even 500m arrival altitude is >>> safe). >>> - Considering, also flight around terrain, airspace, but configurable on/off >>> >>> Any thoughts? >>> >>> Sascha >>> Von: Tobias Bieniek <tobias.bien...@gmx.de> >>> An: >>> Cc: "xcsoar-user@lists.sourceforge.net" <xcsoar-user@lists.sourceforge.net> >>> Gesendet: 12:06 Dienstag, 22.November 2011 >>> Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released >>> >>> Hi everyone, >>> >>> I think I found one possible cause of the confusion. We are not >>> seperating the two values properly and I actually noticed that before >>> on some other occasions in the code itself. We should at least start >>> to use the right names for both values and I would propose the >>> following: >>> >>> Arrival Altitude: The altitude that you would arrive at the airfield >>> assuming a pure glide to it without circling involved and thus no >>> circling drift. >>> >>> Required Altitude: The amount of altitude that is required to reach >>> the airfield. This would include the circling drift since you actually >>> need to climb this altitude because otherwise you wouldn't reach it. >>> This value however should strictly have the opposite sign, so I'm not >>> quite sure if it's the right name for it. Required Altitude is also a >>> little ambiguous since it could also mean the actual altitude on which >>> you should leave the next thermal if you want to reach your >>> destination. I'm open for suggestions here. >>> >>> Once these terms are defined properly, we (the developers) should >>> revisit the source code and check whether they are used properly. I >>> can't think of a better solution so far than making the displayed >>> numbers configurable, but I'm open to suggestions. The traffic on the >>> mailing list about this topic should be a simple indicator that this >>> is an important topic and that there are plenty of opinions about it. >>> >>> Turbo >>> >>> >>> 2011/11/22 Sascha Haffner <s_haff...@yahoo.com>: >>>> Hi, >>>> >>>> the intensity and length of our discussion shows that people feel strongly >>>> about the respective way of calculating AltRequired because they each >>>> "feel >>>> safe" when they see the expected values according to their experience and >>>> their routines. Therefore there is no right or wrong way of calculating / >>>> displaying this, just different ones and I would be happy if XCSoar would >>>> acknowledge both ways. >>>> >>>> As for myself I prefer the way the LX, Cambridge etc. instruments >>>> calculate >>>> the AltRequired to a single waypoint and I use XCSoar the same way Scott >>>> described, but that is not the point - it would be best to find a solution >>>> and I have to admit, I can't (yet) suggest a clean and elegant one. I can >>>> see John's point, that making XCSoar configurable in that way might >>>> confuse >>>> newcomers, but I can't think of an alternative. >>>> >>>> To summarize things: The altreq. value shown on the glide bar and the >>>> labels >>>> is computed differently since the new solver was introduced with vers. >>>> 6.1.x. I believe. The last stable vers. using the old solver was vers. >>>> 6.0.10. The new way seems to lead to fast dropping values of altreq. >>>> shown >>>> in the glide bar when wrongly circling in a lift to weak to compensate for >>>> the drift while circling, which is scientifically correct, but is >>>> different >>>> from hardwired computers (e.g. Cambridge, LX etc.). >>>> >>>> Now getting back to a possible solution. Please correct me if I am wrong, >>>> the glide bar is intended to show the total altreq. for the complete task >>>> and therefore helpful when in competition. The altreq. displayed next to >>>> the labels Max Kellermann explained recently to me are calculated >>>> differently by separate solvers considering flight around terrain, >>>> airspace, safety MC, wind etc. (vers. 6.1.x and newer). Therefore one >>>> experiences slight difference in the altreq. values displayed in the glide >>>> bar and on the labels (when above glidepath). If XCSoars already uses >>>> different methods for glide bar and labels, couldn't we make the glide bar >>>> configurable for a) task mode (as implemented in 6.2.3) and b) abort mode, >>>> meaning a task to a single (final) waypoint, showing the same value as the >>>> label shows and using the "old" method. So if below glide path the label >>>> would show "not reachable" while the glide bar would show the e.g. >>>> -500feet >>>> below glide path. How one gets above glide path is up to the pilot and >>>> his >>>> decision whether to circle, chance an outlanding or hope for lift during >>>> straight flight etc. >>>> >>>> Any thoughts for solutions? And many thanks to the developers for their >>>> hard work and for following and allowing this discussion. >>>> >>>> Cheers, >>>> Sascha >>>> >>>> >>>> Von: David Lawley <davidlaw...@hotmail.com> >>>> An: tangoei...@gmail.com; m...@duempel.org >>>> Cc: xcsoar-user@lists.sourceforge.net >>>> Gesendet: 2:10 Dienstag, 22.November 2011 >>>> Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released >>>> >>>> My only comment is i was perfectly happy with the behaviour of final glide >>>> in 5.2, everytime it predicted the final glides perfectly. >>>> >>>> Storm in a teacup methinks! >>>> >>>> Dave >>>> >>>>> From: tangoei...@gmail.com >>>>> Date: Mon, 21 Nov 2011 19:11:09 -0500 >>>>> To: m...@duempel.org >>>>> CC: xcsoar-user@lists.sourceforge.net >>>>> Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released >>>>> >>>>> >>>>> On Nov 21, 2011, at 5:48 PM, Max Kellermann wrote: >>>>> >>>>> > On 2011/11/21 23:40, Evan Ludeman <tangoei...@gmail.com> 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. >>>>> > >>>>> > What XCSoar shows is not the height relative to the glide slope. >>>>> > >>>>> > What XCSoar shows is how much you need to climb to reach your goal. >>>>> > >>>>> > The height relative to the glide slope is a theoretical number that is >>>>> > of no practical use for a glider, even if it might be appealing to >>>>> > calculate it, and even if it gives you the illusion that it is useful. >>>>> > >>>>> > Max >>>>> > >>>>> >>>>> I disagree, rather strongly. >>>>> >>>>> 30 miles out on final glide, 500' below glide slope, I am not looking for >>>>> a thermal to center and circle in, I am looking for enroute lift to get >>>>> up >>>>> to a comfortable final glide. The height below glide slope is preferable >>>>> to >>>>> height required to climb (in circling). I'm rather astonished to find out >>>>> about how XCS is doing these calculations, I didn't know this but in >>>>> retrospect it does explain (perhaps) some of the discrepancies I have >>>>> noted >>>>> between XCS and my C-302/303. As previously noted, I always go with the >>>>> 302/303 as primary reference for final glide. >>>>> >>>>> This whole conversation completely astonishes me. I never suspected that >>>>> anyone doubted the utility of height relative to glide slope for final >>>>> glide. >>>>> >>>>> It appears to me that there are some who are out to put "all the brains >>>>> in >>>>> the box". That's an interesting intellectual and software engineering >>>>> challenge to be sure, but it's not what I am interested in. I am solely >>>>> interested in aids to my situational awareness. I find height relative to >>>>> glide slope to be such an aid. Height required to climb given an assumed >>>>> thermal strength... not so much. >>>>> >>>>> -Evan >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> Xcsoar-user@lists.sourceforge.net >>>>> 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 >>>> Xcsoar-user@lists.sourceforge.net >>>> 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 >>>> Xcsoar-user@lists.sourceforge.net >>>> 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 >>> Xcsoar-user@lists.sourceforge.net >>> 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 >>> Xcsoar-user@lists.sourceforge.net >>> 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 >> Xcsoar-user@lists.sourceforge.net >> 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 Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
