I would want the software to do precisely the calculations that I'm not good at doing. That's what computers are for. However, the underlying models must be robust and suitable for a range of situations. Assumptions must be clear. Chaining too many assumptions that depend on the same few underlying variables is calling for trouble.
In my view, the problem at hand is that XCSoar seems to assume that height is always gained by way of thermaling. That is obviously not correct. The second problem is that users including myself confuse Height Gain Required with Height Below Glide. As others point out: you need HBG during a final glide, or in order to decide whether to attempt a glide. HGR is useful, too - when it's clear you're going to circle. Perhaps the user ought to choose between them when configuring the infoboxes. Because the Height Gain Required seems to imply that height is gained by thermaling, it should make this clear "Thermal height gain required" (THGR). (A headwind will lead to unfavorable displacement in thermals, but in ridge lift or wave, it may be of no consequence.) MC can be interpreted in the classic way (i.e., strength of next thermal), and THGR is undefined if MC==0 and below glide. It should be shown that way. The data displayed to the pilot must me consistent and clear in their semantics. Would it be OK to show some verbal warnings? "UNREACHABLE AT MC=.5 DUE WIND DRIFT" would make this easier to understand, and make it clear that MC is a factor. So, please do consider headwind when calculating THGR. That said, I would still set my system up to show HBG at least for the final glide screen. In the thermal helper screen, I would want to see THGR not based on MC, but based on the average strength of this particular thermal. Seems logical to me. Suppose the two info boxes exist - what is the default? I would argue for HBG, because it is closer to "raw data" and thus easier to understand. Now for glide range. I absolutely expect reachability calculations (such as arrival height, or the glide amoeba) to be based on pure gliding in the current conditions: performance, wind, at speed-to-fly as displayed. I expect that MC here only influences the speed to fly, and I could temporarily change MC to see if I can perhaps make a final glide at a lower speed. This is how people often use it - that should be clear by now. Perhaps it should simply assume best glide (with wind taken into account), but if it does, it should say so. XCSoar 6.x does not make assumptions about finding a thermal or other lift source if MC>0, for purposes of reachability calculations, right? I would be very confused if it did. Please clarify. Recall that reaching some outlanding field is already "plan B", i.e., it's the plan in place for when the thermals die. The discussion here is educational - particularly, I too thought that the bar on the left showed simple height-above/below-glide, rather than thermal height required. (Most of my flying experience has been in regions where cloudbase is usually below 7,000ft, and little wind, and in ridge lift or wave, with plenty wind of course. Thus, wind drift has been a factor w.r.t. reachability at short distances, but not really for XC.) Thank you for teaching me! On Nov 22, 2011, at 12:12 PM, Morgan Hall wrote: > I've found that some people like L/D Req (Geometric by this thread) to the > safety height. Others like myself are content with Arrival height being > displayed. Either way, I don't expect the flight computer to think for me, > only to be consistent in its estimates. If it shows 20:1 to home and I'm > bucking a strong headwind, I'm just looking for that L/D to change in my > favor. 19:1 would indicate I was gaining on glide, just like an arrive of 0 > increasing to +200 would indicate I'm doing better than the required L/D. > > I understand the theory behind the airmass concept, but that seems so > incredibly complex to not only model in software but to try to explain to new > user. When you look out the canopy, you probably have a decent sense of what > a 20:1 glide or 40:1 glide looks like. Having the flight computer tell me I > was 60:1 away from a target because it was into a 40knot headwind would > generate some serious cognitive dissonance. > > Aside from these threads, what can, we the users, do in order to better > articulate the requirements? Write up scenario's so that you've got a use > case to simulate and test against? > > Morgan
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ 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
