Am 23.11.2011 09:34, schrieb Peter Cutting:
Hi
#1
Max sais - If you set a positive MacCready value, you tell XCSoar that
you want
to gain height by circling thermals. If you don't plan to do that,
don't set a positive MacCready value, because the whole point/basis of
the MacCready theory is the assumption of future lift.
This does not make sense to me. I often start a final glide "below
glide" and "bump" up on the way *without thermalling*. And I do this
with a MC well over 0. This is the normal way of doing FGs (in a
competition) AFAIK. But this seems to be at odds with what Max is
saying. I dont get it.
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
#3
My vote is for changing XCSOAR to behave more like other flight
computers when it comes to this issue. I want to know if I am above or
below glide. I want a stable value so that I can tell if things are
getting better or worse. I quite liked the glidebar diagrams that
someone posted earlier
Peter
------------------------------------------------------------------------------
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
