Variometer quality check

[Tempo]

Let´s compare openXvariometer with other variometers like FrSky-FVAS-02H, wstech, ...
Make "stairways-test" and analyse data.
I will give you an example with openXvario_rev220 and wstech-datavario.


Definitions:

vertical speed = vs
= unit is meter per seconds

vertical speed noise = vs_n
= variometer rests on solid footing

altitude drift = a_d
= slowly shifts and gives nearly constant small shift in vertical speed

vertical speed reaction time = vs_rt
= transition time between state of constant vertical speed and state of zero vertical speed. States change abruptly.

[mstrens]

Let´s compare openXvariometer with other variometers like FrSky-FVAS-02H, wstech, ...
Make "stairways-test" and analyse data.
I will give you an example with openXvario_rev220 and wstech-datavario.


Definitions:

vertical speed = vs
= unit is meter per seconds

vertical speed noise = vs_n
= variometer rests on solid footing

altitude drift = a_d
= slowly shifts and gives nearly constant small shift in vertical speed

vertical speed reaction time = vs_rt
= transition time between state of constant vertical speed and state of zero vertical speed. States change abruptly.

It is for sure good to compare several vario
I did already the test between OXS and Frsky. I had no other vario to test.
For Frsky, it is important to use the new firmware because then the vario is much better.
Still in the comparison, there is a parameter that has a very impact.
In OXS you can change the sensitivity. When you increase sensitivity, you increase vertical speed noise and reduce vertical speed reaction time and the opposite. So to really compare, you have to test with different sensitivities.
I think that a value 50 is a good starting point.
Note: in OXS you can also partly reduce the noise without loosing in reaction time if you change the hysteresis.
Finally in OXS you can apply a dynamic sensitivity if you want (sensitivity is automatically adapted based on Vspeed). You can experiment with those different parameters.

[Tempo]

==========================================================
summary:

openXsensor_r220 (default values in oxs_config.h)
vertical speed noise about +-0,07m/s
reaction time about 1s
altitude drift about +0,01m/s

wstech_linkvario
vertical speed noise about +-0,04m/s
reaction time about 5s
=========================================================

openXsensor_r220
default values in oxs_config.h
#define VARIO // set as comment if there is no vario

#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
#define VSPEED_MIN 20
#define VSPEED_MAX 100

#define PPM_RANGE_MIN 981
#define PPM_RANGE_MAX 1999
#define SENSITIVITY_PPM_MIN 20
#define SENSITIVITY_PPM_MAX 100

#define VARIOHYSTERESIS 5

#define OutputClimbRateMin -3
#define OutputClimbRateMax 3

wstech_linkvario

[ReSt]

The following is from openXvario r204 with Kalman_R=150
For both recordings I went the same course, but the first one with the vario freshly powered on and the second one with the vario powered on for half an hour
The first one has the altitude drift of about 2,45 m for 130 seconds while the second one has nearly no drift.

Reinhard

[mstrens]

The following is from openXvario r204 with Kalman_R=150
For both recordings I went the same course, but the first one with the vario freshly powered on and the second one with the vario powered on for half an hour
The first one has the altitude drift of about 2,45 m for 130 seconds while the second one has nearly no drift.

Reinhard

VARDRIFT.JPG

When OXS start reading the sensor MS5611, its internal temperature increases (about 5 degree) up to reaching a stable level.
This explain the drift.
It seems that the internal temperature compensation is not 100% correct for this sensor.
It will be the same issue for all vario's using this sensor.

[Tempo]

MS5611 temperature drift is not a real problem, because drift in altitude causes constant vertical speed about 1/10 smaller than vertical speed noise of sensor.
You can see it on picture above as small and constant shift of zero point in vertical speed.
It´s insignificant for climbrates.

[mstrens]

MS5611 temperature drift is not a real problem, because drift in altitude causes constant vertical speed about 1/10 smaller than vertical speed noise of sensor.
You can see it on picture above as small and constant shift of zero point in vertical speed.
It´s insignificant for climbrates.

The drift is not an issue when you just want to calculate the vertical speed.
Still the drift is an issue if:
- you look at the altitude (the drift can be several meters)
- you would like to measure also the airspeed using 2 MS5611. If one measure the static pressure and the other the pressure provided by a TEK probe, you could in theory calculate the airspeed but the drift is an issue when it is not the same on the 2 MS5611.

[Tempo]

@mstrens
Yes, you are right.
But this topic is Variometer quality check.

Remeber also, change of atmospheric pressure during flight is more important than temperature drift of sensor.
In this case better use GPS for altitude measurement.
Measurement of airspeed with two different drifting MS5611 is not a good idea.

[Kilrah]

In this case better use GPS for altitude measurement.

Not really, over the duration of a flight where pressure makes the altitude drift by 3m GPS alt will likely have moved by 60 due to satellite alignment changes. GPS alt is very imprecise.

The temperature drift at startup has been widely confirmed over multiple units.

Sent via mobile

[Tempo]

GPS altitude accuracy:
http://gpsinformation.net/main/altitude.htm

[ReSt]

I ran the variometer twice (with several hours between the two runs) on a fixed position (depending on the air pressure at an altitude of around 320m) for 49 minutes, recording the altitude.
The display shows the drift of altitude over the time and is about 8 meters on the left and about 13 meters on the right curve

Couldnt it be possible to at least partially, compensate the drift ?

I will try to send and log the temperature (T1) and check if that drifts in a similar way.

Reinhard

[mstrens]

I ran the variometer twice (with several hours between the two runs) on a fixed position (depending on the air pressure at an altitude of around 320m) for 49 minutes, recording the altitude.
The display shows the drift of altitude over the time and is about 8 meters on the left and about 13 meters on the right curve

Couldnt it be possible to at least partially, compensate the drift ?

I will try to send and log the temperature (T1) and check if that drifts in a similar way.

Reinhard

VARDRIFT.JPG

I think that drift result from at least 2 factors:
- change from the atmospheric pressure (over a long run): It is very usual having a change of 1 hectopascal over 3 hours and this result in a change of about 9 meter.
- drift of the temperature of the sensor. Please note that it is very important to take care of the internal temperature of the sensor and not the temperature of the air. There is normally a difference of about 5 degree between both (the sensor being hotter). In therory, each sensor has been calibrated in factory in order to provide some parameters that allows to compensate the temperature. OXS uses already those parameters. Still it seems that those parameters are not 100% valid. Perhaps that we just expect too much from the sensor. Perhaps, that the parameters are optimized for a large range of temperature and so not optimal for the "normal" temperature.
In principe, it should be possible to use a second level of compensation inside OXS but it has to be experiment and it would probably requires some quite complex calibration that would be different for each device.

Note: if you want I can deliver a version of OXS that transmits the internal temperature from the sensor to the TX.
The information is already available; I just have to send it. This would make experimentation possible.

[ReSt]

I just got the temperature drift curve and it looks very similar to the altitude drift curves.
It started with 24.4 degree and ended up at 32.2 after about 50 minutes.

So I assume, it should be possible to adapt the temperatur compensation a little bit better (but to be honest, I don't know how )

btw, I'm still using openXvario, as it does anything I need

Reinhard

TempDrift.JPG (15.72 KiB) Viewed 9537 times

[mstrens]

I just got the temperature drift curve and it looks very similar to the altitude drift curves.
It started with 24.4 degree and ended up at 32.2 after about 50 minutes.

So I assume, it should be possible to adapt the temperatur compensation a little bit better (but to be honest, I don't know how )

btw, I'm still using openXvario, as it does anything I need

Reinhard

TempDrift.JPG

I had a similar result some months ago when I worked on the code.
To implement a compensation, the first point is to know which value to apply depending on the sensor temperature.
To know it, it should be possible let the temperature of the sensor varying while the pressure remain the same.
Measuring altitude and temperature would allow to find a curve that could be modelised in the program for some range of temperature. This range must not be so wide. From 0 to 40 degree should be enough.
This could be done e.g. moving the sensor from the fridge to a "hot" location.

It would be fine if this can be done with several device in order to see if it is the same or if it has to calibrated per device.
I am afraid that it would be the second case because someone already run a test with 2 MS5611 on the same Arduino and the drift was not the same (even if it goes always in the direction).

If you make the test, and provide the result, I can try to add some compensation in the code.
If you make the test, best would be to make several cycles where temperature goes up and down to see if the altitude error is always the same for the same sensor temperature.
Making the test request probably to move the sensor from one location to another. That will generate short altitude variations during the movement and those have to be discarded.
If you put the sensor in fridge, let the door a little open (to be sure that the pressure is ok

I hope this is clear enough.Otherwise I can try explain more.

[jhsa]

You just need to open the door every litle while for the pressure to equalize, and the food won't go bad

[Tempo]

@mstrens
I own wstech-data-vario and openXsensor, but no FrSky-FVAS-02H.
Comparison openXsensor_r220 and FrSky-FVAS-02H see there:
http://fpv-community.de/showthread.php? ... post653372

====================================
FrSky Variometer FVAS-02H (Softwareversion VARIO2_140124.frk; V1.1)
vertical speed noise about +-0,075m/s
reaction time about 3s
altitude drift about -0,01m/s
====================================

Width of noise is comparable, but intensity of noise is much less for openXsensor algoritms.
Do you confirm ? How sounds openXsensor compared with FrSky-FVAS-02H ?

[mstrens]

@mstrens
I own wstech-data-vario and openXsensor, but no FrSky-FVAS-02H.
Comparison openXsensor_r220 and FrSky-FVAS-02H see there:
http://fpv-community.de/showthread.php? ... post653372

====================================
FrSky Variometer FVAS-02H (Softwareversion VARIO2_140124.frk; V1.1)
vertical speed noise about +-0,075m/s
reaction time about 3s
altitude drift about -0,01m/s
====================================

Width of noise is comparable, but intensity of noise is much less for openXsensor algoritms.
Do you confirm ? How sounds openXsensor compared with FrSky-FVAS-02H ?

Sorry but I do not understand german and the google traduction from the link you provided is very bad.
So if you really want, I can try to better understand but currently I did not.

I generally agree with what you say about comparing OXS and FRSKY but you are just comparing with the default parameters from OXS.
If you change some OXS parameters you could get quite different results.

First over the noise:
OXS has a special feature that I named "hysteresis".
OXS calculate about 50 X per sec the altitude and the vertical speed.
Imagine that value "x" is ready to be sent.
In the background OXS will continue calculating new values.
As long as the new calculated Vspeed remains in a range (x - hysteresis) and (x + hysteresis), OXS will continue to send the value x.
So the Tx will have always the same value (and noise will be 0).
It is only when a new value (say y) is out of range that OXS will send y.
Increasing hysteresis allows to reduce the noise.
Default value is 5 (cm/sec) and I think it could easibly be increase without loosing "feeling" when using the vario tone.

A second and probably the most important parameter is the sensitivity.
When sensitivity is 20, it means that each new pressure read from MS5611 will only be integrated in the calculation for 20/1000 from the difference with the previous calculated value (= exponential smoothing = some kind of filtering to reduce noise).
As the sensor is read 50 x a sec, a full "step" variation will take some time to see the full effect (= reaction time).
When sensitivity is set on say 100, the calculation will integrate 100/1000 and so the reaction will be 5 time less.
So playing on sensitivity, you act at the same time on reaction time but also on the noise.
I think that if you try a sensitivity of 20 (instead of the default 50), you will get a response time smaller and a noise level smaller then those from the other sensors.

Please note that I am not sure at all that the default values that I put in the config file on google are the best one.
I even think that it makes sense to change the sensitivity depending on the size of the glider and on the weather .(calm/turbulent).

One of the advantage of OXS is that you can change the sensitivity from the TX during the flight if you want.

There is a third parameter in OXS that you can use. I am not sure if it is really helpfull but it exists.
The principle is the following.
When Vspeed is around zero, you would probably want to avoid false tone. So sensitivity would be set on a say low value.
Having a low value increases the reaction time.
When Vspeed increase a lot it could take more time to reflect the change (and in this case having more "noise" is not a big drawback)
OXS can automatically change the sensitivity based on the Vspeed.
Therefore you can define a range of value for Vspeed and their corresponding sensitivity.
OXS will take care of this.
In the default set up, this functionality is in fact not activated because the min and the max sensitivities are both set on the same values.
If you use this with according values, you will probably reduce the reaction time without increasing the noise around zero.

As you see it it difficult to compare just one parameters.
In general, it is a compromise: decreasing the response time = increasing the noise.

I hope you understand those technical explanations. If not, I can try to explain more.

If you find better values for the default parameters, please let me know, so I can change the config on google.

[Tempo]

...
Sorry but I do not understand german and the google traduction from the link you provided is very bad.
So if you really want, I can try to better understand but currently I did not.
...

Yes, this is with german text, but I mean diagrams universal speach

Your remarks above are as excellent as your implementation of variometer in openXsensor.
I will test parameter options step for step and will give you feedback in practical thermal hunting.