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
