New beta version of openXsensor (=openXvario)

Development & General Chat for the superb openxvario project.

Moderator: rainer

Post Reply
mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

New beta version of openXsensor (=openXvario)

Post by mstrens » Wed Aug 27, 2014 11:08 am

A new (beta) version of openXsensor is available for testing (see attachment).

Here the main changes made in this version:
- all the explanations contained in the oxs_config.h file have moved to a new file named oxs_config_description.h
- so the oxs_config.h contains only the set up and is much shorter (and easy to write).
- in this oxs_config.h, all parameters related to an option can be omitted (or commented using "//) when not used. E.g. it is not required any more to set the pin to a dummy value "8" to declare that a voltage does not have to be measured.
- The names used to specify in which telemetry field an OXS measurement has to be sent are now the names used by openTx in the telemetry panel (e.g. for the altitude, the name is "Alt"). Therefore there is no need any more to change the name depending of the type of receiver being used.
- The names of all other parameters have been put in upper case (for standardisation)
- OXS can now support a second baro sensor MS5611. One can measure, as usual, the altitude and the uncompensated vertical speed, the other can be a (pneumatically) compensated vario if connected to a TEK probe. See those links to know more about TEK probe.
viewtopic.php?f=48&t=5632&hilit=TEK&start=60
viewtopic.php?f=86&t=5856
It is possible to switch from compensated vario to uncompensated vario using a switch on the Tx. This requires to use the OXS PPM option (where OXS read a channel from the receiver)
- OXS can now provide the airspeed (min 10 km/h, max = 360 km/h) when adding a sensor 4525DO-DS5AI001DP. This sensor connects in parallel with the MS5611 sensor(s) using 4 wires.
It requires to use a Prandtl probe (often wrongly named a Pitot probe) to collect the static and the dynamic pressure.
Such a probe can be e.g. found at Eagletree or can easily be build (e.g. using parts of an old Tx 35mhz antenna).
- when both 4525D0 and MS5611 sensors are used, OXS can also calculate "Prandtl_dTE" (= delta Total Energy based on Prandtl probe) providing an (electronically) compensated vario without a TEK probe. Please note that it seems quite difficult to get full accurate and stable measurements (and more at low airspeed).
- there are new parameters about PPM in order to control from the Tx, on top of the vario sensitivity, the compensation factor for the electronic vario, the reset of airspeed, the selection of the vario source (useful here because not yet possible inside openTx).
- this version have 3 predefined fields (TEST1, TES2, TEST3) that can be transmitted to Tx with whatever you want. This can be useful to develop you own version (e.g. sending the MS5611 temperature).

Read the oxs_config_description.h file for more details.
When the version will be stable, the configurator and the openXsensor google site will be adapted accordingly.

There are quite many changes in this version and it is difficult to test all of them.
That is the reason why I do not put this version directly on google site.
So do not hesitate to communicate issues that you could get.

I would also appreciate getting your feeling about the new measurements: airspeed and Prandtl_dTE.
I spend a lot of time trying to get the Prandtl_dTE measurement as good as possible but I am not sure that the result is really good enough.
If somebody has a proposal in order to improve this, please let me know.
Attachments
openxsensor_2014_08_27_V0.rar
(65.49 KiB) Downloaded 106 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Wed Aug 27, 2014 4:28 pm

Hello Michel,

thank you for this one, here is a logfile with a flight from this afternoon with a lot of thermals (surprisingly), i used the version from yesterday, you sent me with pm. The vario compensation with airspeed works, but the resulution is worse then the TEK with great jumps. Centering the thermal is easier with the TEK. Maybe there is an option to reduce the averaging when calculating the compensation?
Stratos_E-2014-08-27.zip
(355.93 KiB) Downloaded 48 times

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Wed Aug 27, 2014 8:31 pm

Carbo wrote:Hello Michel,

thank you for this one, here is a logfile with a flight from this afternoon with a lot of thermals (surprisingly), i used the version from yesterday, you sent me with pm. The vario compensation with airspeed works, but the resulution is worse then the TEK with great jumps. Centering the thermal is easier with the TEK. Maybe there is an option to reduce the averaging when calculating the compensation?
The attachment Stratos_E-2014-08-27.zip is no longer available
Thanks for the log file.
This help me finding a bug that explains (at least partly) why dTE was worse then TEK.
I also now calculate a dTE even if airspeed is low (and not accurate). So, dTE will be equal to vertical speed when airspeed is less than about 10 km/h.

I suggest that you test again with this version.
If, as I expect, dTE is still to noisy (compare to TEK), I suggest that you further test with a lower sensitivity only for the dTE. This can be achieve changing this line in the config file
There is currently
#define COMPENSATIONMILLIS 500
You could try with
#define COMPENSATIONMILLIS 1000.
Then dte will be calculated once per sec instead of once per 0.5 sec. There should be less peaks.
Attachments
openxsensor_2014_08_27_V1.rar
(65.5 KiB) Downloaded 44 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Thu Aug 28, 2014 3:20 pm

Hello Michel,

here is my afterworkflight with 2014_08_27V1:
Stratos_E-2014-08-28.zip
(340.12 KiB) Downloaded 43 times
I decided to land after a few minutes to record the vario-sound, because it is difficult to describe. The dte sound has a worse resolition, the TEK sound is more sliding. Here is a 4 min excerpt with some switching between dte and tek:
Variosound.mp3
(1.97 MiB) Downloaded 77 times
A loop was nearly perfect compensated. The feeling for the air is still better with tek. But when you find the reason for the steps in dte, it is easier to compare the two compensations and to work with the sensitivity. Saturday seems to bring good thermals :-)

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Fri Aug 29, 2014 9:56 am

@Carbo,
I continue to analyse the logs.
Here your last one with some charts.

In all your logs, I see that there are oscillations (up and down values for altitude and airspeed) about every 10 sec.
Do you have any idea of the origin of those oscillations?

Looking at the log, I see that:
- the "fast" uncompensated Vspeed (in log field Temp1) used to calculate dTE varies like the original uncompensated Vspeed (in accx). It is not to noisy and it seems that it just reacts a little faster. So I presume it is not bad.
- dTE has the same trend than TEK but is still more noisy. This is mainly the result of the noise in the calculated airspeed compensation.
- it is strange for me to see that dTE and TEK compensate in very similar way but that sometime it is perfectly compensated and sometime nearly not (e.g. at 16h43)
- dTE becomes really bad just before landing (perhaps because airspeed goes down and error and noisy increase)
- I am not sure if the worse sound for dte is the reult of a more noisy dte of of the fact that it changes only once per 500 msec. Perhaps a test with an interval of 500 msec could help to clarify this. Still I presume that the reason is more the noisy signal.
- in order to get a less noisy airspeed compensation, Ican try to increase smoothing on the original 4525D0 pressure signal (like in the version of begin august) or add a smoothing on the calculated dTE.
Attachments
Stratos_E-2014-08-28.xlsx
(5.07 MiB) Downloaded 51 times


Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Fri Aug 29, 2014 10:41 am

Hello Michel,

the oscilations are plane specific. I tried moving cg back, far behind recommended place, until i nearly lost the plane. Changed also angle of attack, but the oscillations did not reduce. The performance is really good, so i accepted it.

The main problem for me is not a noisy dTE, but the coarse resolution. I remember a flight with a frsky vario, and also a post of a pilot in a german forum, who had the same observation of a suddenly very steppy variosound - both not with oxs. So is there a possibility, that opentx switches its behaviour regarding the generation of the variosound (maybe bullshit, but i just remembered this). The noisier signal, when landing is really not an issue, i was extremly slow with a stall at the end.

Can you see the coarser resolution of dTE in the logs, is there maybe a multiplier in your calculation, that causes the bigger steps?

Do you recommend a 1000 ms Intervall, you wrote 500 ms twice? Or shall i reduce the intervall, to see (hear) the result?

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Fri Aug 29, 2014 10:49 am

Here is the link to the german forum, i found the post:

http://fpv-community.de/showthread.php? ... post629735

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Fri Aug 29, 2014 3:26 pm

I changed COMPENSATIONMILLIS 500 to COMPENSATIONMILLIS 100 to see what happens, and the effect was a very noisy dTE. Here i magnified 15 sec. of the log with TEK and with dTE, and you can see, that the airspeed is calm, vspeed is calm, dTE is jumping.
P1_TEK.png
15 sec TEK
P2_dTE.png
15 sec dTE
What you see, when you look at the transmitted vertical speed, is what i heard. I hope there is a chance to find the reason for that behaviour.

Here is the complete log (windy, no thermals):
Stratos_E-2014-08-29.zip
(120.29 KiB) Downloaded 33 times
Then i flew the stratos with uncompensated vario, and you hear the 10 sec. oscillations and control them unconsciously. With the compensated vario you hear exactly - nothing - from the oscillations, so there is no chance to correct it. This is another argument, to have the possibility, to switch between compensated and uncompensated vario as it is already possible with the new oxs.

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Fri Aug 29, 2014 8:18 pm

Carbo wrote:
Do you recommend a 1000 ms Intervall, you wrote 500 ms twice? Or shall i reduce the intervall, to see (hear) the result?
Sorry, I forgot to change the second line.
I wanted to suggest to test with 1000ms (so changing 500 by 1000).

I will also look further to morrow to give you other changes to test in order to get a smoother dTE.
In the worst case, I can always put back the algorithm that was used in the version of begin august.

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sat Aug 30, 2014 9:52 am

@carbo,
As said yesterday evening, here another version where:
- I increase a lot the primary smoothing on Airspeed (using lower value for exponential smoothing : 0.001 instead of 0.005)
- I reduce the interval from 500 to 100 msec.
- I added a second level smoothing that is applied on the dte calculated every 100 msec. I set the smoothing factor to 0.1 what means that a jump in DTE would become really 100% effective only 1 sec later (100 / 0.1).

I hope this would already be better (keeping the synchronisation of fast Vspeed and Compensation) and getting less coarse resolution.
Attachments
openxsensor_2014_08_30_V1.rar
(65.52 KiB) Downloaded 30 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 10:29 am

Thank you for the changes, i will test today.

Looking over the logs, i think again about a simpler approach:
The airspeed is reliable, also the vspeed.

Correcting the vspeed with a moving average over the delta airspeed could do it already. Airspeed change is slow, maximum 9.81m/s² as long as you hit nothing :-). VSpeed is the most important information, that should not be delayed.

Time1: Airspeed1, VSpeed1
Time2: Airspeed2, deltaAirspeed1=(Airspeed2-Airspeed1)
Time3: Airspeed3, deltaAirspeed2=(Airspeed3-Airspeed2)
Time4: Airspeed4, deltaAirspeed3=(Airspeed4-Airspeed3), Average_deltaAirspeed4=((dA3+dA2+dA1)/3), VSpeed4, dte=VSpeed4-AveragedeltaAirspeed4
Time5: Airspeed5, deltaAirspeed4=(Airspeed5-Airspeed4), Average_deltaAirspeed5=((dA4+dA3+dA2)/3), VSpeed5, dte=VSpeed5-AveragedeltaAirspeed5
.
.
.

If it is not too much hassle for you, i would really like to try a version with this approach.

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sat Aug 30, 2014 11:22 am

@carbo,
I can make such a version and we will see the result.
What is the interval that you expect between time 1 and time 2, time 2 and time 3, ...
Is it 20 ms (shorter is not possible due to MS5611), 100 ms or 500 ms?

Please note that dte has not to be calculated as Vspeed - AveragedeltaAirspeed but
Vspeed + averagedeltaAirspeed * Airspeed / 9.81.
And deltaAirspeed has to be (Airspeed2 - Airspeed1) / (Time2 - Time1)

Note : the version that I send you this morning aplies greatly a similar logic but instead of calculating a moving average on 3 detaAirspeed, it first calculates a raw dTe and then it apply an exponential smoothing on the rawdte which should be nearly equivalent to a moving average over 6 enlapsed times (but giving also more "weight" to the latest values of dte). This result in a much smoother dte than the one that should be calculated based on your proposal.
- smooth each sensor reading

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sat Aug 30, 2014 12:13 pm

@Carbo,

Please find here a version that allows your to compare 2 logics.
In the file openxsensor.ino there is a line "#define SMOOTH_DTE"
When this line is set as comment (or deleted) , airspeedrate (= airspeeddelta) is smoothed before caluclating dte and dte is not smoothed again. This is like the logic you asked for.
When this line is active, airspeedrate is not smoothed and OXS calculates first a raw dte but smooth it before sending it to Tx. This is how the previous version (V1 from this morning) works.

Important note : in the previous version (V1 from this morning), I made a mistake (type fout) filling the smoothing factor for dte. The version V1 had a value 0.01 instead of the value 0.1 as put in the thread explanation. A value 0.1 seems me better in order to keep a response time around 1 sec.
I fixed this in this version V2. Sorry for this mistake if you already try V1.
Attachments
openxsensor_2014_08_30_V2.rar
(65.64 KiB) Downloaded 38 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 12:25 pm

Stratos_E-2014-08-30.zip
(104.84 KiB) Downloaded 30 times
Here is the V1 log, i can confirm a reaction-time of 10s :-)

To my approach: dTE is not time critical, the calculation can be done, when the data is ready to transmit, in the interval of transmitting. I did my calculations over the total energy: E = m * g * h + 1/2 m * v². Beeing not able to solve this, i made a spreadsheet, where the result was, that i can compensate vspeed with delta airspeed - but: you are the brain, i am the pain.

My delta airspeed calculation is only true in constant intervals, but ........

Will try V2 this afternoon in both ways.

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 1:40 pm

Here is the first flight with 2014_08_30_V2 (unchanged)
Stratos_E-2014-08-30.zip
(398.64 KiB) Downloaded 32 times
It is a realy good one, maybe the best i ever flew. So threating you with my approach worked :-). The conditions were rather rough, one thermal spit me out, as i never experienced before. This one has to be tried in calm conditions, i never missed the TEK, switching over did not noticeably change the behaviour.

Luckily i had the camera running, i will synchronize the vario sound and publish it, maybe in the late evening or tomorrow.

In spite of the success, i will try now the other version with "my" approach.

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 2:46 pm

Here is the log 2014_08_30_V2 with "//#define SMOOTH_DTE" in the second part of the log, i did not delete the first log, so both versions are in this one. Look at the timestamp.
Stratos_E-2014-08-30.zip
(556.82 KiB) Downloaded 33 times
It is similar to prior versions with low resolution and "jumpy" sound, so the unchanged v2 is the one we should focus on. I will do further tests with changing compensation ratio.

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sat Aug 30, 2014 4:34 pm

@Carbo,
I had a look at the logs.
As said, in the first flight the smoothing on dte was to big leading to a wrong reaction time (my mistake).
In the third fligth dte is very very noisy. This is for sure not an option.

In the second flight (see attachment), dte seems to better compensate than TEK during normal flight but does not compensate enough (and less than TEK too) when sinking a lot. Strange: as already seen, both compensate perfectly for high rising. I do not understand why this difference. Perhaps is it related to the position of the probe or to the fact that the speed of the glider saturates when it sink a lot.
Note : the fact that, during normal flight, dte compensates better than TEK could be because there is more smoothing.
You can see that reaction time of dte is slower than TEK (mainly when dte varies a lot).
Probably that if you increase the smoothing on TEK, you will get a better feeling on TEK. If you want to test it, you could change those 2 lines in config.h
Currently it is:
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
You could test with
#define SENSITIVITY_MIN 30
#define SENSITIVITY_MAX 30

On the other side, in order to reduce the reaction time when dte is big, I could replace the fix dte smoothing factor (currently 0.1) by a dynamic one (e.g. using 0.05 when dte changes slowly and up to 0.4 when it changes fast). I need to make a new version for this but it is easy..
Attachments
Stratos_E-2014-08-30.xlsx
(2.31 MiB) Downloaded 39 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 5:25 pm

mstrens wrote:@Carbo,
In the second flight (see attachment), dte seems to better compensate than TEK during normal flight but does not compensate enough (and less than TEK too) when sinking a lot. Strange: as already seen, both compensate perfectly for high rising. I do not understand why this difference. Perhaps is it related to the position of the probe or to the fact that the speed of the glider saturates when it sink a lot.
Note : the fact that, during normal flight, dte compensates better than TEK could be because there is more smoothing.
You can see that reaction time of dte is slower than TEK (mainly when dte varies a lot).
Probably that if you increase the smoothing on TEK, you will get a better feeling on TEK. If you want to test it, you could change those 2 lines in config.h
Currently it is:
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
You could test with
#define SENSITIVITY_MIN 30
#define SENSITIVITY_MAX 30

On the other side, in order to reduce the reaction time when dte is big, I could replace the fix dte smoothing factor (currently 0.1) by a dynamic one (e.g. using 0.05 when dte changes slowly and up to 0.4 when it changes fast). I need to make a new version for this but it is easy..
When you look for thermals, you do it in normal- or even speed-flightmode. So at higher airspeed a high sensitivity and fast reaction time and good compensation is important. In thermal mode you could reduce compensation or even switch it off - that is also good, because the airspeednoise increases at low speed. This should be the the development goal in my eyes. What dTE does in aerobatics is less/not important. But maybe there are other opinions?

At least there is already a very good standard achieved with this version. More tests in calm conditions are necessary, but i am very optimistic.

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sat Aug 30, 2014 7:36 pm

Here is the video, you can hear the turbulences in the background. At 1:45 i switched to TEK:

http://youtu.be/SfnjnqilPdc

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Aug 31, 2014 8:16 am

@carbo
please find here a new version with minor changes:
1) in this version, smoothing of dTE changes automatically. When dTE do not change fast (it means if the difference between the previous smoothed value of dte and a new one is less than 100 cm/sec), then only 5% of the new dte is taken into account, the rest (95%) is kept from previous smoothed dte. When the difference is more than 100 cm/sec, a bigger % (up to 30%) of the new dte is taken into account. In the previous version new dte was always taken into account for 10%. So, now, dte would normally become more stable for low changes of dte and more reactive for a fast changes. I hope it improves a little the feeling with dte.
This is controlled by those lines in openxsensor.ino file
#define SMOOTHING_DTE_MIN 0.05
#define SMOOTHING_DTE_MAX 0.3
#define SMOOTHING_DTE_MIN_AT 100
#define SMOOTHING_DTE_MAX_AT 1000
If you want to go back to previous setting (always 10%), you just have to adapt the first 2 lines in:
#define SMOOTHING_DTE_MIN 0.1
#define SMOOTHING_DTE_MAX 0.1

2) I added an hysteresis on dte (as it exists on normal Vspeed or TEK). It means that the dte value transmitted to Tx will change only if the new smoothed dte differs from the previously sent dte by more than an hysteresis value defined in config.h file in this line: (where 5 means 5 cm/sec)
#define VARIOHYSTERESIS 5
This is another way to avoid minor changes of dte (or vspeed or TEK)
Note: all 3 vario signals (vspeed, TEK and dte) share the same hysteresis value.

3) I currently remove the ability to control the sensitivity of dTE via the PPM. The way it worked was not acceptable anymore due to the added smoothing on dte. I still have to implement a better solution. So in this version, PPM can control only the sensitivity on normal Vspeed and TEK . Sensitivity on dTE can, in this version, only be changed by the 4 lines explained in point 1 here above .
In the config.h file, I added a set up in order to transmit the sensitivity in the field Fuel. So, if you want to experiment with different sensitivities on TEK, you can see the current sensitivity on the TX in the Fuel field.
Please note that in a previous post I said that you could change the sensitivity based on those 2 lines:
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
This is not 100% right in your case because you probably use PPM.
When opeXsensor get a PPM signal (at least once) with a value in the range foreseen for vario sensitivity, the PPM sensitivity get the priority on the set up from those 2 lines.
To be sure about the current sensitivity, it is safe to look at the value on the Tx display (in Fuel with the current set up).
By default you should get a value 50 (means 0.050 smoothing); Decreasing the value (down to 20) would incease the smoothing of Vspeed and TEK.
Attachments
openxsensor_2014_08_31_V1.rar
(65.72 KiB) Downloaded 34 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 10:05 am

Stratos_E-2014-08-31.zip
(147.18 KiB) Downloaded 33 times
This one is very relaxed, lets call it the dope oxs :-) - the feeling is indeed veeeeery goooooood, but its not reality.

I will try:

#define SMOOTHING_DTE_MIN 0.01
#define SMOOTHING_DTE_MAX 0.1

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 10:37 am

Stratos_E-2014-08-31_mod1.zip
(64.5 KiB) Downloaded 31 times
Not much difference, so the culprit is #define VARIOHYSTERESIS 5, will change it to 2 and try

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 10:59 am

Stratos_E-2014-08-31_mod2.zip
(42.32 KiB) Downloaded 33 times
Still too slow, i will do further tests with the version 2014_08_30_V2

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Aug 31, 2014 11:04 am

I will look further.
I presume I made a bug but I do not find it immediately.
I will keep you informed

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Aug 31, 2014 11:24 am

I do not see a bug in the version of this morning.
Compensation seems ok in the log.
Dynamic smoothing on dTE seems ok in the log (more smoothing when dte changes slowly and less when dte changes fast)
If you want that this version works like the one of yesterday you should apply following setup:
#define SMOOTHING_DTE_MIN 0.1
#define SMOOTHING_DTE_MAX 0.1
and
#define VARIOHYSTERESIS 0

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 12:21 pm

OK i will try it. That means, that #define VARIOHYSTERESIS 2, as i flew it, has still a very big influence to the reaction time.

Here is another one with 2014_08_30V2. Still the best.
Stratos_E-2014-08-31_30V2.zip
(190.37 KiB) Downloaded 31 times

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Aug 31, 2014 12:30 pm

Carbo wrote:OK i will try it. That means, that #define VARIOHYSTERESIS 2, as i flew it, has still a very big influence to the reaction time.

Here is another one with 2014_08_30V2. Still the best.
Stratos_E-2014-08-31_30V2.zip
I do not think that Variohysteresis has a big impact.
I think it is more the change in the smoothing on dte.
Using a #define SMOOTHING_DTE_MIN 0.05 instead of a fixed smoothing value = 0.1 means that the reactime is twice as long (about 2 sec).

Using a #define SMOOTHING_DTE_MIN 0.1 should give you the same feeling as V2.

If you use 0.15 (or 0.2) instead of 0.1 (or the 0.05 I put) it will become more reactive.

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 1:28 pm

With this changes:

#define SMOOTHING_DTE_MIN 0.1
#define SMOOTHING_DTE_MAX 0.1
and
#define VARIOHYSTERESIS 0

i had the same behaviour as the previous version. Still i am very happy with it. Today the weather is the limiting factor, it is not calm enough, to make further statements. Maybe later, we will se. In the actual weatherconditions, there is nothing obvious, that could be improved.
Stratos_E-2014-08-31.zip
(75.78 KiB) Downloaded 28 times

Carbo
Posts: 249
Joined: Fri Aug 02, 2013 6:55 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Carbo » Sun Aug 31, 2014 5:39 pm

In rather calm air, after a rain front, i flew with following parameters:

#define SMOOTHING_DTE_MIN 0.2
#define SMOOTHING_DTE_MAX 0.5
#define SMOOTHING_DTE_MIN_AT 100
#define SMOOTHING_DTE_MAX_AT 1000

As predicted, it was slightly more noise, but tolerable. Difficult to say, if it is sensor- or airnoise. Still flyable, here is an example:
2014_08_31-hot.mp3
(486.94 KiB) Downloaded 42 times
SMOOTING_DTE is a candidate for ppm-adjustment, what do you think?

There are long constant fast and slow sectors in the flight, so you can evaluate the noise in different airspeeds.
Stratos_E-2014-08-31_mod3.zip
(235.43 KiB) Downloaded 33 times

mstrens
Posts: 1066
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Mon Sep 01, 2014 7:50 am

@Carbo,
I did not yet look at your log but I prepared a new version with 2 changes:
1) in a previous log, I saw that AccZ (= not switchable dTE) did not change every 100 ms. In fact this is because I had not foreseen that one measurement could be transmitted twice (e.g. once as VSpeed and once as AccZ). Due to this it could also be that telemetry field Vspeed was not sent every 100 msec (because the value was already sent as AccZ - or AccY) and the opposite. This could also create some more jumps than expected.
I change the program in order to avoid this issue.

2) this version allows to change the sensitivity of dTE via a ppm channel.
If sensitivity is set on 50, smoothed dTE will be calculated just like SMOOTHING_DTE_MIN would be 0.1
In fact the formula is : smoothingDteMin = sensitivityPpmMapped /500.
So with sensitivity = 20, it would be like SMOOTHING_DTE_MIN would be 0.04 (so less reactive)
So with sensitivity = 100, it would be like SMOOTHING_DTE_MIN would be 0.2 (so more reactive)

This will allow you to test different values while flying.
Please note that when you change sensitivity using ppm, it has also an impact of normal Vspeed and on TEK (because all share the same PPM setting)

Note : in the openxsensor.ino file for this version, I put currently SMOOTHING_DTE_MIN equal to 0.1 (as you said that it was a good starting value) but this would have no effect if you use PPM to control sensitivity because PPMsensitivity got the priority.

I kept #define SMOOTHING_DTE_MAX 0.3
#define SMOOTHING_DTE_MIN_AT 100
#define SMOOTHING_DTE_MAX_AT 1000
The value 0.3 seems me a good compromise in order to let dTE reacts faster when dTE changes a lot and quite fast.
For the same value of SMOOTHING_DTE_MIN or PPMsensitivity, you could also get a more reactive dTE if you reduce the values on the last 2 lines. You could perhaps try
#define SMOOTHING_DTE_MIN_AT 50
#define SMOOTHING_DTE_MAX_AT 500
It means that when the smoothed dte (the one transmitted) differs for the last calculated by more than 50 cm/sec, than the smoothing factor would increase (but not exceeding 0.3 even if the difference is greater than 500 cm/s).

Ps: I did not tested this version. I just hope I did not make mistakes.
Attachments
openxsensor_2014_09_01_V1.rar
(65.77 KiB) Downloaded 38 times

Post Reply

Return to “OpenXVario - an open source vario supported by the open source firmwares!!”

Who is online

Users browsing this forum: Google Adsense [Bot] and 2 guests