: [Xcsoar-user] XCSoar 6.2.3 released
Hi Mike,
as Max already mentioned there was a slight mistake with the release
of the Android version. I just mirrored the new APK of the version
6.2.3c to our download server. Sorry for the inconvenience!
Turbo
2011/11/27 Max Kellermann :
> On 2011/11/27 23
Thanks Max!
Mike
From: Max Kellermann
To: Mike Hostage
Cc: xcsoar-user@lists.sourceforge.net
Sent: Sunday, November 27, 2011 5:39 PM
Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
On 2011/11/27 23:18, Mike Hostage wrote:
> Tobias, this mornin
Hi Mike,
as Max already mentioned there was a slight mistake with the release
of the Android version. I just mirrored the new APK of the version
6.2.3c to our download server. Sorry for the inconvenience!
Turbo
2011/11/27 Max Kellermann :
> On 2011/11/27 23:18, Mike Hostage wrote:
>> Tobias,
On 2011/11/27 23:18, Mike Hostage wrote:
> Tobias, this morning I tried to load the Android 6.2.3 version, but the file
> delivered said it was 6.2.2 when it started up. Can you verify the link is
> working?
This has been a mistake in the build; version 6.2.3c is on the Market
and available for
Tobias, this morning I tried to load the Android 6.2.3 version, but the file
delivered said it was 6.2.2 when it started up. Can you verify the link is
working?
Thanks!
Mike
--
View this message in context:
http://xcsoar.1045713.n5.nabble.com/XCSoar-6-2-3-released-tp5009756p5027316.html
Sent f
Last August, trying to make it back to Moriarty late in the afternoon, during a
declared triangle and with a stiff headwind, I came across the same XCSoar
situation that Ramy brought up. It was not what I expected, and I did not want
to see that I was 6000' below glide slope to make it back home
Please allow me one last mail concerning the Final Glide issue.
I won't go into the details why the "classic" behaviour is of big
advantage to me and the many others who advocated for it on this list.
That has been done extensively now.
If you are one of the developers, first of all I would l
I agree. My inbox has been beseiged by the discussion on this. Give it a
rest everyone!
- Original Message -
From: "Schoen, Andre (Siemens TS)"
To: "Max Kellermann" ; "Ramy Yanetz"
Cc:
Sent: Wednesday, November 23, 2011 5:03 PM
Subject: Re: [Xcsoar-user]
"Bellow glide based on your current MacCready" - Yes
I am not going to reduce my MC, as I can see good weather between me and
the finish. I will make up the missing altitude by flying through the lift
(hopefully without circling).
This is the normal way of doing things, and therefore what XCSoar
We might use the following feature:
Is final glide? If yes then get the required L/D to final destination (take
into account the wind, moon phase and whatever). Then read from the glider's
polar (bugged or clean, pilot's decision) the "indicated" speed to fly to the
final destination --> presen
On 23/11/2011, at 7:34 PM, Peter Cutting wrote:
> . I often start a final glide "below glide" and "bump" up on the way *without
> thermalling*.
This statement is really the key. You state you start below glide. Bellow what
glide? Bellow glide based on your current MacCready?
XCSoar already s
Max, I already opened a ticket 2 days ago and myself and others demonstrated
here many times how to reproduce it. In fact you just downgraded the ticket to
a wishlist, basicly ignoring our annoying requests. Although i highly
appreciate the work you done with XCSoar and swiched to it recently t
@lists.sourceforge.net
Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
On 2011/11/23 17:23, Ramy Yanetz wrote:
> unless you consider 5000 feet fluctuation on arrival altitude in
> couple of minutes a stable value.
After 2 days of discussion, I still don't see your ticket describing
this v
Ramy, the problem is simply that this can be a change that goes deep
in our engine and might result in unwanted side-effects. Due to this
we won't be implementing this on the stable branch (6.2.x). Since I
would like to have the standard behavior too, I guess it might be
included in version 6.3 of
On 2011/11/23 17:23, Ramy Yanetz wrote:
> unless you consider 5000 feet fluctuation on arrival altitude in
> couple of minutes a stable value.
After 2 days of discussion, I still don't see your ticket describing
this very problem, demonstrating how to reproduce it.
> Can we all conclude this dis
Max, I am not sure why you say that XCSoar behaves like other flight computers
and providing stable value. It doesn't. It assumes that I will stop to thermal
since I use mc >0 below glide, which other computers don't. And as a result it
produce very unstable value, unless you consider 5000 feet
On 2011/11/23 14:43, Sascha Haffner wrote:
> "The MacCready setting is not supposed to be a knob to degrade the
> polar to make it realistic (use the "bugs" setting), and neither is it
> a tool to account for head wind (use the "wind" setting)."
>
> Correct, but consequently shouldn't you abandon
safety MC value" also?
and introduce a different concept to degrade performance. MC is currently
easier to use, than bugs.
Sascha
Von: Max Kellermann
An: Michael Schlotter
Cc: xcsoar-user@lists.sourceforge.net
Gesendet: 12:21 Mittwoch, 23.November
On Wednesday, November 23, 2011, Tobias Bieniek wrote:
> The problem is simply that in some cases MC theory doesn't need to be
> applied anymore even though you are still below glide path... e.g.
> when expecting ridges or other lift sources other than circling along
> the way.
Yes exactly. MC the
The problem is simply that in some cases MC theory doesn't need to be
applied anymore even though you are still below glide path... e.g.
when expecting ridges or other lift sources other than circling along
the way.
2011/11/23 Andreas Pfaller :
> On Wednesday, November 23, 2011, Michael Schlotter
On Wednesday, November 23, 2011, Michael Schlotter wrote:
> ... 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 requ
On Wednesday, November 23, 2011, Michael Schlotter wrote:
> Didn't XCSoar 5.x had two flight modes:
>en route: take drift during circling into account for required height
> display on glidebar
>final glide: show arrival height on glidebar for current MC setting
> assuming no circling
>
>
... 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
On 2011/11/23 12:15, Michael Schlotter wrote:
> IMO changing to 0 MC is not really a good option, as it gives overly
> optimistic numbers. It is very hard to fly exactly at the best
> glide speed, never mind getting the polar right for the glider.
You're using the wrong tool for the job.
The Ma
Didn't XCSoar 5.x had two flight modes:
en route: take drift during circling into account for required height
display on glidebar
final glide: show arrival height on glidebar for current MC setting
assuming no circling
If there was such a functionality implemented in 6.x (maybe it is
alre
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 t
On 2011/11/23 09:34, Peter Cutting wrote:
> 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.
XCSoar does that al
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 mak
Firstly let me express my thanks to all of those who have contributed to
this project. The end product is much better than any single developer
or manufacturer could be expected to achieve with resources justified by
a "commercial" soaring product.
On 22/11/2011 23:06, Alexander Swagemakers wr
I like Morgan suggestion along the line of documenting requirements for "Club
mode". The manual is indeed missing configuration recommendations for various
flight modes, leaving it to trial and error. I think the majority of flights,
at least in the US, are not contest, badge or record flights.
The problem is that you usually only have ONE MC value set, and
getting all those values requires you to cycle through the possible
values like Alex did. This is not practical. Much better would be
something like Morgan suggested
that shows you that in this case you would need thermals of at least
On Tuesday, November 22, 2011, Alexander Swagemakers wrote:
> I just set up a scenario in condor with my streak running xcsoar connected
> to experiment with the glide bar behavior. The setup is as follows:
>
> LS8, final Glide St. Croix to Puimoisson due north 10.2km distance with
> 50km/h headwi
On Tuesday, November 22, 2011, David Reitter wrote:
> On Nov 22, 2011, at 4:06 PM, Andreas Pfaller wrote:
> > On Tuesday, November 22, 2011, David Reitter wrote:
> >> It seems that users find the need to play "what if", and they
> >> manipulate MC to do so (and for other wrong reasons, as you poin
Seems to me that one of the things XCSoar should do is intuitively educate
the pilot on what thermal strength they need in order to make progress.
If I've set MC 1, because I'm flying a little faster than MC 0, but XCSoar
"knows" that I need 2 Knots of lift to warrant circling, a Min Thermal
Stren
I just set up a scenario in condor with my streak running xcsoar connected
to experiment with the glide bar behavior. The setup is as follows:
LS8, final Glide St. Croix to Puimoisson due north 10.2km distance with
50km/h headwind, 1352m MSL.
Switching MC values in XCSoar gives following results
> It is not XCSoar's priority to please the user with intuitive and
> expected calculation results; the first priority is to display correct
> results.
This is not quite correct. Actually at least my priority is to combine
both: intuitive and correct results. And both numbers that we are
calculati
On Nov 22, 2011, at 4:06 PM, Andreas Pfaller wrote:
> On Tuesday, November 22, 2011, David Reitter wrote:
>
>> It seems that users find the need to play "what if", and they manipulate
>> MC to do so (and for other wrong reasons, as you point out). So
>> there's a need to let them do that, is th
On 2011/11/22 22:06, Alexander Swagemakers wrote:
> I?m sure these calculations are technically correct but from a practical
> point of view this is madness!
It is not XCSoar's priority to please the user with intuitive and
expected calculation results; the first priority is to display correct
re
On Tuesday, November 22, 2011, David Reitter wrote:
> It seems that users find the need to play "what if", and they manipulate
> MC to do so (and for other wrong reasons, as you point out). So
> there's a need to let them do that, is there not?
The can play with the MC setting however they like
eitter
>Cc: xcsoar-user@lists.sourceforge.net
>Sent: Tuesday, November 22, 2011 12:33 PM
>Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
>
>On 2011/11/22 21:21, David Reitter wrote:
>> It seems that users find the need to play "what if", and they manipulate MC
>> to do so
On 2011/11/22 21:30, Martin Gregorie wrote:
> - is the input to this just the climb rate as measured during circling
> flight?
>
> - does straight line climbing, e.g. running a convergence line,
> affect the auto setting?
Only lift while circling is considered for AutoMC. AutoMC is not
cap
On 2011/11/22 21:21, David Reitter wrote:
> It seems that users find the need to play "what if", and they manipulate MC
> to do so (and for other wrong reasons, as you point out). So there's a need
> to let them do that, is there not?
Sure, you can edit the MacCready setting at any time, for
Max,
What you say is clear, but would seem to be applicable to manually set
MC settings. Thanks for the explanation.
However, nobody has yet described what happens if MC is left on Auto.
Presumably during thermal flight some sort of averaging algorithm is
applied depending on each actual thermal
On Nov 22, 2011, at 3:08 PM, Max Kellermann wrote:
>
> If you don't want XCSoar to assume you'll ever be thermalling, don't
> set a positive MacCready value. (Have I repeated this statement often
> enough in this email?)
Loud and clear, thank you!
I restate: MacCready theory assumes that heigh
This is the "I repeat myself over and over" thread!
On 2011/11/22 20:51, David Reitter wrote:
> In my view, the problem at hand is that XCSoar seems to assume that
> height is always gained by way of thermaling. That is obviously not
> correct.
No, you are wrong. XCSoar only assumes that heigh
I would want the software to do precisely the calculations that I'm not good at
doing. That's what computers are for.
However, the underlying models must be robust and suitable for a range of
situations. Assumptions must be clear. Chaining too many assumptions that
depend on the same few unde
I've found that some people like L/D Req (Geometric by this thread) to the
safety height. Others like myself are content with Arrival height being
displayed. Either way, I don't expect the flight computer to think for me,
only to be consistent in its estimates. If it shows 20:1 to home and I'm
b
I guess at safety MC speed for still air mass. This would however add a
dependency on the polar setup, which a geometric or ground L/D would not
require.
John Wharington schrieb:
Geometric + wind at what aircraft speed? The impact of wind will
depend on your airspeed.
These L/D required disp
I would assume that those calculations are/should be based on the MC
speed-to-fly. Just like the arrival altitude numbers are also based on
the assumption that the pilot flys at that speed.
Turbo
2011/11/22 John Wharington :
> Geometric + wind at what aircraft speed? The impact of wind will
> d
Geometric + wind at what aircraft speed? The impact of wind will
depend on your airspeed.
These L/D required displays therefore all make additional assumptions.
On Wed, Nov 23, 2011 at 12:54 AM, Sascha Haffner wrote:
> Hi
>
> I like Olaf's summary !!!
>
> As for the questions how other manufactu
Hi
I like Olaf's summary !!!
As for the questions how other manufactures have implemented L/D req. I would
venture a guess that LX uses geometric plus wind.
Sascha
On Tue, Nov 22, 2011 8:36 AM EST Olaf Hartmann wrote:
>Please read the feature request. Some people want geometric L/D for good
On Tue, 2011-11-22 at 14:07 +0100, Tobias Bieniek wrote:
> That is a valid question and by reading both feature requests it seems
> that people are actually requesting both independently. My personal
> opinion would favor the L/D relative to the airmass. If I understand
> correctly that version wou
Please read the feature request. Some people want geometric L/D for good reason
(e.g. very altitude dependent wind) I for myself would prefer L/D relative to
airmass. Wich one is our "curent L/D" btw?
So i would propose making this an option. E.g. a combo box with a few useful
choices, like:
- A
L/D relative to airmass is more useful, I really can't see how knowing
geometric gradient helps.
On Wed, Nov 23, 2011 at 12:07 AM, Tobias Bieniek wrote:
> That is a valid question and by reading both feature requests it seems
> that people are actually requesting both independently. My personal
>
m, 200m or even 500m arrival altitude is
>>> safe).
>>> - Considering, also flight around terrain, airspace, but configurable on/off
>>>
>>> Any thoughts?
>>>
>>> Sascha
>>> Von: Tobias Bieniek
>>> An:
>>> Cc: "
is
>> safe).
>> - Considering, also flight around terrain, airspace, but configurable on/off
>>
>> Any thoughts?
>>
>> Sascha
>> Von: Tobias Bieniek
>> An:
>> Cc: "xcsoar-user@lists.sourceforge.net"
>> Gesendet: 12:06 Dienstag, 22.N
ltitude is
> safe).
> - Considering, also flight around terrain, airspace, but configurable on/off
>
> Any thoughts?
>
> Sascha
> Von: Tobias Bieniek
> An:
> Cc: "xcsoar-user@lists.sourceforge.net"
> Gesendet: 12:06 Dienstag, 22.November 2011
> Betre
thoughts?
Sascha
Von: Tobias Bieniek
An:
Cc: "xcsoar-user@lists.sourceforge.net"
Gesendet: 12:06 Dienstag, 22.November 2011
Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released
Hi everyone,
I think I found one possible cause of the confusion.
ny thanks to the developers for their
> hard work and for following and allowing this discussion.
>
> Cheers,
> Sascha
>
>
> Von: David Lawley
> An: tangoei...@gmail.com; m...@duempel.org
> Cc: xcsoar-user@lists.sourceforge.net
> Gesendet: 2:10 Dienstag, 22.November 2011
> Betreff:
Von: David Lawley
An: tangoei...@gmail.com; m...@duempel.org
Cc: xcsoar-user@lists.sourceforge.net
Gesendet: 2:10 Dienstag, 22.November 2011
Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released
My only comment is i was perfectly happy with the behaviour of final glid
xcsoar-user@lists.sourceforge.net
> Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
>
>
> On Nov 21, 2011, at 5:48 PM, Max Kellermann wrote:
>
> > On 2011/11/21 23:40, Evan Ludeman wrote:
> >> Sorry John, no sale. We need height relative to glide slope at a pilot
> >>
On Nov 21, 2011, at 5:48 PM, Max Kellermann wrote:
> On 2011/11/21 23:40, Evan Ludeman wrote:
>> Sorry John, no sale. We need height relative to glide slope at a pilot
>> selectable Mc setting for final glide. If that's being eliminated in
>> preference wind dependent height of climb required,
On Mon, Nov 21, 2011 at 5:48 PM, Max Kellermann wrote:
> On 2011/11/21 23:40, Evan Ludeman wrote:
> > Sorry John, no sale. We need height relative to glide slope at a pilot
> > selectable Mc setting for final glide. If that's being eliminated in
> > preference wind dependent height of climb re
I guess all these years I had the wrong illusion believing that the height
relative to glide slope is the most important information for me ;)
It is the same as how much I need to GAIN (not necessarily circling) to make
it. Where I fly, you don't always need to stop to climb to reach your goal. A
I would also prefer the "old" behaviour of the final glide bar and
support Evans point of view.
I use MC-Values for two different purposes:
1) Estimating task arrival time (can I still make the task or should I
abort)
I use the estimated average strength of the thermals I expect to
encount
I second that. In my opinion the way it is now calculated is down right
misleading and most pilots don't realize that it is doing something else than
any other flight computer. Most of us fly with somewhat degraded polar, so it
is very important to know how much below glide you are, to have a go
XCSoar allows you to fly according to your stated preferences.
On task, set a low Mc if that's how you want to go. Once you reach final glide
(FG bar goes green, in positive), there are two ways to proceed:
- with auto mc on, keep climbing until MC has increased to the value
you would like to
co
On 2011/11/21 23:40, Evan Ludeman wrote:
> Sorry John, no sale. We need height relative to glide slope at a pilot
> selectable Mc setting for final glide. If that's being eliminated in
> preference wind dependent height of climb required, that's a poor
> choice.
What XCSoar shows is not the hei
Sorry John, no sale. We need height relative to glide slope at a pilot
selectable Mc setting for final glide. If that's being eliminated in
preference wind dependent height of climb required, that's a poor choice.
The fact that you can't see the logic in my proposal is of no account.
This is, in
Hi Tobias,
Yes, strictly speaking you are right about height required approaching
infinity as Mc approaches zero.
I think Simon's suggestion is worth considering though; it does add a
little complexity to the display but to me it appears like it could be
intuitive enough (further, it's relatively
Thermal strength and wind are inherently uncertain, but are not entirely random.
Having an estimate is better than assuming zero for each.
For reasons described in my previous email, simply adding more
configuration options does not help. I fail to see the logic behind
having separate MC values f
On Mon, Nov 21, 2011 at 4:58 PM, Simon Taylor wrote:
> On 21 November 2011 20:25, Martin Gregorie 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 gue
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 ar
On 21 November 2011 20:25, Martin Gregorie 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 sh
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
I'm sorry, I sure see good points for both, so: Are you all discussing the same
thing?
Arrival altitude may be calculated on the same theory as speed to fly, but it
has a completely different meaning to the pilot in flight.
Arrival altitude is something used to determine airfields within rang
in the AltDiffRequired.
>
> Cheers,
> Sascha
>
>
> Von: Tobias Bieniek
> An: John Wharington
> Cc: "xcsoar-user@lists.sourceforge.net"
> Gesendet: 17:20 Montag, 21.November 2011
> Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released
>
> You are rig
rs,
Sascha
Von: Tobias Bieniek
An: John Wharington
Cc: "xcsoar-user@lists.sourceforge.net"
Gesendet: 17:20 Montag, 21.November 2011
Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released
You are right with your second point about the two airfields, but I
thi
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
We will have to agree to disagree on that.
Arrival altitude should indeed consider circling, and you should set a
reasonable MC value, if you are able to climb. If you don't expect to
be able to climb, then set MC=0.
If conditions are such that climbing in weak lift makes an upwind
landing point
On Tue, Nov 22, 2011 at 3:02 AM, Ramy Yanetz wrote:
> Sorry, but if this is not a bug this is absurd. Why i can not climb at MC
> zero??
Of course you can climb, but you are telling the computer you are not
expecting to be able to climb.
> Besides, if i increase my MC to 3 or 4 it shows that i
Arrival altitude should NEVER consider circling! I never heard of such theory.
Arrival altitude should only consider polar, degradation, wind and MC, although
it would be fine without considering MC at all. But trying to guess your climb
and your drift while climbing is completely wrong. We are
Sorry, but if this is not a bug this is absurd. Why i can not climb at MC
zero?? Not everybody fly according to MC theory. Especially not in the western
US where you don't want to get below the mountains if you can. As such my 302
MC setting is usually low zero or 1, occasionaly 2 . But xcsoar
It is consistent at present.
If you are below final glide, then the negative number shows you how
much height you need to gain before you can pure glide. In the case
of Mc=0 in a headwind, that number is smaller than Mc>0, because the
height you have to magically gain at Mc=0 is done instantly, f
John, I think this is inconsistent behaviour... either if you can't
climb you shouldn't see the pure glide value, or if you have a MC
above 0 you shouldn't consider the wind effect while circling. Maybe
for internal calculations we should supply both values and let the
user decide what he wants to
This is not a bug.
At MC=0, you cannot climb, so the value reported (-500 feet) indicates
you magically need to gain 500 feet in order to glide at MC=0.
At MC=0.5, you are telling the computer you can climb, and with that
headwind and a slow climb rate (0.5), you need to climb a lot more.
In this
Thanks Andreas. However this is not the case. Arrival altitude does not and
should never consider any climb. When you can not reach the target it should
always show you how much below glide you are. In my case i was only 500 below
glide, no big deal, as i had good chance to find something aong t
Thanks Max, I will open a ticket but since this is a serious bug (which almost
caused me to land out) I am reporting it here as well..
Thanks,
Ramy
On Nov 21, 2011, at 2:46 PM, Max Kellermann wrote:
> On 2011/11/21 13:32, Ramy Yanetz wrote:
>> I haven't tried 6.2.3 yet but I flew with 6.2.2
On Monday, November 21, 2011, Ramy Yanetz wrote:
> I haven't tried 6.2.3 yet but I flew with 6.2.2 last saturday (running on
> my Streak connected to 302) and something is very wrong with all arrival
> altitude calculations in waypoint info and info boxes when combining bug
> factor, Headwind and M
On 2011/11/21 13:32, Ramy Yanetz wrote:
> I haven't tried 6.2.3 yet but I flew with 6.2.2 last saturday (running on my
> Streak connected to 302) and something is very wrong with all arrival
> altitude calculations in waypoint info and info boxes when combining bug
> factor, Headwind and MC >0.
Hi Tobias,
I haven't tried 6.2.3 yet but I flew with 6.2.2 last saturday (running on my
Streak connected to 302) and something is very wrong with all arrival altitude
calculations in waypoint info and info boxes when combining bug factor,
Headwind and MC >0. Once arrival altitude turned negativ
91 matches
Mail list logo
