Hi Turbo,
Both your points are valid.
1) As I pointed out, when the conditions are tough, I'm not looking at my
PDA (which incidentally is why I've not found the thermal radar very
helpful), I'm working hard at climbing. Yes, if I kept looking at the PDA I
would know when I hit what XCSoar estimates is final glide, but why can't
XCSoar give me a realistic estimate in the first place? Remember, I'm a
simple chap - if I'm at 4,0000 ft and XCSoar says I need to climb 3,000 ft,
I'm going to make 7,000 ft my mental target and - assuming the thermal
doesn't weaken - see what XCSoar says when I get there, or at least, close
to there.
2) Again a fair comment. But what's better - me make an estimate of 1 knot
by way of the MacCready setting, actually achieve 2 knots, and have XCSoar
make a somewhat inaccurate estimate of my actual height below final glide,
or have XCSoar assume an *infinite* climb rate and thus give me a quite
inaccurate estimate?
If XCSoar takes drift into account, the accuracy of its above/below final
glide calculations are governed by how accurately the MacCready setting
matches the actual climb rate achieved (and by the accuracy of the wind
estimates), but to my mind the real issue is not whether to use the
MacCready setting in above/below final glide calculations, but how
accurately you (or XCSoar) set the MacCready setting in the first place.
Cheerio, Michael
On 22 November 2011 21:56, Tobias Bieniek <tobias.bien...@gmx.de> wrote:
> Hi Michael,
>
> these scenarios seem reasonable, but they have at least two flaws.
>
> 1) While circling you should monitor the final glide value. In your
> scenarios it seems like you take the value before circling, then
> circle and after circling for the amount of altitude that XCSoar told
> you before starting to circle you will stop. This is obviously not
> perfect and leads to the second more important problem.
>
> 2) Your scenarios only work if you would hit a thermal with the exact
> lift value that you had set as the MC value. If the MC value isn't
> fitting the additional amount of altitude that XCSoar predicted due to
> the wind drift is also wrong since the time you need to spend in the
> themal won't fit.
>
> Turbo
>
>
> 2011/11/22 Michael Brandon <mikezulubr...@gmail.com>:
> > 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
