... completely agree with what you have said. I -and everyone else I know- use the MC setting as explained below. I find it a helpful tool, and I don't care if it is theoretically incorrect.
- I'm interested in thermal gain required to reach the finish when I am on task. - On final glide I want to know arrival height at my current MC setting *if I don't stop to thermal*. - For outlanding fields I want to know arrival height at safety MC setting *if I don't stop to thermal*. Mike > STF=Speed to fly > THGR= Thermal gain required (current behaviour of xcs final glide) > ARH= Arrival height (old behaviour of xcs and all other computers I know) > > I agree with Peter. There are more than one possible reasons for a final > glide (even starting blow GP) with > MC set to a nonzero value: > > 1) If the airmass is still active MC 0 is a bad choice because with 0.5 > youll be faster without losing to much. Check Reichmann for that. If you > have a ARH display (instead of THGR) you can immediatly see how much > altitude it costs you to fly a little faster. No theramalling involved here! > 2) In a headwind condition to get correct STF from your vario you need > to set MC slightly above 0 > 3) You just "want" to fly faster for other reasons (e.g. convergence or > ridge ahead in the final glide) and you want to see the effect on your > ARH and get to correct STF audio for it. > 4) You want an additonal safety margin to your final glide for whatever > reason (eg. expected sink ahead) > > As long as you still have an "old" standalone Gliding computer you can > work around the problem by setting different MC values on xcs and the > computer (generating STF audio). > *Big drawback in the current xcs THGR behaviour is that you cannot > compare and crosscheck the ARH values on the two comupters (at lets say > MC 0.5 30m below GS) anymore.* > > The problems really grow when you connect the two MC values (like in > Ramy's setup) or with the upcoming sensorbox with xcs eventually > becoming the only glide computer. > *Then we definetly need a way of telling xcs how fast we intend to fly. > Indepentdently of the "pure MC Theory" !!! And getting audio STF > according to momentary sink and ARH (even negative) at that speed in return. > * > This can either be done by using MC values, which is theoretically > incorrect but widely used (crosscheckable with older instruments) and > easy to understand. But seemingly still needs to be accepted by > MC-Purists ;-) > > Or any other "correct" but intuitive easy to understand method, which I > cannot think of at the moment. > Maybe introduce a second "MC"-value that is called differently? > > > Somebody else used the phrase: "xcs is trying to put too much in the box" > I agree concerning the Arrival Height discussion. If the pure arrival > alt (even negative) is taken away from me and my decisionmaking in > favour of the THGR in a guessed thermal in the future, this is not > acceptible to me and I will sadly switch back to the last version with > the old solver. > > I am afraid you will scare potential users (who are used to the ARH > concept and are appreciating it) away by using the THGR instead of "raw" > ARH as default behaviour of xcs. Make it an advanced feature for the > ones who like to use it. > > > Greets Henrik ------------------------------------------------------------------------------ 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
