Can someone explain the formula & inputs Companian uses to calculate vertical speed?
I have been using a FrSky precision vario to record altitude data on my Taranis to try and establish descent rates for various control settings.
The data is then analysed in Companian.
To establish the descent rate I have been taking the average gradient of the Baro readings over say 2minutes.
Baro readings frequency is 1 second.
However, the Companian software also displays Verticle speed in the data file, but it does not agree with my values calcluated from Baro graphs.
It does seem to agree whether I am climbing or descending, but not the values!
I have tried various manipulation of my Baro data to get the Companian vertical speed without success!
Can someone explain it & what I am doing wrong!!
Companian vertical speed calculation derivation

 Posts: 6
 Joined: Tue Nov 17, 2015 12:28 pm
 Country: 
Re: Companian vertical speed calculation derivation
It doesn't calculate anything, the vertical speed value is sent by the sensor and jsut displayed as is.

 Posts: 6
 Joined: Tue Nov 17, 2015 12:28 pm
 Country: 
Re: Companian vertical speed calculation derivation
Ok thanks, but then the question is how is the sensor calculating vertical speed?
The sensor only knows atmospheric pressure (baro) at some time interval unless it has an accelerometer in it.
I have analysed some data from a glider descent and a climb using excel & linear trendlines to see if I can establish the data processing involved.
Obviously the glider data is not linear, but I think the results are reasonable.
Baro altitude is given in FEET, but Vertical Speed units are not defined.
It appears that Vertical Speed is METERS PER SECOND.
See data on the 2 sheets of the attached Excel. The first sheet just compares a descent gradient of the Baro altitude in feet with the mean VERTICAL VELOCITY in undefined units.
The result is 1.49m/s vs 1.42
The second sheet shows the same analysis for a climb.
The result is 6.28m/s vs 5.56
Further, the vertical speed from the Vario appears to vary quite a lot.
It is difficult to know if the glider is really moving around that much!
However, I wanted to see if the Vertical Speed graph could replicated from the Baro data.
On the second sheet I also calculated & plotted vertical speed between each data point from the Baro data converted to m/s.
The shape of the curve is very similar to the Vertical Speed data, but larger flucuations.
In an attempt to smooth the curve I then calculated vertical speed using 1st and third Baro data points (like a running average)
This last curve agrees quite well with the original Vertical Speed from the vario.
Not identical, but then I do not know how the baro data is used in the vario.
So, in conclusion I have learnt :
The vertical speed comes from the vario (not Companian)
Baro altitude is in feet, whereas Vertical Speed appears be in meters.
Perhaps some units could be added to the vertical speed column in Companian.
Can anyone confirm my findings?
The sensor only knows atmospheric pressure (baro) at some time interval unless it has an accelerometer in it.
I have analysed some data from a glider descent and a climb using excel & linear trendlines to see if I can establish the data processing involved.
Obviously the glider data is not linear, but I think the results are reasonable.
Baro altitude is given in FEET, but Vertical Speed units are not defined.
It appears that Vertical Speed is METERS PER SECOND.
See data on the 2 sheets of the attached Excel. The first sheet just compares a descent gradient of the Baro altitude in feet with the mean VERTICAL VELOCITY in undefined units.
The result is 1.49m/s vs 1.42
The second sheet shows the same analysis for a climb.
The result is 6.28m/s vs 5.56
Further, the vertical speed from the Vario appears to vary quite a lot.
It is difficult to know if the glider is really moving around that much!
However, I wanted to see if the Vertical Speed graph could replicated from the Baro data.
On the second sheet I also calculated & plotted vertical speed between each data point from the Baro data converted to m/s.
The shape of the curve is very similar to the Vertical Speed data, but larger flucuations.
In an attempt to smooth the curve I then calculated vertical speed using 1st and third Baro data points (like a running average)
This last curve agrees quite well with the original Vertical Speed from the vario.
Not identical, but then I do not know how the baro data is used in the vario.
So, in conclusion I have learnt :
The vertical speed comes from the vario (not Companian)
Baro altitude is in feet, whereas Vertical Speed appears be in meters.
Perhaps some units could be added to the vertical speed column in Companian.
Can anyone confirm my findings?
Re: Companian vertical speed calculation derivation
If you specified the version of OpenTX you're using I could help.
On 2.1 you specify the units, on 2.0 it might be logged as it comes from the sensor.
On 2.1 you specify the units, on 2.0 it might be logged as it comes from the sensor.
Re: Companian vertical speed calculation derivation
I do not know how Frsky performs Vspeed calculations.
I can shortly explain how openXsensor does it.
It uses a baro sensor that provide the athmospheric pressure.
This pressure can be converted in altitude based on some formula's.
It is important to notice that the values provided by the baro sensor are quite noisy.
So, in order to get the best from it, it is important to read the sensor as fast as possible and then to apply some filters on the received data.
openXsensor reads the sensor 50 times a second, converts each data in pressure and altitude.
It uses 2 differens filters in order to calculate the altitude being send to the Tx on one side and the Vspeed send to the Tx on the other side.
For altitude, it uses a simple smoothing filter.
new altitude = previous altitude + 0.04 * ( last altitude from sensor  previous altitude).
So it means that at each iteration, it adds 4% of the difference between last altitude from sensor and previous altitude.
So the calculated altitude follows "slowly" the altitude provided by the sensor.
For the vertical speed, openXsensor first calculates 2 altitudes using different smoothing parameter:
altitudeLowPass += 0.085 * ( last altitude from sensor  altitudeLowPass) ;
altitudeHighPass += 0.1 * ( last altitude from sensor  altitudeHighPass) ;
So one altitude is "moving" faster then the other.
OpenXsensor calculates then a vertical speed making the difference between the 2 altitudes and applying a scaling parameter taking into account the difference of the 2 filter parameters and the delay between 2 iterations.
climbRate2AltFloat = ((altitudeHighPass  altitudeLowPass ) * 5666.685 ) / 20000 ;
This calculated vspeed is still too noisy to be used.
So openXsensor applies again a smoothing filter on this climbRate2AltFloat and this gives the Vspeed being send to Tx.
So uou can note that:
 all data are provided by the baro sensor
 all calculations are done as fast as possible in openXsensor (and not in the Tx) (50X times per second)
 different filters are applied in order to reduce the noise present in the raw data from the baro sensor
 the filters are not the same for altitude and for Vspeed because the expected reaction times are not the same (Vspeed must react faster)
This explains why Vspeed is not directly calculaled by a formula like
(new altitude from baro  previous altitude from baro ) / enlapsed time between 2 baro reads.
Please note also that when you perform calculation on Tx side based on a log file, there are some delays in the transmission and in the logging process. So you could not exactly find back the values calculated on Rx side.
I can shortly explain how openXsensor does it.
It uses a baro sensor that provide the athmospheric pressure.
This pressure can be converted in altitude based on some formula's.
It is important to notice that the values provided by the baro sensor are quite noisy.
So, in order to get the best from it, it is important to read the sensor as fast as possible and then to apply some filters on the received data.
openXsensor reads the sensor 50 times a second, converts each data in pressure and altitude.
It uses 2 differens filters in order to calculate the altitude being send to the Tx on one side and the Vspeed send to the Tx on the other side.
For altitude, it uses a simple smoothing filter.
new altitude = previous altitude + 0.04 * ( last altitude from sensor  previous altitude).
So it means that at each iteration, it adds 4% of the difference between last altitude from sensor and previous altitude.
So the calculated altitude follows "slowly" the altitude provided by the sensor.
For the vertical speed, openXsensor first calculates 2 altitudes using different smoothing parameter:
altitudeLowPass += 0.085 * ( last altitude from sensor  altitudeLowPass) ;
altitudeHighPass += 0.1 * ( last altitude from sensor  altitudeHighPass) ;
So one altitude is "moving" faster then the other.
OpenXsensor calculates then a vertical speed making the difference between the 2 altitudes and applying a scaling parameter taking into account the difference of the 2 filter parameters and the delay between 2 iterations.
climbRate2AltFloat = ((altitudeHighPass  altitudeLowPass ) * 5666.685 ) / 20000 ;
This calculated vspeed is still too noisy to be used.
So openXsensor applies again a smoothing filter on this climbRate2AltFloat and this gives the Vspeed being send to Tx.
So uou can note that:
 all data are provided by the baro sensor
 all calculations are done as fast as possible in openXsensor (and not in the Tx) (50X times per second)
 different filters are applied in order to reduce the noise present in the raw data from the baro sensor
 the filters are not the same for altitude and for Vspeed because the expected reaction times are not the same (Vspeed must react faster)
This explains why Vspeed is not directly calculaled by a formula like
(new altitude from baro  previous altitude from baro ) / enlapsed time between 2 baro reads.
Please note also that when you perform calculation on Tx side based on a log file, there are some delays in the transmission and in the logging process. So you could not exactly find back the values calculated on Rx side.
Re: Companian vertical speed calculation derivation
This is in my point of view the main purpose of VSpeed. Indeed it is a little miracle, how a pressure sensor and the calculations are able to generate a useful signal, that allows to find and center thermals. But this signal is not useful for measurements. Here is an example of a measurement flight early in the morning in dead air. Altitude is a straight and VSpeed is still noisy.Matchless55 wrote:It does seem to agree whether I am climbing or descending, but not the values!
If you want to know the average sink of your plane, use altitude loss and elapsed time in a constant flight phase and you will get precise numbers. Link
OpenXSensor vertical speed calculation
The difference is 0.1  0.085 = 0.015mstrens wrote: ↑Mon Nov 21, 2016 8:52 pmaltitudeLowPass += 0.085 * ( last altitude from sensor  altitudeLowPass) ;
altitudeHighPass += 0.1 * ( last altitude from sensor  altitudeHighPass) ;
OpenXsensor calculates then a vertical speed making the difference between the 2 altitudes and applying a scaling parameter taking into account the difference of the 2 filter parameters and the delay between 2 iterations.
climbRate2AltFloat = ((altitudeHighPass  altitudeLowPass ) * 5666.685 ) / 20000 ;
1 / 0.015 = 66.666...
so why 5666.985 and not 6666.667 as factor?