New beta version of openXsensor (=openXvario)

[Carbo]

Thank you for this one, when weather permits, i will test after work. First with SMOOTHING_DTE_MIN equal to 0.1, to see if your first change has audible effects, because sometimes i heard unmotivated beeps with prior versions, maybe this was the trigger. Then with changing ppm in flight, to check the result of this.

[Carbo]

Stratos_E-2014-09-01.zip

(152.48 KiB) Downloaded 241 times

It is a very sedated one, you wish to have a magnifier for the variosound. Even with shortest reaction time, it was like flying in cotton. DTE and TEK are both sedated. The air was calm, but not dead, as the sound pretended.
To be sure, its not me, who is sedated, i flew again the last one with the "hot" parameters.
#define SMOOTHING_DTE_MIN 0.2
#define SMOOTHING_DTE_MAX 0.5
The noise is absolutely OK for me, the varios are alive and you have the feeling for the air. Dont know, which changes are responsible, maybe we try versions with only one modification in each.
I logged it again in the calm air:

Stratos_E-2014-09-01_08_31hot.zip

(67.44 KiB) Downloaded 245 times

[mstrens]

@Carbo
I think I know the reason why the version from monday morning was so sedate about dte.
To fix the issue, this line
if ( sensitivityPpmMapped > 0) smoothingDteMin = sensitivityPpmMapped / 500 ;
should be replaced by this one.
if ( sensitivityPpmMapped > 0) smoothingDteMin = ((float) sensitivityPpmMapped) * 0.002 ;
At first, it looks the same but not for the computer (when it is calculating first with integer values).

[mstrens]

Even with shortest reaction time, it was like flying in cotton. DTE and TEK are both sedated.

I looked further why TEK was sedated because the bug I saw yesterday evening could not explain it.

I found a second bug. Due to some changes I made in order to allow to send dTE (or TEK) in 2 telemetry fields at the same time, I made a mistake and OXS sent no VSPEED anymore when your switch C asked for sending TEK. So when you expected to hear TEK, in fact you heared the last dTE value. This explain why TEK was so sedated.

I fixed this bug (and the one from yesterday) in this new version.

I hope this version will be OK.

[Carbo]

Here is the new log, unfortunately dTE delivers no data, TEK is perfect. After the walk with the dog i can do another one, probably a easy to find bug.

Stratos_E-2014-09-02.zip

(70.13 KiB) Downloaded 260 times

[mstrens]

Here is the new log, unfortunately dTE delivers no data, TEK is perfect. After the walk with the dog i can do another one, probably a easy to find bug.

Stratos_E-2014-09-02.zip

I look immediately

[mstrens]

Here is the new log, unfortunately dTE delivers no data, TEK is perfect. After the walk with the dog i can do another one, probably a easy to find bug.

I think I fix it.
Sorry for this mistake.

Please note that I made to day some clean up of the code and it could be that I made new mistakes. I have not yet made tests myself.
I will explain later one new feature but just ignore it at present.

[Carbo]

Thx, this one works very good. The air is not calm enough, to make a final judgement, but i am again very happy with it. Decrasing reaction time did not bring too much noise, only in speedmode (switch A up), there seemed to be more noise than expected, normally it should be calmer. But the conditions are really not the one we need today.

Stratos_E-2014-09-02V2.zip

(178.44 KiB) Downloaded 248 times

[mstrens]

Thx, this one works very good. The air is not calm enough, to make a final judgement, but i am again very happy with it. Decrasing reaction time did not bring too much noise, only in speedmode (switch A up), there seemed to be more noise than expected, normally it should be calmer. But the conditions are really not the one we need today.

Stratos_E-2014-09-02V2.zip

I look at the log and it seems that it works fine.
dTE seems even better than TEK. TEK seems more noisy. Sometime TEK fluctuates even more than normal Vspeed what seems me not really normal (except if there is wind and the glider get it front and back quite fast).
Are the TEK probe and the Prandtl probe close to each other so that they get the same pressure?

About sensitivity, you can see now that sometime the value increase even when you do not change PPM. This was foreseen with the new program and it seems ok.

There is still, from my point of view, an issue. Normally the log should give on every line (or nearly) a different value for Vspeed (and for dTE) because dTE is normally calculated every 100 ms and there is one entry in the log every 100ms.
In fact it happens quite often that the log repeats the same Vspeed (and dTE) on several lines.
I can partly explain it by the fact that OXS transmit a data as soon it is "available" and that the Rx allows it. Because normal AccX and AccY are available every 20 msec, it could be that they get to much priority.
In practice, this problem should not exist because there is normally no need to transmit all those data.
It could be useful to make a new test with this config which is more realistic for a normal user:
#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 ,\
VSpd , PPM_VSPEED , 1 , 1 ,0 , \
DEFAULTFIELD , AIR_SPEED , 1 , 1 ,0

Anyway , I suspect that there are some issues in the Sport protocol (not OXS based but Frsky or OpenTx related) because in the past, I already have seen that the data in the log did not change as fast as OXS generates them.

In order to partly solve this, I can change the program in order to ask OXS to repeat as often as possible the last known switchable Vspeed (being Vspeed, TEK or dTE) when there is a free slot on the Sport bus.

[mstrens]

FYI, compare to some previous versions, the version 2014_09_02_V2 has following changes:
- up to now, when PPM was not used, OXS used following parameters to adjust the sensitivity (for normal Vspeed and TEK):
#define SENSITIVITY_MIN_AT_VSPEED 20
#define SENSITIVITY_MAX_AT_VSPEED 100
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
When SENSITIVITY_MAX was greater than SENSITIVITY_MIN, it allowed to get automatically a higher sensitivity when Vspeed (normal of TEK) get a high value (positive or negative).
I had foreseen it long ago in order to react faster when VSpeed increased (so avoiding noise around zero lift and still faster response at high Vspeed).

Still I was not 100% convinced that it was useful.
Therefore I put often SENSITIVITY_MIN = SENSITIVITY_MAX and so, it had no effect and the sensitivity did not change.

Furthermore, when ppm was used, those parameters where totally discarded and the sensitivity was only defined by ppm.
That is currently how you used OXS.

I made a modification that replaces the previous parameters by those one:
#define SENSITIVITY_MIN_AT 100 // cm/sec
#define SENSITIVITY_MAX_AT 1000 // cm/sec
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 300
When there is no ppm signal, the sensitivity is normally fixed by #define SENSITIVITY_MIN 50 (as before).
But now sensitivity is automatically adapted by OXS based on the difference between the current raw VSpeed (raw = the value before smoothing) and the previous smoothed Vspeed.
It means that it is not anymore the Vspeed value it self but the rate of change of Vspeed that has an impact.
This seems me better in order to eliminate most of noise in signal but still keeping fast reaction when changes are quite fast and that the smoothing function can't follow.
I already used this kind of logic on several places but not yet for the "traditional" Vspeed.
Now I used it for normal Vspeed and TEK too.
I think that this new automatic sensitivity adaptation can be useful when sensitivity is controlled by ppm too.
In order to achieve this (when ppm is used), OXS use now the value got from ppm just instead of SENSITIVITY_MIN.
It means that the 3 other parameters SENSITIVITY_MIN_AT, SENSITIVITY_MAX_AT and SENSITIVITY_MAX continue to have an impact on the sensitivity (allowing a faster reaction time only when Vspeed changes fast).

Note: I (already) used the same principle for dte.

- I moved the parameter COMPENSATIONMILLIS that is used to fix the interval to calculate dte from config.h to oxs_ms5611.cpp because it would be to risky to let normal user modify it. That is the reason why the previous version did not work as expected.

- I removed from the code all min and max values (Vspeed, altitude, current, ...) that OXS calculated because they were never transmitted. In fact they are calculated by the Tx it self.

PS : I had planned to add some code in order to discard very very fast changes of the raw dte but this is not yet done.

[mstrens]

FYI, here some charts on the last log.

[Carbo]

Are the TEK probe and the Prandtl probe close to each other so that they get the same pressure?

The positions should be OK, but TEK is sensible, you remember maybe, when i mounted the camera, suddenly TEK was overcompensated, i had to change it against one with smaller washer. The reason for the TEK noise is definitely the wind. I could not resist, and have just made another flight in calm conditions to stop you offending my handmade TEK

Flying sinus, first with dTE then with TEK showed an acoustic better performance of the TEK, but this are not normal maneuvers when searching for thermals. If you want to improve something, here is a starting point. Questionable, if it is worth the effort.

Left side is dTE, right side of the vertical line is TEK. The funny thing is, dTE looks better, TEK sounds better, in fact TEK sounds as dTE looks, i hope, it is not a mix-up somewhere. It is better to discuss this based on a video with synchronized vario, so this is my next task. Bullshit: Correct is that on the left side is TEK, on the right side is dTE !

Overall this version is really, really good, so this is my new favourite!

Stratos_E-2014-09-02V2#2.zip

(95.49 KiB) Downloaded 239 times

[mstrens]

Left side is dTE, right side of the vertical line is TEK. The funny thing is, dTE looks better, TEK sounds better, in fact TEK sounds as dTE looks, i hope, it is not a mix-up somewhere.

There is probably a mix-up.
I presume that you switch the vario source based on switch C

If I look at switch C in the log, I see 3 phases:
- first it is 0
- second it is -1
- third it is 1

Then I try to compare Vspeed (= what you hear) with AccY (= TEK) and AccZ (=dTE)
I see that when:
- switch C = 0, Vspeed looks like dTE
- switch C = -1, Vspeed looks like TEK
- switch C = 1, Vspeed looks like dTE again.
So begin and end of the flight is with dTE and middle is with TEK.

Take care setting your PPM with this explanation :
* Even if OXS can calculate up to 3 vertical speeds (VERTICAL_SPEED, VERTICAL_SPEED_2, PRANDTL_DTE), it is only possible currently to switch between 2 predefined vertical speeds.
* To enable this feature, additional parameters are required:
* 1) Specify what are respectively the primary and the secondary vertical speeds using the lines
* #define VARIO_PRIMARY 2
* #define VARIO_SECONDARY 1
* where 0 means first ms5611, 1 means second ms5611 (=TEK), 2 means vario based on vario 1 + compensation from airspeed sensor (= dTE)
* 2) Specify a range of PPM value that OXS has to check in order to send or the primary or the secondary vertical speed using the lines
* #define SWITCH_VARIO_MIN_AT_PPM 10
* #define SWITCH_VARIO_MAX_AT_PPM 90
* When the ABSOLUTE value of PPM is between SWITCH_VARIO_MIN_AT_PPM (typical value = 10) and SWITCH_VARIO_MAX_AT_PPM (typical value = 90),
* - OXS will switch to the primary vertical speed IF PPM is POSITIVE
* - OXS will switch to the secondary vertical speed IF PPM is NEGATIVE
* Note: when the absolute value of PPM is outside this range, OXS will not switch from vertical speed and keep the current one.
* This principle allows to use a switch on TX simultaniously with a pot in order to control sensitivity or compensation.
* Switching from positive to negative can be achieved on openTx with a mixer using MULTIPLY by -1.
* Sending a value outside this range allows to instruct OXS to apply an order (e.g. reset the airspeed offset) without switching the vertical speed.


I do not know what is your set up on Tx side for generating ppm signal (specially about switch C = 0).
Could you check please.

[Carbo]

I use the oldfashioned way to check which VSpeed is active: puffing into the TEK --> sound changes --> TEK and vice versa.

I start the flights with switch C in the middle, knowing from the test before, that dTE is active and knowing, i have the standard sensivity (50). Here are my mixes for ppm:

L4 is for sending 2 sec 100% for resetting airspeed: rudder full left and SH pulled.

My fault was: I flew 2 times sinus, first time i switched from dTE to TEK, second time from TEK to dTE, on the log i saw only the vertical line and i thougt it was the first change. So big relief: everything is OK, i heard what i see

[mstrens]

Here a version with 3 minor changes:
1) I added a line "#define SWITCH_VARIO_GET_PRIO" in the config. When present, it means that OXS will try to send the "switched Vpseed" as often as possible and will slow down the transmission of normal Vspeed and TEK.
This could perhaps help getting a better realistic vario tone.
2) I saw in you log that when you made sinusoidal, dTE did not compensate enough at the beginning of sinking. I expect that it is because fast Vspeed react faster than airspeed compensation; I also saw that fast Vspeed has more noise that other data. In order to try to improve dTE, I put some more smoothing on fast Vspeed.
3) I added some code in order to avoid to fast big change of compensation. If, between an interval of 100millisec, compensation changes (increases or decreases) by more than a new parameter (currently set on 200 cm/sec), I limit the change to this parameter. I hope this will avoid to big and abnormal peaks.

Let me know if it works better.

[Carbo]

2) I saw in you log that when you made sinusoidal, dTE did not compensate enough at the beginning of sinking. I expect that it is because fast Vspeed react faster than airspeed compensation; I also saw that fast Vspeed has more noise that other data. In order to try to improve dTE, I put some more smoothing on fast Vspeed.

@ mstrens When you look at the log, it seems for me, that the compensation is too late and therefor too much, so the overshoots happen. Maybe we mean the same, i am not not sure? The noise of the positive overshoots is disturbing, because it makes no sense in this situation. You know: left side TEK, right side dTE .

@ others_if_there_is_anyone : The big wave is the uncompensated vario, that is what you hear without compensation.

Now dog, then flight.

[Carbo]

Here a version with 3 minor changes:
1) I added a line "#define SWITCH_VARIO_GET_PRIO" in the config. When present, it means that OXS will try to send the "switched Vpseed" as often as possible and will slow down the transmission of normal Vspeed and TEK.
This could perhaps help getting a better realistic vario tone.
2) I saw in you log that when you made sinusoidal, dTE did not compensate enough at the beginning of sinking. I expect that it is because fast Vspeed react faster than airspeed compensation; I also saw that fast Vspeed has more noise that other data. In order to try to improve dTE, I put some more smoothing on fast Vspeed.
3) I added some code in order to avoid to fast big change of compensation. If, between an interval of 100millisec, compensation changes (increases or decreases) by more than a new parameter (currently set on 200 cm/sec), I limit the change to this parameter. I hope this will avoid to big and abnormal peaks.

Let me know if it works better.

Normal flying is still perfect, good sound. Sini with less positiv overshoots. When you look at the log, it seems, that switched vspeed has also reduced transmission. Can you say something about the reaction time for vspeed in relation to the actual oxs? I hope there will be some thermals in the next days, to check the sensibility for them.

Stratos_E-2014-09-03.zip

(69.36 KiB) Downloaded 179 times

[Tempo]

Are the TEK probe and the Prandtl probe close to each other so that they get the same pressure?

Sensors.jpg

(Important picture of fitted probes !)

The positions should be OK, but TEK is sensible, you remember maybe, when i mounted the camera, suddenly TEK was overcompensated, i had to change it against one with smaller washer.
Position of probes is very unfavorable. In this way you make measurements of flow field interference between fuselage, wings and camera. Also angle of attack has control on your probes.
The reason for the TEK noise is definitely the wind. I could not resist, and have just made another flight in calm conditions to stop you offending my handmade TEK

[Carbo]

Hello Tempo,

as you can see, it is only a provisionally setup. The goal is still, to prove if reliable electronic vario-compensation with airspeed is possible at all. Qualitative results are OK at the moment. I am convinced, that the airspeedsensor is far enough away from the rest, to give reasonable data.

Nevertheless a wider database is required, so if you fly TEKs, please publish your logs flying sinus-figures. I asked already in FPV-Forum, you join too, for additional tests. The best would be tests with airspeedsensor and TEK, so you can evaluate the difference between the two compensations.

[Carbo]

Stratos_E-2014-09-05.zip

(297.04 KiB) Downloaded 169 times

Here is the log with 2014_09_05V2 (missing v1, will you test it?)
Very restless dTE, switching to TEK exactly the same - a lot of small thermals, some flyable, most not. Did some longer dives and climbs, but most of the time searching. Gives a good feeling for the air, but must be tested in calm air. Mabe this evening.

[Carbo]

And here is the second one in very calm conditions:

Stratos_E-2014-09-05.zip

(151.63 KiB) Downloaded 176 times

Removed the camera and mounted a more compensating TEK-probe, here is a comparison of the uncompensated (AccelX), TEK (AccelY) and dTE (VSpeed). dTE has some artifacts, that are not caused by the sensor data, when airspeed changes very fast. In normal flight it is perfect, sound and reactiontime are fine. I will reduce the compensation of TEK a little bit, it seems slightly overcompensated.

[mstrens]

Stratos_E-2014-09-05.zip

Here is the log with 2014_09_05V2 (missing v1, will you test it?)
about first flight:
Very restless dTE, switching to TEK exactly the same - a lot of small thermals, some flyable, most not. Did some longer dives and climbs, but most of the time searching. Gives a good feeling for the air, but must be tested in calm air. Mabe this evening.

Indeed, very restless dTE. It seems that dTE is worst than TEK from this point of view. But there are no big difference between Vspeed, TEK and dTE.
Perhaps we can increase smoothing on dTE.

Perhaps also no bad to try V1 and V2 when flying condition are similar (in order to see which one gives the best feeling/log)

I will now look at your second flight

[Carbo]

Indeed, very restless dTE. It seems that dTE is worst than TEK from this point of view. But there are no big difference between Vspeed, TEK and dTE.

Maybe a misunderstanding, indeed they are nearly the same, because the air caused it, i phrased it strange.
To V1 i have no access, neither here nor pm, please send it again, thanks.

[mstrens]

Indeed, very restless dTE. It seems that dTE is worst than TEK from this point of view. But there are no big difference between Vspeed, TEK and dTE.

Maybe a misunderstanding, indeed they are nearly the same, because the air caused it, i phrased it strange.
To V1 i have no access, neither here nor pm, please send it again, thanks.

When I look at the log for your second flight, when I compare uncompensated Vspeed, TEK, and dTE, it seems that:
- TEK compensates better than dTE.
- dTE could probably get more smoothing. This can be done replacing #define SMOOTHING_DTE_MIN 0.1 by #define SMOOTHING_DTE_MIN 0.05 in openxsensor.ino
- when you start a fast sinking, TEK compensates wel at the begining (better than before) but not better after some delay. I do not know if this is the result of the new probe, of another position of the probe or from the fact that I now compare with FastVspeed instead of normal uncompensated Vspeed).

Here the missing V1

[mstrens]

- dTE could probably get more smoothing. This can be done replacing #define SMOOTHING_DTE_MIN 0.1 by #define SMOOTHING_DTE_MIN 0.05 in openxsensor.ino

Sorry,
this is right but only when you do not use PPM.
So in your case, increasing smoothing can be done in the following way:
There is a line in openxsensor.ino with
if ( sensitivityPpmMapped > 0) smoothingDteMin = ((float) sensitivityPpmMapped) * 0.002 ; // a value of sensitivityPpmMapped = 50 becomes a smoothing factor 0.1
It could be changed in
if ( sensitivityPpmMapped > 0) smoothingDteMin = ((float) sensitivityPpmMapped) * 0.001 ; // a value of sensitivityPpmMapped = 50 becomes a smoothing factor 0.05

I will also try to make another version where I will sum the 2 sensors pressures before applying any smoothing.
I will keep you informed
This parameter says to OXS than when he has

[Carbo]

Going 2 steps back, i calculated total energy in the 2014_09_05 log for 19:10:57 - 19:10:21:

It seems, there is an energy increase, and that is impossible, there were absolutely no thermals at that time. Here once again dTE:

So the dTE calculation is OK, except the artifacts, but the basic data is wrong?
Another observation, i do not understand: in the log there are knots, on the display, while flying, i see definitely km/h (~ knots x 2), where does this conversion take place? Can this be the reason?
It would be good to crosscheck this, because it implies, that airspeed or altitude (ore hopefully my calculation) are wrong.

[mstrens]

Another observation, i do not understand: in the log there are knots, on the display, while flying, i see definitely km/h (~ knots x 2), where does this conversion take place? Can this be the reason?
It would be good to crosscheck this, because it implies, that airspeed or altitude (ore hopefully my calculation) are wrong.

I do not expect a mistake in the conversions.
In OXS, I calculate airspeed, vertical speed, compensation... in cm/sec but just when I have finish I convert airspeed (and only airspeed) in knot/h because openTx needs it in this unit.
Then it is openTx that converts the knots/hour into km/h when you put your Tx in metric but this conversion is performed by openTx only on the screen. So, in the log, you have first to convert the knot/h into another unit. Best is to convert the knot/h into m/sec, if you want to calculate the total energy by adding to altitude. Normally you would have to calculate:
Airspeed (knot/h) * Airspeed (knot/h) / 2 * 0.5144 * 0.5144 / 9.81.
When you do it you should find back the compensation that I calculate inside OXS and that is put in Temp1.
Please note that the OXS compensation is in cm/s and so you have to multiply the previous result by 100.

There is something strange: When I do this calculation in XLS, I do not find exactly the same value (about 15% difference). I do not know why.
I checked in OXS but I did not find an error.
Perhaps that conversion done by OpenTx do not use the same conversion factor as I expect.

[Carbo]

Then it is openTx that converts the knots/hour into km/h when you put your Tx in metric but this conversion is performed by openTx only on the screen.

OK, got it

So, in the log, you have first to convert the knot/h into another unit. Best is to convert the knot/h into m/sec, if you want to calculate the total energy by adding to altitude.

Thats what i did.

There is something strange: When I do this calculation in XLS, I do not find exactly the same value (about 15% difference). I do not know why.

Playing around in calculation of total energy, it showed, that increasing airspeed for 15% gave a realistic energy trend.

[mstrens]

Playing around in calculation of total energy, it showed, that increasing airspeed for 15% gave a realistic energy trend.

With the log, you can also do this calculation :
Total energy = baro (alt) * 100 + Temp1
Baro is in m and has to be converted into cm
Temp1 is already the compensation calculated by OXS in cm based on airspeed.

[Carbo]

With the log, you can also do this calculation :
Total energy = baro (alt) * 100 + Temp1

Here it is:

Same result as the +15% diagramm, so there is a conversion problem in opentx, and
my Stratos is 15 % faster!! btw. the diagramm reminds me of a comb-filter, when speed changes fast, maybe there is a time alignment problem. That would cause the artifacts in dTE.