The problem with AutoPolar is that you don't have enough measurements about the environment. Once those varios like John is building or the Butterfly vario become available this will work better since they have live 3D wind calculation 20 times a second and as such the effect of the environment on the plane can be filtered out in a more useful way. But most of us don't have such systems (yet) and so this will produce results which are likely to be incorrect.
What I just remembered is a feature called "Pirker Vario" which we have implemented to some degree under a different name that I can't remember right now. It is basically the derivative of your task arrival altitude or a task vario. It will show you the improvement of your situation as a value expressed in m/s or whatever you have set as lift unit... This tool might also be useful to determine if the current thermal is actually improving your situation or not. I think there was a (german) PDF floating around the internet explaining the theory behind this. Turbo 2011/11/23 martin.kopp...@gmx.de <martin.kopp...@gmx.de>: > 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 > ------------------------------------------------------------------------------ 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
