Lovely descriptions Michael... really illustrates nicely. What ever we decide
on enhancements etc or not, I like the style of documentation. I would like to
see that kind of documentation in an appendix - e.g. "Understanding
calculations" or similar.
Scott
On 22/11/2011, at 9:40 PM, Michael Brandon wrote:
> Hi folks,
>
> Could I present a few scenarios and see where they take us? Bear with me...
>
> Scenario 1:
> - I'm at 4,000 ft
> - the day has died and there is no lift
> - the MacCready is set to zero
> - XCSoar reports that I'm 3,000 ft below final glide
>
> It's clear that I'm not going to make it home, so all I can do is see what
> landing places XCSoar says are within glide range and head for the most
> promising option. If there are none, I'll be looking at my outlanding options.
>
> Scenario 2:
> - I'm at 4,000 ft
> - there is still lift about
> - the MacCready is set to a non-zero value
> - XCSoar reports that I'm 3,000 ft below final glide
> - there is no wind
>
> Being the simple fellow that I am, I think to myself "if I can climb 3,000 ft
> I have a chance of getting home". If I hit a thermal straight away, I think
> to myself "if I can climb to 7,000 ft I have a chance of getting home". I
> ride that thermal to 7,000 ft, and XCSoar tells me I'm on final glide. I'm a
> happy chappy.
>
> Scenario 3:
> - I'm at 4,000 ft
> - there is still lift about
> - the MacCready is set to a non-zero value
> - XCSoar reports that I'm 3,000 ft below final glide
> - there is a headwind on the final leg
> - XCSoar ignores drift in its calculations
>
> Being the simple fellow that I am, I think to myself "if I can climb 3,000 ft
> I have a chance of getting home". If I hit a thermal straight away, I think
> to myself "if I can climb to 7,000 ft I have a chance of getting home". I
> ride that thermal to 7,000 ft, but I've drifted away from home, so XCSoar
> tells me I'm still 1,000 ft below final glide. I climb again, this time to
> 8,000 ft, but XCSoar is still telling me I'm below final glide. I think to
> myself "that damned XCSoar is lying to me". I'm a confused and less than
> happy chappy. If this keeps happening, I'd probably end up dubious about
> XCSoar's judgement on whether I was above or below final glide, and certainly
> ignoring it's judgement of by how much. That doesn't help me.
>
> Scenario 4:
> - I'm at 4,000 ft
> - there is still weak lift about
> - the MacCready is set to a non-zero value
> - XCSoar reports that I'm 3,000 ft below final glide
> - there is a tailwind on the final leg
> - XCSoar ignores drift in its calculations
>
> Being the simple fellow that I am, I think to myself "if I can climb 3,000 ft
> I have a chance of getting home". If I hit a thermal straight away, I think
> to myself "if I can climb to 7,000 ft I have a chance of getting home". I
> ride that thermal to 7,000 ft, but I've drifted closer to home, so XCSoar
> tells me I'm now 1,000 ft above final glide. I've wasted time and effort
> trying to climb higher than I needed in a weak thermal. I think to myself
> "why did XCSoar say I needed to climb 3,000 ft, but when I did I ended up so
> far above final glide?". Bear in mind that when I'm climbing in less than
> ideal conditions, I'm not looking at my PDA, I'm looking outside and focusing
> on thermalling, so I'll probably miss the point at which the XCSoar
> above/below indicator switches from red to green. Again I'm a less than happy
> chappy, and again I learn to mistrust XCSoar's calculations.
>
> I'd be a much happier chappy, and would place much more faith in what XCSoar
> tells me, if it takes drift into account in its calculations of above/below
> final glide. I want to know that I really need to climb 4,500 ft if there's a
> headwind, or just 2,000 ft if there's a tailwind. Then I'd have a realistic
> idea of how far I needed to climb, and while the achieved climb rate might
> differ from the MacCready setting, it's going to be a much better estimate
> than ignoring drift based on forecast climb rate.
>
> If the XCSoar developers implemented an option to enable or disable this
> behaviour, I know which setting I'd be choosing.
>
> Cheerio, Michael
>
> On 22 November 2011 11:17, Morgan Hall <morh...@gmail.com> wrote:
> Essentially this is like "Club" Mode to me. I rarely enter a task or even
> select a destination waypoint since my goal is usually to return home. For
> outlanding options, I'm taking a quick look at the arrival height on the map
> display. I just want those numbers to be "final glide" values given the
> current assumptions the system is working off of. (wind, altitude, MC,
> safety alt)
>
> If I'm beating my way back into a headwind at MC 0 I just want to know if I
> dead glide it, where will I end up (roughly). If I hit lift and try to climb
> I'd just like to know if I'm gaining or loosing ground at that moment.
>
> I'm admittedly a few revs behind the current, so I think this is the behavior
> the version I'm running is using at the moment, I'd have been shocked if I
> set to MC .5 and went from 500 below glide to thousands below glide. I can
> understand the logic and that for competition you might need that logic in
> place, but it doesn't align with the way I think or expect the system to
> behave.
>
> I should learn the contest capabilities more, but for myself and the people
> I've turned on to XCSoar the simple mode I usually recommend is the basic
> club mode from above. Pretty much set it and don't mess with it. I do
> fiddle with my L-Nav more. MC value changes for what-if scenarios and
> waypoint changes for alternates. That's only because it doesn't provide as
> much "at-a-glance" data as XCS.
>
> Great work you guys are doing.
>
> Morgan
>
>
>
> On Mon, Nov 21, 2011 at 3:57 PM, Ramy Yanetz <ryan...@yahoo.com> wrote:
> I also want to thank all developers for the hard work they do. All I ask, is
> please don't assume that everyone fly the same way you do. I know many very
> successfully XC pilots who use low MC on final glide and do not set tasks.
> They are not racing to a goal, they just going on a long shallow final glide
> back home at the end of the day after a long flight. Arrival altitude, or
> altitude difference is crucial for decision making. Adding more configuration
> options is fine, but Please don't change basic functionalities.
>
> Thanks
>
> Ramy
>
> On Nov 22, 2011, at 1:39 AM, Ramy Yanetz <ryan...@yahoo.com> wrote:
>
> > Turbo, it is not just the final glide bar. If it was just the bar than we
> > could just ignore it. But as I said, it is all the arrival altitude info
> > boxes AND all the waypoint details. I guess the labels as well, but they
> > typically not showing when you below glide so I can't confirm this. So yes,
> > the misleading calculation is everywhere.
> >
> > Ramy
> >
> > On Nov 22, 2011, at 12:29 AM, Tobias Bieniek <tobias.bien...@gmx.de> wrote:
> >
> >> Too be honest, I've haven't entirely understood yet where the issue is
> >> actually happening. Is it just the final glide bar or also the arrival
> >> height labels for airports on the map?! I'm hoping to get some more
> >> input from the other developers before making any fast decisions.
> >>
> >> Turbo
> >>
> >>
> >> 2011/11/21 Ramy Yanetz <ryan...@yahoo.com>:
> >>> Sounds like most of the repliers prefer the conventional way of
> >>> calculating
> >>> arrival altitude without assuming that the only lift I will find along the
> >>> way is 0.5 knot since I am using conservative STF and that I will be silly
> >>> enough to circle in it while drifting more than climbing. I can't imagine
> >>> why someone would prefer it this way but I realize that there will always
> >>> be
> >>> opposite opinions.
> >>> So the conclusion is to make it configurable. I am concerned that such a
> >>> critical change was made without making it an option.
> >>> I would like to request that any enhancement made going forward will be
> >>> *always* made configurable if it will change any existing behavior. This
> >>> is
> >>> crucial to make XCS safe and reliable.
> >>> Turbo, please let me know if I still need to open a ticket. I think this
> >>> should be fixed ASAP, I personally wouldn't want to fly with it again this
> >>> way, after almost picking up an alternate landing believing XCS which was
> >>> telling me there is no way I can make it... I may need to switch back to
> >>> my
> >>> old PDA running WinPilot until this bug is fixed..
> >>> Ramy
> >>>
> >>> On Nov 21, 2011, at 7:05 PM, Sascha Haffner <s_haff...@yahoo.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> regarding speeds to fly - I use my LX5000 for speed to fly indication
> >>> (beep
> >>> sounds) and therefore I set my best guess for MC at the LX5000 (Cambridge
> >>> etc). XCS I use with a safety MC value (higher, than the MC in the LX)
> >>> with Vers. 6.0.10 (old solver) to give me conservative values of
> >>> AltRequired
> >>> / Arrival Height. While comparing the arrival heights of the two
> >>> instruments it gives me a nice redundancy (using even two GPS sources,
> >>> Flarm
> >>> and LX) and ease of mind.
> >>> But again, I understand not everyone flies that way or has two
> >>> instruments -
> >>> therefore please please make the solver use configuable.
> >>>
> >>> Thank you guys.
> >>>
> >>> Cheers,
> >>> Sascha
> >>> Von: Evan Ludeman <tangoei...@gmail.com>
> >>> An: xcsoar-user@lists.sourceforge.net
> >>> Gesendet: 17:52 Montag, 21.November 2011
> >>> Betreff: Re: [Xcsoar-user] About MC and tasks
> >>>
> >>> No, you're certainly not alone. I've been trading email with JW privately
> >>> this morning.
> >>>
> >>> Ramy, I agree with everything you've said here. I fly the same way.
> >>>
> >>> FWIW, I never use a PDA for final glide... there's too darned many ways to
> >>> get it wrong and XCS seems to be exacerbating the trend here. I rag on
> >>> other aspects of the 302/303, but one thing it does pretty well is
> >>> calculate
> >>> a glide to a turnpoint. It will also do a final glide with HW/TW
> >>> component
> >>> wind which is *really* useful. and yet to be picked up by XCS.
> >>>
> >>> Another thing I pretty much never do is take speed to fly information from
> >>> any instrument. You understand why!
> >>>
> >>> There's a critical need in soaring software to separate speed to fly from
> >>> glide calculation that so far hasn't been met by anyone. It is often the
> >>> case that the fast (and safe) way home is Mc 1 or 2 speed to fly and Mc 3
> >>> or
> >>> better on final glide. Likewise, speed on task need not be calculated by
> >>> your speed to fly Mc setting.
> >>>
> >>> -Evan Ludeman / T8
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Nov 21, 2011 at 11:24 AM, Ramy Yanetz <ryan...@yahoo.com> wrote:
> >>>
> >>> After using XCSoar for a while I am very impressed with it but at the same
> >>> time surprise that it assumes that everybody fly according to MC theroy
> >>> and
> >>> with pre defined tasks. Most pilots I know, which are serious XC pilots,
> >>> do
> >>> not set tasks and do not fly according to MC theory, which is way
> >>> overrated.
> >>> In most place in western US you will want to fly at low MC to stay at the
> >>> sweet spot above the mountains and near the clouds. But it looks like
> >>> XCSoar
> >>> insists that if you don't fly according to MC you can't go anywhere since
> >>> you can't climb, and that if you fly for OLC than you also have a task pre
> >>> declared.
> >>> Flying strictly according to MC is a guarantee way to land out often. An
> >>> example from my last flight: release at 1500 feet, made 3 turns in 3
> >>> knots
> >>> and hit the inversion at 2000 feet, next thing you know XCSoar tells you
> >>> to
> >>> dive to the ground at 80+ knots at MC 3. Instead of flying at best glide
> >>> to
> >>> stay aloft. And if I change to mc zero it assumed I can not go anywhere
> >>> upwind since I can not climb. If so, how did I manage to fly 200km tip
> >>> toeing from one thermal to next at MC between zero and 0.5?
> >>> I think this is a flaw to assume this. Am I alone thinking this?
> >>>
> >>> Ramy
> >>> ------------------------------------------------------------------------------
> >>> 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
>
>
> ------------------------------------------------------------------------------
> 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
