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
