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
