openXvario development

[RightRudder]

Since looking at the display may result in you losing the model or at the very least losing the thermal, I think the display format is quite unimportant. For recording the telemetry to the SD card the full resolution can always be used but at least to my mind it is much more important to have the audio output be fast and very meaningful. With a beeping which changes pitch in proportion to climb rate one can tell during circling even which half of the circle is closer to the thermal core just by listening. This is how we do it in the full scale ships without ever looking at the instruments.

[rainer]

yes, fully agree with that. the audio is the most important part when flying. but still it´s nice to have accurate data on the display, in the logs and especally to create the audio. The higher the resolution and the more accurate the transmitted data is, the more possibilities we have to create a good audio signal from that.

[jhsa]

+1.

[bertrand35]

New email from Eva today. Their engineers agreed about the cm/s unit. That's perfect!

Bertrand.

[Promix]

I can check the accuracy down to 1 cm/s

[rainer]

I can check the accuracy down to 1 cm/s

i could supply that value in 1cm/s resolution, but in that case we would have a delay of around 10 seconds before the value will be displayed correctly....

[Promix]

no no, this is a misunderstanding . I wanna say only, that my test equipment is able to check the sensor 10 times higher in resoluion. So at the end we can confirm the 10cm/s (or not).

[rainer]

just joking... but it´s really possible to get a 1cm resolution out of the MS5611, just set the size of the averaging buffer for the pressure readings high. to something like 150... i did that during my tests. it ended up displaying cm value that stable, that i was tempted to use it as a measuring instrument to measure the height of my desk...
but of course theres a downside. the higher the accuracy, the slower the vario reacts. the default buffer length is tuned for a good balance between speed and accuracy.

[Rob Thomson]

What you want is two MS5611. One running accurate.. One running fast...

Then through some interpolation calculate the pseudo accurate reading!

Probably would not work!

[jhsa]

Is the reaction to lift fast, or is there a delay??
I mean, since lift occurs till the vario sound is heard..

João

[Rob Thomson]

In my experience with Varios... you often can see the lift at the same time as hear it. Sometimes fly through it if small before it sounds.

But the vario helps get a 'picture' of the sky. Dont assume it is a cure all!

[RightRudder]

Since the instrument responds to pressure, you have to be climbing before it can respond. In my experience with building thermal sensing instruments and flying I feel the response time needs to be less than 1 second to be useful. Bear in mind that if the current sample is subtracted from a running average the response to a step change is still as fast as the sampling period but the size of the averaging buffer has a dramatic influence on the dynamic behaviour. A small buffer basically desensitizes the instrument to gradual changes because the averager keeps up with the gradual change but also the system has low tolerance for input noise. A large buffer increases sensitivity to gradual changes and improves noise handling but makes for sluggish dynamics.

As an example suppose you are flying level (with cruise power) and fly through a thermal. With a large buffer it is filled with a constant pressure value. When the plane rises there is a delta between current samples and the average so the vario beeps. As the plane now continues past the thermal at a new height the vario continues to beep till the buffer is filled with the new pressure value. The larger the buffer, the longer the lag till it squelches again. In flying with my own electronics I got a sense that with a 10msec sample rate, a 64 register FIFO worked pretty well but I was working with an input with fairly low scatter in the data (low noise). When the signal is noisy (as it can be depending on where your static pressure port is located) then increasing the buffer size can help deal with the noise but impacts the dynamics. This is (one of the reasons) why I have serious doubts about being able to use a TE probe to compensate the vario for energy effects. It will require so much averaging of the local pressure at Cp=-1 that it will ruin the dynamics of the instrument. If the combination of sample rate and buffer size is such that the buffer can be filled with data in ~1/2 sec I think it is in the right range for a vario. That could be just my taste though.

[rainer]

Great explanation! Thanks for that.

I am actually using 2 seperate buffers in the current implementation.

Buffer 1 is used to store and average all the pressure (and thereby altitude) values.
it´s default length is 15 values and it takes around 270 to 300 milliseconds to fill it up once completly.
Every 100ms i am performing the internal calculations.
So we are talking about calculating an average value of all altitudes of the last 270ms every 100ms.
10 of those readings will be used to calculate the actual vertical speed.

The data (alt+vertical speed) will be transmitted to the ground every 200ms.

The response time is allways much better than 1 second. the actual real speed depends on the amount of change in the last readings. as all values are being averaged, only a big change of the last reading will have a high enough impact on the average in order to change it "instantly". But that exactly is what those buffers are for. We do NOT want a single change to have a too fast influence. The raw data being read from the sensor is full of noise. Its allways going up and down around the "real" value. The size of the averaging buffer for the pressure values is configurable in openxvario. So once you built yourself a device, you can experiment with this setting. It is really quite interesting to set it to real high (e.g. 120) values and experience how this sensor with +-10cm resolution becomes a dead slow but +-1cm presiosion device. The current method of how these 2 buffers are defined is the result of quite a lot of experiments and has yet to be proven to be good in a plane in the air, but i am quite optimistic that it will work.

[jbeebo]

@RightRudder - good post.

There are more than 1 way to filter data, a simple boxed moving average (i.e. FIR filter) is very easy to implement in code. We are dealing with a micro of limited computing power but there are other options like a Kalman filter or other IIR filters which can produce some excellent results.

Because we're dealing with potentially noisy input, but still need accuracy and good response time, if it doesn't work as implemented, I suggest a different digital filtering method. Also, as you pointed out perhaps some clever "analog" filtering of the pneumatic side could help too (e.g. accumulator)

Just a couple thoughts/ideas...

[RightRudder]

@jbeebo
Yes the full scale gliders often have a bottle of some sort usually filled with steel wool to give enough heat capacity to remove temperature effects. It acts as a pneumatic low pass filter on the pressure line going to the vario. This is especially important with a TE probe otherwise your vario needle is going to shake itself to death. To do the kind of signal processing you are talking about is better suited to use a dedicated chip like a dsPIC but this project is on a plain arduino. On the other hand consider a system with a forward facing probe connected to an absolute pressure sensor which measures total pressure. The signal is smooth due to the laminar air stagnating ahead of the pitot. The noise in the system is mainly the inherent quantization noise of the sensor itself. Total pressure is dynamic + static so if you use the data from both sensors you can get dynamic pressure (airspeed) but your TE probe delivers only local pressure at Cp=-1 which is basically negative dynamic. That's your vario signal free of stick thermals. The probes are so noisy because they create huge turbulence and the pressure sense is on the back side of the probe. By measuring total pressure and inverting it you have a clean signal to use instead but the downside is you need two pressure sensors. The majik of the TE probe is it does it all for you right at the probe.

@Rainer
I simplified it in my previous post but basically I used a small buffer compared to a big buffer as well. A FIFO of 4 is 1/4 the noise and if sampling at 10ms it means the 'current reading' is a running 40ms avg. It then compares that to a running average 16x the size or so. I tried different values. I even had a switch so I could change some features in the code while flying like long buffers and tight thresholds vs short buffers and loose thresholds so I could see how it worked while thermalling. However my code calculates all the averages once per sample. I could do this because I hand-bombed all the code in assembler and avoided float math. Every time a new sample is added to the FIFO the first four elements are averaged and the whole 64 are averaged and then the averages are subtracted and compared to the thresholds. This can be done by fast shifting math instructions. I guess there is a fork here as to how much processing happens in the on-board electronics vs in the 9x. Perhaps there is more horsepower for dsp tricks in the 9x but I doubt anyone wants it there. I don't think it needs anything too fancy anyways. What you are doing will probably work well once it's tuned in.

Oh while I'm spouting off I'll just make another comment about TE compensation. Suppose we could make a perfect air mass vario and it didn't have the drawbacks about yaw problems or changes due to wing loading which they always do. Suppose it was perfect. Then you would have information purely about the air you are flying in but not much idea how your glider is doing in general. I agree it is great to be able to remove stick induced beeping from the vario but I think it is valuable to have my current sink rate (as a result of my glider's polar) as part of the information I am having fed to me. If I'm gliding at 200ft and sinking at 100f/m I know that if I don't find some lift I'm going to be on the ground in 2 minutes. If I have my sink alarm set at -120fpm and it stays quiet I have a pretty good idea about what's going to happen. That's valuable info, but a netto vario doesn't give me any idea about that because it has all the polar info subracted out and only tells me what the air itself is doing. So IMHO a straight energy compensation gives me more and more valuable info than a netto. I'll get off my soap box now. ;^>

[RightRudder]

@jbeebo
Yes the full scale gliders often have a bottle of some sort usually filled with steel wool to give enough heat capacity to remove temperature effects. It acts as a pneumatic low pass filter on the pressure line going to the vario. This is especially important with a TE probe otherwise your vario needle is going to shake itself to death. To do the kind of signal processing you are talking about is better suited to use a dedicated chip like a dsPIC but this project is on a plain arduino. On the other hand consider a system with a forward facing probe connected to an absolute pressure sensor which measures total pressure. The signal is smooth due to the laminar air stagnating ahead of the pitot. The noise in the system is mainly the inherent quantization noise of the sensor itself. Total pressure is dynamic + static so if you use the data from both sensors you can get dynamic pressure (airspeed) but your TE probe delivers only local pressure at Cp=-1 which is basically negative dynamic. That's your vario signal free of stick thermals. The probes are so noisy because they create huge turbulence and the pressure sense is on the back side of the probe. By measuring total pressure and inverting it you have a clean signal to use instead but the downside is you need two pressure sensors. The majik of the TE probe is it does it all for you right at the probe.

@Rainer
I simplified it in my previous post but basically I used a small buffer compared to a big buffer as well. A FIFO of 4 is 1/4 the noise and if sampling at 10ms it means the 'current reading' is a running 40ms avg. It then compares that to a running average 16x the size or so. I tried different values. I even had a switch so I could change some features in the code while flying like long buffers and tight thresholds vs short buffers and loose thresholds so I could see how it worked while thermalling. However my code calculates all the averages once per sample. I could do this because I hand-bombed all the code in assembler and avoided float math. Every time a new sample is added to the FIFO the first four elements are averaged and the whole 64 are averaged and then the averages are subtracted and compared to the thresholds. This can be done by fast shifting math instructions. I guess there is a fork here as to how much processing happens in the on-board electronics vs in the 9x. Perhaps there is more horsepower for dsp tricks in the 9x but I doubt anyone wants it there. I don't think it needs anything too fancy anyways. What you are doing will probably work well once it's tuned in.

Oh while I'm spouting off I'll just make another comment about TE compensation. Suppose we could make a perfect air mass vario and it didn't have the drawbacks about yaw problems or changes due to wing loading which they always do. Suppose it was perfect. Then you would have information purely about the air you are flying in but not much idea how your glider is doing in general. I agree it is great to be able to remove stick induced beeping from the vario but I think it is valuable to have my current sink rate (as a result of my glider's polar) as part of the information I am having fed to me. If I'm gliding at 200ft and sinking at 100f/m I know that if I don't find some lift I'm going to be on the ground in 2 minutes. If I have my sink alarm set at -120fpm and it stays quiet I have a pretty good idea about what's going to happen. That's valuable info, but a netto vario doesn't give me any idea about that because it has all the polar info subracted out and only tells me what the air itself is doing. So IMHO a straight energy compensation gives me more and more valuable info than a netto. I'll get off my soap box now. ;^>

[jbeebo]

@RightRudder - good discussion. Agreed a pitot would be a better option and math can do the rest. Yes, a dsp chip is much better suited to Kalman filters and complex IIR, but a simple IIR will likely give better performance than moving box average with very little computational overhead. Caveat - that is, if it's needed...it seems rainer already has a workable solution for vario, even if not TE or netto vario.

@rainer - dude, nice job! that's a beaut!

[RightRudder]

Hey Rainer

If you are still interested in building yourself a TEK probe here are a couple of awesome references:

http://ntrs.nasa.gov/archive/nasa/casi. ... 020138.pdf

http://ntrs.nasa.gov/archive/nasa/casi. ... 015729.pdf

Joe

[rainer]

Hey Rainer

If you are still interested in building yourself a TEK probe here are a couple of awesome references:

http://ntrs.nasa.gov/archive/nasa/casi. ... 020138.pdf

http://ntrs.nasa.gov/archive/nasa/casi. ... 015729.pdf

Joe

Thanks Joe,
yes i am interested in building one, but this has to wait. i´m currently looking into different filtering technics and want to get the whole vario working as good as possible (with the Hardware as it is right now)
if it works out as planned there might be some nice enhancements in that area next.
And if that is working good ( and we get some better weather as well) i might take the TEK probe as my next project.
rainer.

[rainer]

just to let you know...
the next version is going to have a kalman based filter algorythm. i am currently adjusting it, but it is allready looking quite good. much less noise and still a very good reaction time.
Thanks for the tip with this filtering technique.
Rainer.

[jbeebo]

Rainer - nice! I'm glad I could help in some small way...
Kalman filters are impressive beasts aren't they? I'm looking forward to reading how you've implemented that in code for such a small micro. It would be interesting to see time based traces of the moving average filter vs. Kalman output when exposed to same noise and change in average pressure (e.g. put inside balloon, then pop it).

ABBC3_OFFTOPIC

I first ran across Kalman filters when I was working in Detroit (many moons ago) on Anti-lock brake control algorithms. Some people much smarter than I were using it to create a stable vehicle reference speed from noisy wheel speed sensors. We were doing this as we developed ABS and ESC algorithms for 4x4 vehicles in off-road conditions. When all 4 wheels are linked together and then exposed to severe accelerations, it makes finding the average speed quite difficult. Kalman filter was basically the only one that had a hope of working in that control system.

Military also uses them for missile guidance systems, which need pretty special control algorithms for such short time constants of basically dynamically unstable machines.

[RightRudder]

Hi Rainer

When you get to that, if the Kalman filter routines are too slow as compiled in C let me know, I have some fast kalman code in assembler. It is written for PIC16 devices but could be adapted pretty easily.

Joe

[rainer]

No speed problems so far... this little arduino is quite fast for its small size. The slowest part in the system is actually the sensor. it requires around 10ms to read pressure and temperature.
I'm getting good results allready from the new kalman filter routines. Really a fascinating piece of algo....
I found out that the 3.3v version of the MS5611 sensor i am using on my breadboard for development is having a problem with the supply voltagte. The problems occurs allways when i open the serial monitor or any other serial connection to my PC. As soon as the connection is established, there is 2-3x the noise compared to before... i had to add a small capacitor to the 3.3v output in order to compensate at least a little bit.
The 5V prototype i am using as well does not have that problem at all, so it might be the 3.3v source in the arduino nano...
as soon as i got the kalman tuned and decide for some default parameters, i´ll post some processing screenshots of the actual output comparison raw against filtered altitude..
rainer

[rainer]

OK, as promised, here is some actual data of the new filter algorythm. This is about 1 minute data with a maximum altitude change of 2Meter ( at my desk, not in the sky...)
The grey noisy part is raw sensor data ( whith mor noise than normal because of the earlier mentioned problems with my 3.3V MS5611.. The white line is the data from the kulman filter (parameters: q=0,04 r=50)




as you can see from the image there is still a clearly visible lag between raw data change and the kulman data, but what i like about this filter is that still, the change of direction in vertical speed is almost instant. Just if you stop at a certain altitude without further movements, it takes some time for the filtered data to stabilize again.
I am currently thinking about implementing a way of actually adjusting the response time via a RC channel. We could configure one of out pot´s to send a signal and change one of the filter parameters ( Process noise) based on that input i think this shouldn´t be to difficult to implement. The servo channel in most cases would be occupied by the vario in order to provide 5v to it. it could be implemented as another configuration value if you want this or not.

===> What do you think about the idea of being able to control the sensitivity of the vario via your transmitter? Is there a need for something like that?

turning the knob in one direction would increase the response speed of the vario for the cost of more noise.
turning the knob in the other direction would increase the stability of the vario, reduce the noise for the cost of a slower reaction time.

As an alternative we could add a small potentiometer to the vario to fine tune it manually with a small screwdriver.
rainer.

[Flaps 30]

I wouldn't like to use a channel to control the sensitivity, as they are already taken up (apart from one) with other things.

On my full size vario (Renschler SOL 17) I find that it does the job with enough delay to stop it giving false readings.. So I would tend towards having the response speed set at a low figure (long delay) so that it didn't come up with too many false indications of lift. My vote would be for it to be set in software and not have yet more things to twiddle with on the flying field.

[Rob Thomson]

My feeling is that considering how simple this is to hold... Just a firmware parameter you can tweak would suffice?

Sent from my Nexus 7 using Tapatalk 2

[RightRudder]

MY two cents

I think it would be something I would adjust once so if I could adjust via a pot while flying it would be ideal if after flying I could press a button on the arduino and have the value stored to NV memory so the radio channel could then be free for something else.

Great work on the code Rainer. I saw Locutus on the RCgroups cross posted to here. There is a lot of interest for this.

Thanks for all your work
Joe

[Rob Thomson]

I guess my point in this is... The KISS rule.

KEEP IT SIMPLE SILLY

maybe what is needed is two versions of this project.

Simple, and advanced?

What appeals to me is simplicity. The more components we add, the more, expense, and the more work required to make one. The result... No longer easy for end users to make!

A split into two sub projects may help?

Sent from my GT-I9300 using Tapatalk 2

[rainer]

i allways like the keep it simple Idea...
So if we add something like that, it would be configurable in the software. under normal circumstances the project runs out of the box. no additional Hardware required.
But if you like to play a little more with the options... enable something here or there and add a switch there and tweak it a bit... if you don´t want to play, it should work as good as possible out of the (non existing) box.
Like the analog output option... if you don´t want it... don't build it. if you want/need it... add it by enabling one define in the code and start playing. i kept that part of the wiki seperated for a reason... the main build instructions should not be too complicated if 95% won´t need that option anyway.
When you guys receive your sensors and arduinos we might want to split this thread to have a built thread and another one as the development thread. Most people are probably not interested in to deep insights of how a filter works in the background

[ReSt]

Yes, keep it simple,
but don't throw away the possibilities, that already exist.

Reinhard