I think Martin Kopplow did a good job summarizing the whole issue. It is actually what I meant earlier by supplying the engine with both numbers for internal calculation. It should be intuitive to use without having to think what those numbers actually mean. I guess we should check which results are displayed at what position in the current state.
As for the original MC=0 issue: I think it should display infinity in this case. Our logic right now is that the pilot is only circling if below glide path AND mc is set to any value above zero. This leads to the "magic" switch at MC=0. It might be easier to understand if we assumed that the pilot would always be circling when below glide path even with no lift. This would probably lead to a division by zero resulting in an infinite amount of height needed due to the wind drift. As and easter egg we could obviously calculate the trip around the earth though... ;) @Simon: Nice idea in general, but I think adding even more complexity to the final glide bar isn't a good thing. Most people are probably already confused by the two bars instead of just one... Turbo 2011/11/21 Simon Taylor <simon.taylor...@gmail.com>: > On 21 November 2011 20:25, Martin Gregorie <mar...@gregorie.org> wrote: >> >> On Mon, 2011-11-21 at 17:20 +0100, Tobias Bieniek wrote: >> > You are right with your second point about the two airfields, but I >> > think we should let the pilot figure this out. I guess I would have to >> > agree that the time spent circling shouldn't be a factor. AFAIK no >> > other software does it that way... As I mentioned earlier, we could >> > make it configurable but I don't think that's really useful. >> > >> I have to agree with Tobias. >> >> If you've abandoned the task because of deteriorating weather and are >> now in survival mode for getting home, its normal where I fly to turn MC >> down to zero and head for home. If I do this I expect the FG computation >> to act exactly as it would at a higher MC setting - only difference >> being that your speed through still air would be the glider's best glide >> speed rather than the higher speed implied by cranking MC up. >> >> In this situation I'd expect to see the predicted arrival height getting >> lower if I have a headwind and am silly enough to be circling in lift so >> weak that the effect of being blown away from home is more significant >> that the achieved climb rate. >> >> >> Martin > > From discussing the final glide bar issue with other developers on IRC, I'm > putting forward this suggestion: separate out the current functionality of > the final glide bar to incorporate an optional indicator devoted entirely to > height required due to drift while circling. The indicator is blue to match > existing functionality relating to circling drift (specifically the blue > arrow on the moving map which indicates the optimal track to follow to the > active waypoint, compensating for circling drift) > > http://i40.tinypic.com/28iom1c.png > > With this configuration the numeric display always indicates the arrival > height at the current MacCready setting assuming no additional climbs. > However, the indicator for height required due to drift while circling > scales appropriately to its significance (it will be barely noticable with a > weak headwind, but large when there is a strong headwind), which should > contribute to the user's awareness of the headwind and the effects it should > have on decision making. > > There is some concern that the addition of the extra indicator makes the > final glide bar overcomplex, and if this is the general consensus it may be > necessary for it to be disabled by default; instead only the solid bar - > indicating arrival height at current MC setting - and inset hollow bar - > indicating arrival height at MC=0 - might be displayed. > > Any feedback on this suggestion would be welcome. > > Cheers, > > Simon > > ------------------------------------------------------------------------------ > 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
