This is (was?) a very interesting discussion. I just re-read most of it, and I can't help feeling most of the discussion is most probably on the wrong subject. My conclusion (while everybody's at it making conclusions) is that this is actually a user interface issue, coupled with a heritage of learned workaround procedures that do now collide with recent improvements.
None of the contributors has really doubted the relevance and correctness of McCready theory as such. That is to say the new solver, which respects more factors than the old one, and is working closer to the theory is actually an improvement, as it does give the pilot additional and more accurate information. This information is more complex, though, and requires a more complex interpretation. There are situations, where this is undoubtedly helpful, and there are situations where this level of complexity is overkill, or the additional factors do simply not apply. Also, there is a wide spread uncertainty about when and where the results of old an new solver are displayed and applied. Ambiguous terms used in the context might have forwarded this. Putting the user to the choice of using the one OR the other is no solution. This would mean discarding useful information. I propose to focus on carefully improving the interface in a way that a) the right information is displayed at the right time and place. b) the user can more intuitively understand what is used when. Also, we need to keep in mind there are several decision processes happening at the same time, and they all rely on variables such as the MC value set. The problem here is that while we fly en route, we need the MC set according to the theory in order to obtain optimum STF output. At the same time, it appears many pilots like to be be monitoring options like landable places to reach in case they do not hit the expected lift. It is most probably they will not continue to fly with the en route MC setting once this happens. Still, monitoring the options does today happen with the same setting, as there is only one, and it happens simultaneously. The assumption that the pilots will abort the task in XCsoar before considering any final glide options towards a landable field is not valid, and so, any simultaneous plan B is inaccurate. In terms of UI, this means we need to separate the two scenarios in a way that the user can operate them both and get reliable results for both. They are only contradictory because they use the same input for different scenarios. I do not think just adding a second MC setting will do the job. It will increase the load on the pilot, and it might even open a new door for errors. Auto MC will not do the job either, because a sudden lack of thermal changes everything. So, while the en route calculations should incorporate all factors such as lift expected, wind, polar degradation and such, they should in my opinion also deliver an output that reduces the room for error during interpretation. STF is pretty unambiguous, though when we look at the drift while circling, we do actually not need any output of a distance or arrival height going infinite now and then, depending on settings. What we need is a clear statement of what thermal strength is required to get us on. Maybe there should be a thermal bar, similar to the glide bar, only it tells us how much the current thermal improves our situation. If we climb well in little wind, it will thus display as a long arrow pointing up and all green. If the wind drift is eating up all height gain, it turns short orange and if we even loose room by a weak thermal and much drift, it would point down and turn red. Kind of a 3D-Variometer. This would make the complex scenario quite intuitive. Also, this thermal bar could maybe have a minimum mark, permanently displayed, and this could tell the pilot what thermal strength is required now. (That won't find him any strong thermals, but help with tactics, and maybe prevent him from losing room when trying to grab weak thermals.) Also, this could be connected to an MC warning, in case the MC setting turns out to be much too high for the day. We'd have STF and TTF*, then. On the other side, the final glide calculations should in my opinion always run in parallel (they do anyway, AFAIK). These are the Plan B calculations for the cases that a) we need to reach a landable field (or play what if, even if we don't need to right now) b) we get close enough to the target to attempt a safe final glide c) the pilots forces final glide for tactical reasons. All the above (maybe except C) do assume no more circling. Displaying negative arrival height for a field would still be interesting for what-if, though. So the only part of MC theory we need here is the optimum STF for best glide over terrain, of course respecting safety arrival height. Calculations should, of course, respect wind and polar degradation but not rely on the current en route MC setting which was set in the anticipation of thermals, and is no longer valid now. In this scenario, we need as safe a glide prediction as possible. Fiddling with an estimated MC setting is not a good solution. Instead, the factors like wind and polar degradation should be made reliable and easy to check or even tune. STF should respect head/tailwind. If wind calculations are good enough, there will be no more need to set any fancy MC values. Maybe completely excluding it from this scenario might also solve the 302 compatibility issue. Everything to do with final glide should be displayed in a way that cannot be mixed up with en route calculations. In case of field labels this is easy. The glide amoeba is also quite intuitive. The glide bar is a bit more critical, as it does serve multiple purposes during the flight phases. I have no proposal right now how to make it communicate this information, but it might have to shift it's appearance, depending on what kind of data it represents at the time. And, finally, I'd like to propose a new tool: As it appears to be difficult for pilots to determine the actual polar degradation (and thus lead to MC being used to fine tune), it might be useful to have an analysis tool built into the glide computer that can - from data mostly collected anyway - analyze the degradation that would have been right for any flight recorded (or even do it in flight), by comparing the predicted and true arrival height or L/D and making statistics on it. The correction factors generated this way could be stored together with the glider's individual polar. I don't know if it could work, but looks like an interesting option. If we have AutoMC, why not have AutoPolar? Martin *TTF = Thermal to Find ;O) --- ------------------------------------------------------------------------------ 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
