Thermal direction finder

[jochenelser]

[iltis42]

Some thoughts to the idea:

1. It makes good sense to draw the average wind over a longer period of time maybe in the range of minutes while the current wind is averaged in a shorter period by several seconds. Note that the live wind measurements are noisy as pilots correct sideslip more or less with some error but this error is usually equal around the centerline, so after 15 to 20 seconds we can expect a stable measurement according to my tests in flight.

2. The resulting tornado effect "wind vector" can be evaluated by the library we already have: https://github.com/iltis42/XCVario/blob/master/main/vector.cpp, as the difference between the current wind vector from the average wind vector.

3. Regarding the relative bearing i can't follow. The formulas above show IMHO the relative bearing of the center of the thermal to the measured tornado wind vector. The planes heading should be regarded in my opinion to talk about a relative bearing. If the glider approaches a thermal left or right the center, things look different. Only this two vectors had to regarded IMHO, the vector the glider is heading to and the tornado effect wind vector.

4. Generally speaking: Approaching the thermal tornado from outside, the thermal wind vector relative to the gliders heading will always be from the left side and leaving it from the right side on the northern hemisphere as of the counterclockwise rotation of the thermal. See also figure below.

5. If there is a tailwind component of the thermal wind compared with the heading, the center is left (1) and if there is a headwind component, the the center is right (3), finally if there is neither head or tailwind component, the center is exactly straight in front (2).

Rotation of Thermals and their effect on the wind also referenced here:
https://www.imk-tro.kit.edu/download/Thermik_von_A_bis_Z.pdf

Contains measurements supporting the theory :)

[hjr]

Hey .. good ideas,
what I am missing here is the realistic estimate of vector dimensions. Up to my understanding the tornado effect drops off fast moving away from the thermal center. Yes, I would like to see an instant wind vector that gives me the hope that this kind of models might be applicable. For now I do not have any prove that the t... vectors dimension significantly exceed the noise level. XCV as a senor box should contribute a best possible IMU, pressure, temp, etc. sensors. A good GPS source of real 1Hz, or more, is needed. Then you are be able to filter the instant wind vector. If this proven to be stable the next step will be the tornado model. The right place to implement it is XcSoar. The way to do it is well described and basically C++.

[iltis42]

In my last flights i had an eye on the changes of the wind, and my impression is the stronger the thermal, the stronger the effect. The thermal wind vector is absolutely not marginal, e.g. June 17 (yes its was a good day), changes of the wind vector up to 40° in direction and up to 20 km/h in windspeed i could see, and in the below picture at second 172, created from an older nmea log, we can even see the effect.
Not always direction and speed changes what might indicate that this information as from my drawing above could indicate how exactly we enter the thermal tornado. If i remember right, this image was a direct hit, means no big corrections were needed to center thermal, and obviously there wasn't any change in speed in that case.
Agree with XCSoar, there is already a tornado like marker for the thermal center, plotted based on the TE vario indications somehow as a center of gravity of lift in a recent period of time. Maybe some AI like method could join this with the live wind?
As a first step IMHO we needed to forward the XCVario live wind in our protocols to XCSoar, what is ATM only provided in the $WIND nmea "debug" sentence.

[jochenelser]

Hi everybody, thank you for your interest in the idea.
I read the comments, and it would be a very long text to answer all of them.

In fact I was searching for somebody who would like to code it in the XCVario as I had no glimpse how to do that, but I could not find sombody. The principle I described is not yet approved in the air, and it would have been fine to see how it is working till june or july (I wrote it in April). But as the formulas and the principle in my opinion are rather simple, there is no need to go too much into detail. I assure you that the formulas described are correct, cause in the meantime I checked them practically with hundreds of cases using the program I wrote myself, (as nobody liked to code it in the last months).

I tried my best: As an absolute beginner I had to learn how to code it in C++. Over all it took me one evening (6,5 h's) to code this small routine, included to watch some Youtube-videos to learn how to do this (so obviously it was not such a big deal). The tiny little code is finished, and it is working pretty well as an .exe routine. I had to correct some mistakes, which were mainly the +/- problem. (This is one of my weaknesses: I am always mixing up plus and minus ;-)

The biggest problem I have right now are not the formulas or a code, that's done. It is only, that I destroyed my mainboard due to overvoltage on my USB, when trying to program a microprozessor in the last 2 weeks to be able to test the program in the air. As I mentioned I am a bloody beginner in programming...

So for me the task to code it is closed. Now I have to repair my notebook first ;-)

When the principal is been tested sucessfully in the air, I will come back with the probably further developed code for implementation.

Have a good time everybody

[hjr]

Did not find the link to your code, otherwise I am pretty sure it would be in a XCS or XCV branch soon and available to test for you.

[jochenelser]

Thanks a lot for the offer!
It would be a fine thing to do that. But the code is on the destroyed notebook and unfortunatly not available till the notebook repaired. It will take's some time. And I don't like to do it again. Next weeks I am on vacation. So the time slot this year probably passed.
And the code is not available in the net, so how could I post a link? And if I use the <> "Add code" it is only txt. So I could better add the code as an text here, make's no difference in my opinion. Don't know how this is usually done here...

[iltis42]

As a first prove of concept i have implemented an option to display the "thermal wind" instead of the measured wind. Per default the average wind is 60 seconds (adjustable), the termal wind is averaged by 10 seconds (adjustable). To see in real flight if this is helpful. With the thermal wind-vector, according to my drawing we can already guess where the center is located. Will try that tomorrow hopefully if i can get away from my homefield:
dc6a04d

[jochenelser]

Yes, this is maybe an idea to get a first glimpse. But maybe this will mislead in some situations, as using different ways of calulations? Best would be in my opinion to have the two winds "old" and "momentaneous" switchable on the wind symbol, both created out of one principle (if possible to do so).

Therefore I would first think about the minimum lag of the monentaneous straight wind calc:

As far as I understood the manual and the straight wind code (...I only understood parts of the code...) and after checking flight data (NMEA-protocol, logged via a flight) I found:

1.) The wind with default "20" would calculate the wind out of the last 60 s as you wrote in the manual. So it shows the average 30 s ago. Better is a maximum "5-10" or something to show the wind 8-15 s ago. This is difficult as wind is more biased then. Therefore the other comments:

2.) The use of the averager itself I think overinterprets the "old" wind data. Better would be the use of a real low pass in my opinion. It will be able to show a 1,5 -2 times faster with the same quality as before. And a shorter time interval for wind calculation, best 0,2 s (or as much as is possible) would grant high advantage. With your principal of using mag sens for heading this should be possible and much easier to implement, than if using a GPS.

3.) But we still will receive a biased, nerveous wind. I am not really shure, but is the following interpretation of the signal analysis correct?

• Heading (Magnet) > LP-Dämpfung Heading > Anzeige Heading
• True Heading (aus HP IMU und LP GPS) minus Heading (aus Magnet) > Averager Wind > Anzeige Wind

If yes, this would help in my opinion:

• True Heading (aus HP IMU und LP GPS) minus Heading (aus LP Magnet) > Anzeige Wind

Reason is, that I found a very high correlation of the mag sens bias with the wind signal bias. If you calc a difference of two sensors, in my experience it is much better not to use any damping of the output signal, it is much better to do a "coordinated" (!) filtering of the both input signals before. E.g.: Not to use different principals (mixing lin filter, averager, aso) and using same time constants for the merged raw input "heading" (out magnetic) and the raw input "TC" (out of GPS and IMU), etc. Otherwise this will create bias and not filter the existing bias (> all kind of strange beats, Schwebungen you can imagine). It is like the front axle and the rear axle in a car are doing different things: You will feel uncomfortable, doesn't matter how good the dampers of each axle are..

Maybe I misinterpreted the signal chain in the code and the manual? But the flight data are showing such effects.

If you would rework filtering I estimate the straight wind data could be about two to three times faster, and the wind would be reliable with 5 to 10 s lag maximum and a rather stable output. This filtering in my opinion should not be possible for the user to adjust, it is more a matter of the performance critical basic systems tuning.

With that resulting wind we could only focus on straight wind:
1.) Straight wind Low pass out of the last 30 min - with wind speed
2.) Straight wind out of calc above with a maximum lag of 5 to 10 s - with wind speed

If you show these two winds changeable, better as an overlay of the both signals, it maybe would give you a reliable base for interpreting?

But I am doubting, that somebody can interpret wind direction changes and not to forget the wind speed changes so fast in the cockpit to get the real thermal direction easily and really correct. I trained myself to do like in the calculation, to understand it in a few second with a "powerpoint training" and I think if I fully concentrate on it, in flight maybe I could do so. Roland finally didn't succeed in that. He uses "mental shortcuts", which do not need so much workload in the cockpit, but they are not working in every situation (the tested calc function works in every situation).

[iltis42]

Yes, this is maybe an idea to get a first glimpse. But maybe this will mislead in some situations, as using different ways of calulations? Best would be in my opinion to have the two winds "old" and "momentaneous" switchable on the wind symbol, both created out of one principle (if possible to do so).

Its just about a first glimpse today. Nothing more.

Therefore I would first think about the minimum lag of the monentaneous straight wind calc:

As far as I understood the manual and the straight wind code (...I only understood parts of the code...) and after checking flight data (NMEA-protocol, logged via a flight) I found:

1.) The wind with default "20" would calculate the wind out of the last 60 s as you wrote in the manual. So it shows the average 30 s ago. Better is a maximum "5-10" or something to show the wind 8-15 s ago. This is difficult as wind is more biased then. Therefore the other comments:
The averager can be adjustes as you like. 60 seconds is a good compromise. Lower periods will more quickly tune in to a new wind situation. For navigation purposes and situation awareness (where does the wind current come from ?) the temporary thermal wind disturbance is an unwanted effect.

2.) The use of the averager itself I think overinterprets the "old" wind data. Better would be the use of a real low pass in my opinion. It will be able to show a 1,5 -2 times faster with the same quality as before. And a shorter time interval for wind calculation, best 0,2 s (or as much as is possible) would grant high advantage. With your principal of using mag sens for heading this should be possible and much easier to implement, than if using a GPS.
A true low pass filter, e.g. a buttworth low pass filter is for sure an option. A higher frequency of GPS fixes can't be done with standard Flarm's, they emit every second one fix.

3.) But we still will receive a biased, nerveous wind. I am not really shure, but is the following interpretation of the signal analysis correct?

* Heading (Magnet) > LP-Dämpfung Heading > Anzeige Heading

* True Heading (aus HP IMU und LP GPS) minus Heading (aus Magnet) > Averager Wind > Anzeige Wind

Basically this is correct.

If yes, this would help in my opinion:

* True Heading (aus HP IMU und LP GPS) minus Heading (aus LP Magnet) > Anzeige Wind

Reason is, that I found a very high correlation of the mag sens bias with the wind signal bias. If you calc a difference of two sensors, in my experience it is much better not to use any damping of the output signal, it is much better to do a "coordinated" (!) filtering of the both input signals before. E.g.: Not to use different principals (mixing lin filter, averager, aso) and using same time constants for the merged raw input "heading" (out magnetic) and the raw input "TC" (out of GPS and IMU), etc. Otherwise this will create bias and not filter the existing bias (> all kind of strange beats, Schwebungen you can imagine). It is like the front axle and the rear axle in a car are doing different things: You will feel uncomfortable, doesn't matter how good the dampers of each axle are..

Any external GPS comes with low pass filtering and latency by one to three seconds. The other values are also filtered in such a way, that they should meet on the time axis.

Maybe I misinterpreted the signal chain in the code and the manual? But the flight data are showing such effects.

If you would rework filtering I estimate the straight wind data could be about two to three times faster, and the wind would be reliable with 5 to 10 s lag maximum and a rather stable output. This filtering in my opinion should not be possible for the user to adjust, it is more a matter of the performance critical basic systems tuning.

Some people want to see any of those effects in a small timeframes, e.g. sideslip, thermal disturbance, or just turbulences, some want not :)

With that resulting wind we could only focus on straight wind: 1.) Straight wind Low pass out of the last 30 min - with wind speed 2.) Straight wind out of calc above with a maximum lag of 5 to 10 s - with wind speed

If you show these two winds changeable, better as an overlay of the both signals, it maybe would give you a reliable base for interpreting?

But I am doubting, that somebody can interpret wind direction changes and not to forget the wind speed changes so fast in the cockpit to get the real thermal direction easily and really correct. I trained myself to do like in the calculation, to understand it in a few second with a "powerpoint training" and I think if I fully concentrate on it, in flight maybe I could do so. Roland finally didn't succeed in that. He uses "mental shortcuts", which do not need so much workload in the cockpit, but they are not working in every situation (the tested calc function works in every situation).

Yeah, some effort to reduce the workload was desirable, sure.

[iltis42]

Here a shot video from the today's test:
https://www.youtube.com/watch?v=Rdb_Js1F1Yc
The video was taken in approach of a flat thermal, a beginning condensation in an almost blue sky.
The straight wind average was set to 120 seconds and the thermal wind average to 15 seconds (later i tried 6 seconds).
The wind arrow is made with Thermal Wind "Enable" from therm-dev branch.
In the video we see as the thermal wind jumps from the left as soon as the climb started with some (little) tail wind component.
According to my handmade drawing above, tailwind meant that we hit the counterclockwise rotating thermal on the right edge, so i turned to the left and bingo, there is the lift 2.6 m/s later turning to above 3 m/s!
Basically good news, this time it worked!
But there is also bad news. The same thing happened several times when there was no lift at all. Okay it was a dry thermal day with almost blue sky and everybody knows that in that condition strange things happen, inversions may deflect lift and create just wind or even worse bad sink. So we can't blindly turn to the left when there is a tail-wind component in order to catch a thermal, have tried this 5 times and there was just sink. Just and idea, may sink also create a cyclonic pattern and trick us?
What i can summarize by today:
When there is already a bit lift started, as here in the video we see a flat condensation, and when the wind starts blowing from the left, we are approaching a new thermal, and by tailwind or headwind component, we may better guess left or right.
More tests to be done with different timings, maybe true low pass filtering.

[jochenelser]

Yes, understood the first comments: So the user may have different requirements to the wind damping aso., than the thermal finder. So better to have different filtering and merging for user wind and thermal finder wind.

The test is really exciting, the principal of using thermal vs. straight wind seems to work in a way: The interpreteation: wind left thermal ahead, wind turns right: Passed the center, thermal behind, headwind stronger: Thermal left are a easy ways to approch the topic.

For the interpretation of the downdrafts I have three ideas:

• A thermal with opposite rotation: But if it is like this, it is strange, that it appears more often than the opposite direction: And if there is right turning thermal, often there is the second coressponding core left turned aside and not a sink. From experience with right circling as the better working variant and different bank angles experienced, left turn circling thermals I found in the most cases
• Second like you wrote a cyclonal cold downdraft, like in a Roland Emmerichs movie? Never heard about it apart from the movie. But if it exists, it is strange, that it also appeared more often than the thermals. Maybe to check literature.
• A filtering and sensor merging topic, like described: The only one, what we could work about right now.

So I would expand the generelly geometrical topic to create an additional module for an optimized long term and short term wind, decoupled from the user winds. I will make up my mind about it. Maybe I can design it out of the existing data.

An of course best is going on observing the behaviour of the wind in the air.

[iltis42]

The interpretation for headwind and tailwind component can help for the direction. IMHO we needed not only to consider wind, but also lift for thermal finding. Otherwise we may even center sink with this approach if the theory of rotation in downdrafts is true as well.
Actually it did not take place more often that there was only sink. I had just tried, whenever there was a rising wind from the left with some tailwind component, blindly to curve to the left side, or with a headwind component to the right side what did not work. In the video there is along with the growing wind from the left also already a lift by one to two meters. What we simply needed to do in my opinion is to connect both things, the wind and the lift for the whole picture. Maybe the gyro or accelerometer can also help here to get a better idea for the direction. Those instruments are likely more sensitive than the most important body part of a glider pilot, if you know what i mean ;)
In further tests we need to confirm if the above is all can be reproduced and in what degree this helps for a better decision to start circling left or right.

[jochenelser]

Yes, I also received replies, that the wind diretion led to thermals especially, when there was a minimum of lift before or a good line. Maybe this would make sense. And, yes I agree, to do it well we need as much experience in flight as possible…

[jochenelser]

glider season for this year is over...