Please take me one time off the list because i get all the mails twice
Mit freundlichen Grüßen
Peter M. Groß
Manager of Company Networks
-------- Original message --------
Subject: Xcsoar-user Digest, Vol 66, Issue 43
From: [email protected]
To: [email protected]
CC:
Send Xcsoar-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xcsoar-user digest..."
Today's Topics:
1. Re: XCSoar 6.2.3 released (George)
2. Flarm to IPAQ? (Adam Webb)
3. Re: Flarm to IPAQ? (Tobias Bieniek)
4. Re: Final Glide vs. En Route (was:XCSoar 6.2.3 released)
([email protected])
5. Re: XCSoar 6.2.3 released (Henrik Bieler)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Nov 2011 11:39:55 -0000
From: "George" <[email protected]>
Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
To: "Schoen, Andre \(Siemens TS\)" <[email protected]>, "Max
Kellermann" <[email protected]>, "Ramy Yanetz" <[email protected]>
Cc: [email protected]
Message-ID: <B8274C3DE83C41C690708ED9B97F3D41@desktop>
Content-Type: text/plain; format=flowed; charset="Windows-1252";
reply-type=original
I agree. My inbox has been beseiged by the discussion on this. Give it a
rest everyone!
----- Original Message -----
From: "Schoen, Andre (Siemens TS)" <[email protected]>
To: "Max Kellermann" <[email protected]>; "Ramy Yanetz" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 23, 2011 5:03 PM
Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
> Well summarized Max,
>
> I think this discussion is blowing out of proportion and is more of a
> debate of preferences to deal with an imperfect world (.... which may or
> may not be fixable by modifying MC settings to offset other parameters
> ....)
>
> ... and the discussions also deflects from the great work done by the
> software team.
>
> To conclude it, it would probably need a sharply formulated and well
> thought through approach, written down in a ticket.
>
> -----Original Message-----
> From: Max Kellermann [mailto:[email protected]]
> Sent: 23 November 2011 16:35
> To: Ramy Yanetz
> Cc: [email protected]
> Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
>
> On 2011/11/23 17:23, Ramy Yanetz <[email protected]> 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 discussion that XCSoar needs an urgent fix
>
> No, we can't. Your continued alarmism is annoying and doesn't add to
> your credibility. Your problem isn't the most important one in the
> world, and your feature request (that's what it is) does not need an
> "urgent fix".
>
> Very recently, we had serious calculation problems that needed urgent
> fixes, and after a few night shifts, we did publish new maintenance
> releases after we figured them out. Your request is nowhere near
> that.
>
> Max
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
------------------------------
Message: 2
Date: Thu, 24 Nov 2011 23:47:47 +1100
From: Adam Webb <[email protected]>
Subject: [Xcsoar-user] Flarm to IPAQ?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
Does anyone have any information as to what the wiring should be between
a FLARM and IPAQ running XCSoar?
Is it as simple as FLARM TX -> IPAQ Serial RX and vice versa?
Also, what settings need to be selected under 'Devices'? I can see a
list of loggers,but FLARM isn't one of them.
Regards
Adam?
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Thu, 24 Nov 2011 13:58:53 +0100
From: Tobias Bieniek <[email protected]>
Subject: Re: [Xcsoar-user] Flarm to IPAQ?
To: Adam Webb <[email protected]>
Cc: [email protected]
Message-ID:
<CABEOeTnctbeJ_Ev6ishyY5hgn7JMuyoUvXjdgk=fvzuecdj...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Adam,
it is basically as simple as you described. I think in the Flarm
Installation Manual there are some explanations about this.
There is no dedicated Flarm driver in the current Version (6.2.3),
just use the "Generic" driver. You will probably need to use "Com 1"
and a baudrate of "19200".
Turbo
2011/11/24 Adam Webb <[email protected]>:
> Hi All,
> Does anyone have any information as to what the wiring should be between a
> FLARM and IPAQ running XCSoar?
>
> Is it as simple as FLARM TX -> IPAQ Serial RX and vice versa?
>
> Also, what settings need to be selected under 'Devices'? I can see a list of
> loggers,but FLARM isn't one of them.
>
> Regards
>
> Adam
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>
>
------------------------------
Message: 4
Date: Thu, 24 Nov 2011 16:24:07 +0100
From: "[email protected]" <[email protected]>
Subject: Re: [Xcsoar-user] Final Glide vs. En Route (was:XCSoar 6.2.3
released)
To: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Am 24.11.2011 um 00:00 schrieb Tobias Bieniek <[email protected]>:
> The problem with AutoPolar is that you don't have enough measurements
> about the environment.
That may be an issue if you want a rather immediate analysis. In the long term,
comparing prediction and logged data might be enough to narrow in on a
corrected polar of a known glider/pilot combination.
If the solver output was saved with the logged flight data, even a web based
tool could do the statisics. Think of the Flarm range check tool. Upload your
polar and a collection of recent flight logs and as a result, download a
degradation file. It wouldn't need to be 100% accurate, it would only need to
compensate for say a basic trend or noise level.
> 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.
Well, I'm on the edge of my seat to see one of these in flight. Very intersting
development going on there.
> 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.
I guessed someone might have proposed this before, but couldn't find any info
on the net. If you have implemented something like it, where does it show up? I
usually watch estimated arrival height next WP while circling in weak lift to
see if working the thermal pays off, or if applicable, the glide bar. It does
something similar, though kinda in a low resolution with quite some time lag.
It does not tell me what averager reading would give me a good reason to stay
in that thermal or rather leave it. I could imagine this might be helpful and
speed things up. But then, I am only some guy who flies for fun.
And, please nobody get the idea I want to criticise. I respect the work done
here, and only want to throw in some ideas.
Best,
Martin
------------------------------
Message: 5
Date: Thu, 24 Nov 2011 20:37:13 +0100
From: Henrik Bieler <[email protected]>
Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
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 like to thank you
for your work!
And I would be happy if you would consider the following, when making
the decision to reimplement a switch to get back the classic behaviour
for the ones who want it, or if you are going to ignore the requests.
- There is a large group of users who want the classic way of displaying
Arrival Alt (about 50% of the people who wrote on this topic)
- These users are not dumb. They are experienced XC and competition
pilots. (so are the ones who like the new behaviour as well) After this
discussion they now understand why you implemented the new behaviour and
they understand the pure MC-Theory. However they still advocate strongly
to get back the old way of displaying final glide for a bunch of reasons.
- You may or may not think the reasons for their wish are valid. But
please don't think they just "did not understand" or they are just lazy
to learn something new. That is not the case. Please carefully reread
all the reasons brought forward if you really might think so.
- All other gliding computers (LX, Zander...) and gliding software
(SeeYou Winpilot StrePla) behaves the "classic" way for final glide
display. Which is not just one value of many, it is the heart of any
gliding calculator. Pilots are used to it and therefore the behaviour
they expect from xcs will be different. Which is a reason for users to
distrust xcs's calculations and use other software.
- There is no way to do a crosscheck between two systems if below GP
with MC>0 anymore.
- I understand that if you designed something like the new solver and
you put loads of work into it, the first reaction when constructive
critisicm arises at this very late point in time is that you will be
hesitant to change things that are obviously right in your perspective.
However I think a big advantage of opensource is that different views on
the same thing can be openly discussed and the users can give input
about the things that are really important to them.
- If you decide NOT to reimplement the classic display as an option what
do you want to achieve?
Reduce complexity *you think* is unnecessary?
Educate other pilots to see things "your way"?
- Just a final thought: Wouldn't it be possible to calculate a "Thermal
Gain Required"-Altitude with the resources of the old hardware gliding
calculators? (Geometric Postion, Polar, Wind, Thermalstrength(MC) )
Why has none of the numerous systemdesigners ever done so for the final
glide display? Don't you agree they are smart guys as well?
Maybe they had reasons... just thinking....
You made a lot of people happy creating and enhancing this software. If
the user could choose in which way final glide is displayed you would
make a lot of those people really happy ! =)
This is an important issue.
The decision lies in your hands !
Please don't decide too quickly.
Greets Henrik
Am 24.11.2011 09:44, schrieb Peter Cutting:
> "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
> should support first and foremost
>
> I dont use AutoMC for some reason. Dont know much about it. Only I
> know what the weather looks like ahead so I like to stay in charge of
> the MC setting.
>
> Peter
>
>
> On Wed, Nov 23, 2011 at 11:46 PM, Scott Penrose <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> 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 supports what you want by just using Auto MacCready
> on Final Glide.
>
> Scott
>
>
>
>
> --
> Peter Cutting
> +46 703 580073
>
>
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
End of Xcsoar-user Digest, Vol 66, Issue 43
*******************************************
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
