All good suggestions technically, but I think we miss the point. The point is
that rule number one for safe XC flights is to always keep a landing
option within safe glide. Rule of thumb for safe glide is between half to 2/3
of the published polar. there are very good reasons for that:
1 - Gliders typically perform 10% below the published polar
2 - Pilots don't always fly 100% accurately
3 - You may encounter significantly stronger head wind than what the flight
computer currently calculates
4 - Any slight sink along the way will significantly decrease the glide
performance
5 - Bugs
The same goes for terrain clearance calculation. One should never rely on
published polar to clear terrain to reach landable area.
This has nothing to do with STF. You can use high or low MC in your flight
computer to command STF based on actual conditions, but the arrival labels and
infoboxes should not be impacted and should always show worst case scneario to
be considered "within reach". As such, they should be independent of each
other. Otherwise, whenever you get low, you likely lower your MC, and if the
arrival altitude depends on the MC, it may now show an airport as reachable
although it is only reachable if you manage to achieve very close to published
polar. Not a good idea.
So how do pilots address this? I can think of few options:
1 - increase safety altitude - Not a good idea, as to make up for the
difference between published polar and achieved glide under typical conditions
of sink and headwind you will need to add couple of thousand feet to the safety
altitude, which will almost eliminate XC below 4000 feet AGL.
2 - Tinker with the polar parameters as some suggested - this will do, but is
not a user friendly solution, and may require trial and errors to come up with
a reasonable polar. Users should not need to do that.
3 - Use bug factor - a good solution but currenly not persistent and can be
easily forgotten. This can also be problematic if it will update the bug factor
in the 302. Besides, if it is called "Bug factor" it should be indeed used for
bugs, not permanent degradation.
4 - Safety MC - From reading the manual, this sounds like XCSoar's solution,
but apparently it is not, since it is ignored in the infobox.
So my point is not how I or someone else can degrade their polar from one
reason or another, but how XCSoar addresses the need to use safe glide
calculation to determine arrival altitudes. I have 2 suggestions:
1 - Use Safety MC consistantly in all arrival labels and infobox (configurable
of course)
2 - Add an option to degrade the polar permanently by x% , and keep the
bug factor non persistent as now. Bug factor will than be calculated on top of
the permanent polar degradation. Besides, bug factor is completely arbitrary in
my opinion. How can someone determine by looking at their leading edge from the
cockpit how much it degrades their polar?
Ramy
>________________________________
>From: Wladimir Kummer <wladimirkum...@gmail.com>
>To: "xcsoar-user@lists.sourceforge.net" <xcsoar-user@lists.sourceforge.net>
>Sent: Saturday, November 5, 2011 5:22 PM
>Subject: Re: [Xcsoar-user] Arrival Altitude and MC setting
>
>
>Good call. Try adjusting the mid range polar sinking speed in 5% increments
>till it fits to your specific glider. But I suspect your reserve is
>dissipating because of sinking air and not exclusively because a bad glider
>performance. In order to verify the number one have to fly in still air with
>very sensitive instruments. Even the famous Dick Johson´s flight evaluation
>have too many scatter despite Dick´s immense efforts, I think their number
>should come with a confidence interval. The readers would surprise by how much
>the data could vary just by the chance. Maybe some day I ´ll try to do that.
>
>
>
>2011/11/5 Scott Penrose <sco...@dd.com.au>
>
>To permanently degrade polar just enter lower numbers. Doing it via bugs is
>too arbitrary. An interface to reduce by percent against a predefined is ok
>but should not be necessary.
>>
>>Sent from my iPhone
>>
>>On 06/11/2011, at 7:04, Peter Cutting <peter.cutt...@gmail.com> wrote:
>>
>>
>>I would also like to see bugs persistant (like SeeYouMobile). I also use bugs
>>to degrade the polar since the polar always seems to be optimistic.
>>>
>>>Better yet, I would like to see a polar degradation control (in%) which is
>>>persistant and conneced to a particular polar. One would trim this in over a
>>>few flights. I hate seeing my reserve disipating
>>>
>>>Peter
>>>
>>>
>>>On Sat, Nov 5, 2011 at 7:56 PM, Olaf Hartmann
>>><olaf.hartm...@s1998.tu-chemnitz.de> wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>>Ramy Yanetz <ryan...@yahoo.com> schrieb:
>>>>
>>>>>1 - I believe many (most?) of us use XCsoar
>>>>>mostly for 'casual' XC or OLC, and less for contest/record/badges,
>>>>>which means in most flights no task is set. It is not clear to me what
>>>>>is the recomended strategy to configure
>>>>>XCSoar to this most common type of flying. The most important
>>>>>information for the casual XC pilot is distance, direction and arrival
>>>>>altitude at various landout places along the course, using conservative
>>>>>
>>>>>glide angle (typically half to 2/3 of published polar).
>>>>
>>>>One alternative might be to show required l/d values for each outlanding
>>>>field instead of arrival height. There is a ticket for that. I think i like
>>>>the idea and will give it a try.
>>>>
>>>>
>>>>------------------------------------------------------------------------------
>>>>RSA(R) Conference 2012
>>>>Save $700 by Nov 18
>>>>Register now
>>>>http://p.sf.net/sfu/rsa-sfdev2dev1
>>>>_______________________________________________
>>>>Xcsoar-user mailing list
>>>>Xcsoar-user@lists.sourceforge.net
>>>>https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>>>>
>>>
>>>
>>>--
>>>Peter Cutting
>>>+46 703 580073
>>>
>>>
>>------------------------------------------------------------------------------
>>>RSA(R) Conference 2012
>>>Save $700 by Nov 18
>>>Register now
>>>http://p.sf.net/sfu/rsa-sfdev2dev1
>>_______________________________________________
>>>Xcsoar-user mailing list
>>>Xcsoar-user@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>>>
>>------------------------------------------------------------------------------
>>RSA(R) Conference 2012
>>Save $700 by Nov 18
>>Register now
>>http://p.sf.net/sfu/rsa-sfdev2dev1
>>_______________________________________________
>>Xcsoar-user mailing list
>>Xcsoar-user@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>>
>>
>
>
>
>--
>Wladimir Kummer de Paula MD
>Sarah Network of Rehabilitation Hospitals
>
>
>------------------------------------------------------------------------------
>RSA(R) Conference 2012
>Save $700 by Nov 18
>Register now
>http://p.sf.net/sfu/rsa-sfdev2dev1
>_______________________________________________
>Xcsoar-user mailing list
>Xcsoar-user@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>
>
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
