Anybody running a Butterfly Vario with XCSoar?

[jfitch]

Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this?

Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?

[[email protected]]

On Sunday, July 14, 2013 2:08:50 PM UTC-4, jfitch wrote:
> Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this?
>
>
>
> Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?

Well, it only saves a few taps, but the gesture to get into the nav stuff
is right, down. That will take you directly to the task calculation screen..
Getting to the turnpoint stuff takes 1 tap after that. The gesture really
comes in handy when flying a time-distance task (AAT or MAT), though.

Matt

[son_of_flubber]

On Sunday, July 14, 2013 2:08:50 PM UTC-4, jfitch wrote:
> Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations.

Could you please confirm that you are saying that when XCSoar uses wind data from Butterfly Vario that it calculates glide based on the exact opposite of the correct wind vector? If so, that is a rather serious defect and you should report it to XCSoar.org pronto.

[jfitch]

On Sunday, July 14, 2013 7:28:17 PM UTC-7, son_of_flubber wrote:
> On Sunday, July 14, 2013 2:08:50 PM UTC-4, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations.
>
>
>
> Could you please confirm that you are saying that when XCSoar uses wind data from Butterfly Vario that it calculates glide based on the exact opposite of the correct wind vector? If so, that is a rather serious defect and you should report it to XCSoar.org pronto.

Yes - actually it seems to compute correctly, just that the Butterfly and XCSoar don't agree on which way the wind is blowing. I think. Can you confirm that the arrow in XCSoar points the direction the wind is blowing (as distinct from pointing into the wind)? What I thought I was seeing was an increase in tailwind component reported by the Butterfly increased my glide range on the Butterfly, and reduced it in XCSoar. Consistent, given that the arrows seem to be backwards. I don't know if that is an XCSoar bug or a Butterfly bug. The wind is coming from the Butterfly via LX sentence protocol.

The Butterfly computes wind VERY rapidly from the ISU. This was interesting in the rough thermals on Saturday. Not uncommon to feel a strong side gust, look at the Butterfly and see it report a very large wind vector change in response. It is unclear how this is smoothed for glide calcs, but maybe not at all - XCSoar always followed the Butterfly vector exactly, just 180 degrees out on direction.

I will report it as soon as they let me in the door.....

[jfitch]

On Sunday, July 14, 2013 6:39:47 PM UTC-7, wrote:
> On Sunday, July 14, 2013 2:08:50 PM UTC-4, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this?
>
> >
>
> >
>
> >
>
> > Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?
>
>
>
> Well, it only saves a few taps, but the gesture to get into the nav stuff
>
> is right, down. That will take you directly to the task calculation screen.
>
> Getting to the turnpoint stuff takes 1 tap after that. The gesture really
>
> comes in handy when flying a time-distance task (AAT or MAT), though.
>
>
>
> Matt

OK, the gesture helps, removes two taps. Why don't they have touch & hold semantics like everyone else? I guess I will suggest that if they let me onto the forum.

[Richard[_9_]]

On Sunday, July 14, 2013 11:08:50 AM UTC-7, jfitch wrote:
> Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this? Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?

In my glider the Butterfly wind is similar to the PowerFlarm - V7(ISU firmware) - Ultimate Le running SeeYou PNA. So I don't think it is a Butterfly problem.

Richard
Craggy Aero LLC

[[email protected]]

On Sunday, July 14, 2013 11:09:15 PM UTC-4, Richard wrote:
> On Sunday, July 14, 2013 11:08:50 AM UTC-7, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this? Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?
>
>
>
> In my glider the Butterfly wind is similar to the PowerFlarm - V7(ISU firmware) - Ultimate Le running SeeYou PNA. So I don't think it is a Butterfly problem.
>
>
>
> Richard
>
> Craggy Aero LLC

It's interesting that when I was using SoarPilot with Condor a while back
it would interpret the wind data coming in the LX sentences in the opposite
direction that Condor indicated. Now, when I use XCSoar the wind always
agrees exactly with Condor. A number of years ago I had SoarPilot connected
to an LX5000, but I wound up treating it as a generic GPS source rather
than using the vario data since SP's lift graph never worked right if I
told it it was connected to an LX.

On a related note I'm hoping to finally see what XCSoar makes of my
Clearnav data this weekend.

Matt

[jfitch]

On Sunday, July 14, 2013 8:09:15 PM UTC-7, Richard wrote:
> On Sunday, July 14, 2013 11:08:50 AM UTC-7, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this? Another question for XCSoar users: There must be some better way to edit a task in the air than I have discovered. The only way I have found to do it is (Double tap)>Nav>Task>Turnpoints>Add Turnpoint>Add Turnpoint again (or select)>(Scroll through list and find turn point)>(Select turn point)>(Select again or touch 'Select')>(Hit up arrow several times to get it to the right place)>Close>Fly. Minimum of 12 taps and maybe a lot more. There must be a much quicker way with a lot less head down time. What is it?
>
>
>
> In my glider the Butterfly wind is similar to the PowerFlarm - V7(ISU firmware) - Ultimate Le running SeeYou PNA. So I don't think it is a Butterfly problem.
>
>
>
> Richard
>
> Craggy Aero LLC

Richard, do you have the Butterfly putting out LX or CAI format?

I think the wind was correct on Winpilot (but I wasn't paying much attention at that moment) so maybe it is a XCSoar problem. I do have XCSoar configured for LX input - should try something else and see if the wind suddenly reverses.

[Max Kellermann[_2_]]

On Sunday, July 14, 2013 8:08:50 PM UTC+2, jfitch wrote:
> Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this?

This sounds very much like the Butterfly firmware bug that was reported to the XCSoar bug tracker 4 months ago:

http://bugs.xcsoar.org/ticket/2660

[jfitch]

On Monday, July 15, 2013 3:44:56 AM UTC-7, Max Kellermann wrote:
> On Sunday, July 14, 2013 8:08:50 PM UTC+2, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector (derived from Butterfly information) seem to disagree by 180 degrees. That is they point toward each other. XCSoar seems to believe it too, based on glide calculations. I am using the LX format output on the Butterfly. I am assuming the arrow on each is intended to point the direction the wind it blowing towards, I.e., a vector. From observation, the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen this?
>
>
>
> This sounds very much like the Butterfly firmware bug that was reported to the XCSoar bug tracker 4 months ago:
>
>
>
> http://bugs.xcsoar.org/ticket/2660

I will get to the bottom of this. Please tell me, what is the assumption of XCSoar?

In particular, a CAI 302 !w sentence that looks like this:

!w,180,30,5,,,,,,,,,,*hh

would be interpreted how? Wind blowing from north towards the south, or south towards the north?
(my interpretation of the description "vector wind direction in degrees" indicates from north to south)

In an LX mode, an $LXWP0 sentence that looks like this:

$LXWP0,,,,,,,,,,180,3*hh

would be interpreted how? Wind blowing from north towards the south, or south towards the north?
(description is less clear, "windcourse" would seem to mean same thing as Cambridge)


How does one get access to the XCSoar forum and bug reporting scheme? I registered over the weekend, but my registration is being held I guess.

[Dan Marotta]

I've been using XCSoar on an Android with a CAI-302 for almost 3 years now
and the wind calculation/display works perfectly.

If you tecchies would look outside once in a while instead of at your
whiz-bang panels, you could compare the wind velocity arrow to the cloud
shadows. Oh, wait! That would be too much like pilotage.



"jfitch" > wrote in message
...
On Monday, July 15, 2013 3:44:56 AM UTC-7, Max Kellermann wrote:
> On Sunday, July 14, 2013 8:08:50 PM UTC+2, jfitch wrote:
>
> > Got a question: the Butterfly wind vector and the XCSoar wind vector
> > (derived from Butterfly information) seem to disagree by 180 degrees.
> > That is they point toward each other. XCSoar seems to believe it too,
> > based on glide calculations. I am using the LX format output on the
> > Butterfly. I am assuming the arrow on each is intended to point the
> > direction the wind it blowing towards, I.e., a vector. From observation,
> > the Butterfly appears to be correct, XCSoar 180 off. Has anyone seen
> > this?
>
>
>
> This sounds very much like the Butterfly firmware bug that was reported to
> the XCSoar bug tracker 4 months ago:
>
>
>
> http://bugs.xcsoar.org/ticket/2660

I will get to the bottom of this. Please tell me, what is the assumption of
XCSoar?

In particular, a CAI 302 !w sentence that looks like this:

!w,180,30,5,,,,,,,,,,*hh

would be interpreted how? Wind blowing from north towards the south, or
south towards the north?
(my interpretation of the description "vector wind direction in degrees"
indicates from north to south)

In an LX mode, an $LXWP0 sentence that looks like this:

$LXWP0,,,,,,,,,,180,3*hh

would be interpreted how? Wind blowing from north towards the south, or
south towards the north?
(description is less clear, "windcourse" would seem to mean same thing as
Cambridge)


How does one get access to the XCSoar forum and bug reporting scheme? I
registered over the weekend, but my registration is being held I guess.

[Marc - Butterfly Avionics]

to shed some light in this:

CAI: our fault, this was a bug that has been resolved a while ago.

LX: sorry guys, there is no spec on the LXWP wind direction (at least nobody knows of a specification). Both directions are commonly used depending on software you use. Rumors say that even LX devices exist that send data differently (is this true? i don't know). iGlide e.g. features a switch for that.

We will sure use the most common "interpretation" but the question is which one is the most common?

[jfitch]

On Monday, July 15, 2013 8:51:18 AM UTC-7, Dan Marotta wrote:
> I've been using XCSoar on an Android with a CAI-302 for almost 3 years now
>
> and the wind calculation/display works perfectly.
>
>
>
> If you tecchies would look outside once in a while instead of at your
>
> whiz-bang panels, you could compare the wind velocity arrow to the cloud
>
> shadows. Oh, wait! That would be too much like pilotage.
>
>

If you are flying in the flatlands where the clouds are 2000 AGL and likely to be blowing the same way as the air you are flying in, that works great. Otherwise, not so much.....

For example, final glide Saturday, 77 miles Mt. Patterson to Truckee out of 17,500. Cloud drift not discernible from altitude (or forming ahead as fast as drift), wind lines on Topaz Lake indicate calm, wind lines on Lake Tahoe indicate SSW about 10, AWOS at Truckee reporting W at 7, Butterfly showing 25 knots south. Butterfly says tailwind (and it is correct, too), XCSoar says headwind. Drop through about 12,000 ft., wind switches to 7 from the west. Have fun with your pilotage on that one.

[Dan Marotta]

Guess I've been flying long enough and without any high tech aids that it
just works for me. And, for the record, at Moriarty we routinely fly at
altitudes up to 18,000 MSL with surface altitudes from about 5,000 up to
around 13,000 MSL.

Personally, I get nervous below about 12,000 MSL unless I'm within gliding
distance of a landable field and, for that reason, my flights aren't nearly
as long as they could be.

"jfitch" > wrote in message
...
On Monday, July 15, 2013 8:51:18 AM UTC-7, Dan Marotta wrote:
> I've been using XCSoar on an Android with a CAI-302 for almost 3 years now
>
> and the wind calculation/display works perfectly.
>
>
>
> If you tecchies would look outside once in a while instead of at your
>
> whiz-bang panels, you could compare the wind velocity arrow to the cloud
>
> shadows. Oh, wait! That would be too much like pilotage.
>
>

If you are flying in the flatlands where the clouds are 2000 AGL and likely
to be blowing the same way as the air you are flying in, that works great.
Otherwise, not so much.....

For example, final glide Saturday, 77 miles Mt. Patterson to Truckee out of
17,500. Cloud drift not discernible from altitude (or forming ahead as fast
as drift), wind lines on Topaz Lake indicate calm, wind lines on Lake Tahoe
indicate SSW about 10, AWOS at Truckee reporting W at 7, Butterfly showing
25 knots south. Butterfly says tailwind (and it is correct, too), XCSoar
says headwind. Drop through about 12,000 ft., wind switches to 7 from the
west. Have fun with your pilotage on that one.

[son_of_flubber]

On Monday, July 15, 2013 12:03:05 PM UTC-4, Marc - Butterfly Avionics wrote:

> LX: sorry guys, there is no spec on the LXWP wind direction (at least nobody knows of a specification). Both directions are commonly used depending on software you use. Rumors say that even LX devices exist that send data differently (is this true? i don't know). iGlide e.g. features a switch for that.
>
> We will sure use the most common "interpretation" but the question is which one is the most common?

Does anyone know if XCSoar correctly interprets the wind direction information that it gets from a V7? Or does XCSoar have the same problem with the V7 that was reported here for the Butterfly/XCSoar combination?

I understand that the problem is that there is no known specification for the windage protocol and so it is not a defect attributable to either vario or XCSoar.

[Max Kellermann[_2_]]

On Wednesday, July 17, 2013 2:28:21 AM UTC+2, son_of_flubber wrote:
> Does anyone know if XCSoar correctly interprets the wind direction information that it gets from a V7?

This question cannot be answered, because the V7 does not send a wind estimate over the wire.

[son_of_flubber]

On Wednesday, July 17, 2013 5:56:21 AM UTC-4, Max Kellermann wrote:
> On Wednesday, July 17, 2013 2:28:21 AM UTC+2, son_of_flubber wrote:
>
> > Does anyone know if XCSoar correctly interprets the wind direction information that it gets from a V7?
>
>
>
> This question cannot be answered, because the V7 does not send a wind estimate over the wire.

Right, the issue never comes up. The V7 calculates a wind vector for it's internal "get home" function, but it sends airspeed "over the wire" to XCSoar. XCSoar combines the V7 supplied airspeed with the GPS supplied ground speed and direction to calculate a wind vector.

XCSoar can calculate wind based on GPS position (alone) over time but the V7 supplied airspeed makes the wind calculation more accurate and robust.

Did I get that right?

[jfitch]

On Wednesday, July 17, 2013 5:13:10 PM UTC-7, son_of_flubber wrote:
> On Wednesday, July 17, 2013 5:56:21 AM UTC-4, Max Kellermann wrote:
>
> > On Wednesday, July 17, 2013 2:28:21 AM UTC+2, son_of_flubber wrote:
>
> >
>
> > > Does anyone know if XCSoar correctly interprets the wind direction information that it gets from a V7?
>
> >
>
> >
>
> >
>
> > This question cannot be answered, because the V7 does not send a wind estimate over the wire.
>
>
>
> Right, the issue never comes up. The V7 calculates a wind vector for it's internal "get home" function, but it sends airspeed "over the wire" to XCSoar. XCSoar combines the V7 supplied airspeed with the GPS supplied ground speed and direction to calculate a wind vector.
>
>
>
> XCSoar can calculate wind based on GPS position (alone) over time but the V7 supplied airspeed makes the wind calculation more accurate and robust.
>
>
>
> Did I get that right?

I will say that the inertial derived wind vector from the Butterfly Vario is awesome.

[Max Kellermann[_2_]]

On Thursday, July 18, 2013 2:13:10 AM UTC+2, son_of_flubber wrote:
> XCSoar can calculate wind based on GPS position (alone) over time but the V7 supplied airspeed makes the wind calculation more accurate and robust.
>
> Did I get that right?

Mostly right, let me clarify:

With just GPS, XCSoar can only use the "Circling" algorithm, which compares ground speeds in opposite circle positions. Wind calculation occurs only while thermalling.

With airspeed input, XCSoar uses an Extended Kalman Filter (https://en.wikipedia.org/wiki/Extended_Kalman_filter) which continuously compares airspeed and ground speed, and can always derive an accurate wind vector while flying straight.

There is a big difference in quality/accuracy and speed between the two algorithms. According to my tests, the EKF algorithm delivers the exact wind after flying straight for less than 20 seconds, while the circling algorithm takes more than a minute of circling, with varying results.

For those curious, this link has a dump:

http://bugs.xcsoar.org/ticket/2961#comment:4

This is a bug report from a user, he uploaded a NMEA dump, which I fed into both algorithms. Observe the volatility of the CirclingWind results.

TL;DR - feeding airspeed into XCSoar is totally worth it. Get a vario that is capable of doing so.

[jfitch]

On Wednesday, July 17, 2013 8:40:41 PM UTC-7, Max Kellermann wrote:
> On Thursday, July 18, 2013 2:13:10 AM UTC+2, son_of_flubber wrote:
>
> > XCSoar can calculate wind based on GPS position (alone) over time but the V7 supplied airspeed makes the wind calculation more accurate and robust..
>
> >
>
> > Did I get that right?
>
>
>
> Mostly right, let me clarify:
>
>
>
> With just GPS, XCSoar can only use the "Circling" algorithm, which compares ground speeds in opposite circle positions. Wind calculation occurs only while thermalling.
>
>
>
> With airspeed input, XCSoar uses an Extended Kalman Filter (https://en.wikipedia.org/wiki/Extended_Kalman_filter) which continuously compares airspeed and ground speed, and can always derive an accurate wind vector while flying straight.
>
>
>
> There is a big difference in quality/accuracy and speed between the two algorithms. According to my tests, the EKF algorithm delivers the exact wind after flying straight for less than 20 seconds, while the circling algorithm takes more than a minute of circling, with varying results.
>
>
>
> For those curious, this link has a dump:
>
>
>
> http://bugs.xcsoar.org/ticket/2961#comment:4
>
>
>
> This is a bug report from a user, he uploaded a NMEA dump, which I fed into both algorithms. Observe the volatility of the CirclingWind results.
>
>
>
> TL;DR - feeding airspeed into XCSoar is totally worth it. Get a vario that is capable of doing so.

How do you know a wind vector is exactly accurate? Genuinely interested....

Also I can't claim to understand the EKF filter, is it possible to describe in layman's terms how the vector is derived from straight flight observations? Component velocity obviously, but the vector?

[Max Kellermann[_2_]]

On Thursday, July 18, 2013 6:59:42 AM UTC+2, jfitch wrote:
> How do you know a wind vector is exactly accurate? Genuinely interested.....

After 20 seconds, I get a result that is consistent with the following calculations. Adding more data will not change the wind vector (unless the wind really changes). The EKF wind matches the CirclingWind result, but the CirclingWind is more volatile (inaccurate) and needs much more time for the initial estimate.

That's not a proof, but it strongly suggests that our EKF wind is very accurate and quick.

[Max Kellermann[_2_]]

On Thursday, July 18, 2013 6:59:42 AM UTC+2, jfitch wrote:
> Also I can't claim to understand the EKF filter, is it possible to describe in layman's terms how the vector is derived from straight flight observations? Component velocity obviously, but the vector?

I forgot to respond to that part of your post. I can't because I don't understand this filter either. Kalman and EKF are pure magic to me. It was John Wharington who engineered this. If you're interested, check out the source code, XCSoar is open source!

http://git.xcsoar.org/cgit/master/xcsoar.git/tree/src/Computer/Wind/WindEKF.cpp

[jjbird]

> How do you know a wind vector is exactly accurate? Genuinely interested.....

Im some sense you don't, truthing that kind of thing isn't easy or cheap. You can get some confidence in it through simulation and otherwise you fly with it a bunch and it consistently seems "about right"

> Also I can't claim to understand the EKF filter, is it possible to describe in layman's terms how the vector is derived from straight flight observations? Component velocity obviously, but the vector?

The EKF is a generalization of a kalman filter which is used to estimate a value that isn't measurable directly but is related to some quantity that you can measure. Basically it runs a simulation of your system. From this simulation you get the value you are interested in (we like to call them "states"), you also get out a prediction of what you expect your next measurement to be. By comparing this measurement to what you actually get from a sensor you can correct errors in your simulation. There's some linear algebra in between this description and the thing actually working, but it works so well that it seems like magic.

I poked through the source code, and the way it works in XCSoar is pretty cute. The "states" used here are the wind speeds and a term to take care of density change with altitude (and unit scaling). The "simulation" predicts that the wind speed should be constant all the time. When it is time to correct the model, the wind is subtracted from the GPS velocity, giving a guess at the airspeed vector which is then used to compute a guess at the dynamic pressure. By comparing the dynamic pressure measured to what it was expected to be, the EKF can start to drive out errors. After a few seconds of chunking away at this, the wind estimate should be pretty good.

HTH

[son_of_flubber]

I think that passing airspeed to XCSoar (V7 approach) is advantageous compared to passing the wind vector (Butterfly approach) to XCSoar.

On Thursday, July 18, 2013 12:59:42 AM UTC-4, jfitch wrote:
> How do you know a wind vector is exactly accurate?

If you're relying on software to get you somewhere safely, the bottom line is that you want to know that the implementation is robust and correct under a variety of scenarios. You might be able to formally prove that the algorithm is correct, but that tells you nothing about the correctness of the implemented code.

To raise confidence in the implementation you need an "Oracle", a way of knowing the correct answer so that you can compare the expected answer with the computed result. One could write a program that would generate a synthetic GPS and airspeed trace for a known wind and heading, feed that to XCSoar (on the ground in a testing harness), and compare the actual result to the expected result. To raise confidence you would need to test as many non-equivalent scenarios as possible. To some extent these scenarios could be generated painstakingly by hand. To go one level further, one could write a program that would generate a large number of test scenarios (1000s) randomly and automatically run the scenarios through XCSoar. That would gradually raise confidence in the implementation. You also need to verify the correctness of the test program, and so all of this is rather time-consuming, and so we generally rely on the warm and fuzzy feeling that we get when software "seems to work fine". It is difficult to generate exhaustive scenario based testing and for that reason XCSoar's rather unique unit tests are a smart and efficient way to raise confidence. Some programs rely more heavily on scenario and user testing.

The thing that I like about the way that XCSoar takes the raw airspeed data from the V7 is that the V7 independently computes a wind vector and you can compare that vector to the vector computed by XCSoar. If XCSoar took the wind vector from V7, you would see the same, possibly wrong vector displayed in two places. So it is possible to do a "poor man's verification" by comparing the wind vectors computed by the V7 with the vector computed by XCSoar, in flight and under a variety of conditions. You cannot make a meaningful comparison when XCSoar takes the wind vector from the Butterfly because there is no independent computation of the vector. That's said, it is entirely possible for two (or three) completely independent implementations to make exactly the same mistake and end up agreeing on the wrong answer. The prudent pilot does a sanity-check on anything that a computer tells him in the air.

[jjbird]

....
> > is it possible to describe in layman's terms how the vector is derived from straight flight observations? Component velocity obviously, but the vector?
>

Oops, forgot a bit...you are right that you can't get the wind vector from straight-line observation (at least with the current formulation, with more sensors you can do it). This will only allow you to predict the wind along the direction you are currently flying. As soon as you turn at all however, you'll have information about the wind in another direction. After a bit or circling or even just some turns back and forth the filter will be able to figure things out. If you fly for a long time in one direction the wind estimate might start to drift a bit though.

[Marc - Butterfly Avionics]

On Wednesday, July 17, 2013 11:56:21 AM UTC+2, Max Kellermann wrote:
> On Wednesday, July 17, 2013 2:28:21 AM UTC+2, son_of_flubber wrote:
>
> > Does anyone know if XCSoar correctly interprets the wind direction information that it gets from a V7?
>
>
>
> This question cannot be answered, because the V7 does not send a wind estimate over the wire.

Latest version of Butterfly Vario Firmware (more accurate: Butterfly NMEA Interface Unit firmware contained in the latest release) rotates output on LXWP 180° so that it matches XCSoars assumption.

Still don't know if this makes sense, yet it will work for now and I guess its a good idea to share the XCSoar teams assumption...

Cheers
Marc

[jfitch]

On Thursday, July 18, 2013 6:10:05 AM UTC-7, jjbird wrote:
> ...
>
> > > is it possible to describe in layman's terms how the vector is derived from straight flight observations? Component velocity obviously, but the vector?
>
> >
>
>
>
> Oops, forgot a bit...you are right that you can't get the wind vector from straight-line observation (at least with the current formulation, with more sensors you can do it). This will only allow you to predict the wind along the direction you are currently flying. As soon as you turn at all however, you'll have information about the wind in another direction. After a bit or circling or even just some turns back and forth the filter will be able to figure things out. If you fly for a long time in one direction the wind estimate might start to drift a bit though.

OK, I agree that wind velocity component in the direction of flight is derivable this way. Must the be engineer in me, "vector" means velocity and direction. My rather limited understanding of the EKF suggests that it is a very elegant way to get a quick reading for velocity out of the jittery GPS data.

On XCSoar then, if I check Both in the wind preferences and turn off the "prefer external" then I will get the XCSoar calculation based on circling or EKF filtered straight flight data? I am interested in comparing this with the Butterfly inertial derived wind vector.

Could ask this on the XCSoar forum, but for some reason I am banned from the site....

And thanks, Marc, for a quick resolution to this.