New beta version of openXsensor (=openXvario)

rolfz · Post by **rolfz** » Tue Oct 07, 2014 9:54 pm

PPM signal,

I just discovered that I connected the MiniAVR on my CPPM output

so no chance to get a proper timing).
Now I have the right PPM signal, I only see the value changing from 488-1000 ! as I am using a 3.3V 8Mhz board, I could imagin the timer counting PPM has to be changed to count 2x faster.

As I am not an expert in Arduino you may tell me where I could adjust the timer setup, if this the right origin of my problem. I made a try muliplying with <<4 inside ReadPPM and I finally got some Sensitivity feedback on the radio, but that's not the right place to make the correction as with this, I loose mesurment resolution.

mstrens · Post by **mstrens** » Wed Oct 08, 2014 8:00 am

rolfz wrote:PPM signal,

I just discovered that I connected the MiniAVR on my CPPM output so no chance to get a proper timing).
Now I have the right PPM signal, I only see the value changing from 488-1000 ! as I am using a 3.3V 8Mhz board, I could imagin the timer counting PPM has to be changed to count 2x faster.

As I am not an expert in Arduino you may tell me where I could adjust the timer setup, if this the right origin of my problem. I made a try muliplying with <<4 inside ReadPPM and I finally got some Sensitivity feedback on the radio, but that's not the right place to make the correction as with this, I loose mesurment resolution.

You are right: there is a bug in OXS.
I just saw that OXS had never been adapted to support correctly PPM with an arduino running at 8 mhz.
The correction is made in the ino file inside the ISR code.
I replaced
time >>= 7 ; // Nominal 125 to 250
by
#if F_CPU == 20000000L // 20MHz clock
#error Unsupported clock speed
#elif F_CPU == 16000000L // 16MHz clock
time >>= 7 ; // Nominal 125 to 250
#elif F_CPU == 8000000L // 8MHz clock
time >>= 6 ; // Nominal 125 to 250
#else
#error Unsupported clock speed
#endif

I just put a new version on google at this link
https://code.google.com/p/openxsensor/s ... ensor_v2.0
I also removed the comments on the 4 lines about Gps speed in Hub and I made a minor update of the config description.

Let me know if it is now OK.

rolfz · Post by **rolfz** » Wed Oct 08, 2014 11:34 am

Thank you for the correction, I have implemented it, and ppm seems to work not.

Can you just tell me what is the best setup on Taranis for the Sensivity ? Potentiometer like S1/S2 and what setup ? linear from -100 to + 100 ? my impression now is that there is a variation close to middle point, on mine showing 20 and then it moved both sides to 100 which is explained in the documentation (abs value).

mstrens · Post by **mstrens** » Wed Oct 08, 2014 12:52 pm

rolfz wrote:Thank you for the correction, I have implemented it, and ppm seems to work not.

Can you just tell me what is the best setup on Taranis for the Sensivity ? Potentiometer like S1/S2 and what setup ? linear from -100 to + 100 ? my impression now is that there is a variation close to middle point, on mine showing 20 and then it moved both sides to 100 which is explained in the documentation (abs value).

You said "I have implemented it, and ppm seems to work not.".
I presume that you intend "I have implemented it, and ppm seems to work now".

OXS allows to change vario sensitivity (using PPM) but this is just an option.
I think that using the default setting is already very good.
The default setting is configured with those lines:
#define SENSITIVITY_MIN_AT 100
#define SENSITIVITY_MAX_AT 1000
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 300
This means that when the absolute value of Vertical speed is less or equal to 100 cm/sec, the sensitivity will be 50 which give a good response time and not to many jumps.
The 2 other parameters ( 1000 and 300) are just there to allow a faster reaction when vertical speed is high.
I think that many users do not need/want to modify the vario sensitivity during the flight.
They just set up a value in the config.
Without using PPM you could already experiment changing sensitivity just by replacing the parameter MIN (currently 50) by another one.
I think you could experiment with values between 20 and 150. Never use a value higher that 999 because the vario will be unstable.

Anyway, the PPM option exist and normally work.
It is up to you to choice how to adjust sensitivity on TX. You can use any pot or even some switch.
You just have to apply some mixer on a channel. In order to control the OXS sensitivity, the output of the mixer must be between the parameters set in lines
#define SENSITIVITY_MIN_AT_PPM 10 // sensitivity will be changed by OXS only when PPM signal is between the specified range enlarged by -5 / +5
#define SENSITIVITY_MAX_AT_PPM 40
Please note that I did used values 10 and 40 (and not 0 - 100) in order to keep (range of) values for the other functions controlled PPM.
For sure you have to take care that the values for different funtions does not overlap each other.
That is the reason why the values for electronic compensated vario are set in following way:
#define COMPENSATION_MIN_AT_PPM 60
#define COMPENSATION_MAX_AT_PPM 90
and the value for airspeed reset is
#define AIRSPEED_RESET_AT_PPM 100

Please note also that OXS will apply the same sensitivity (or compensation) if the channel send a positive or a negative value. OXS uses the absolute value from the channel (e.g. channel -45 gives same result as +45). This has been done in order having the possibility to switch between 2 vario sources with a switch and still keepingsimultanously the control of sensitiviy or compensation by a Pot or another switch.
In order to have simultanously control of sensitivity and compensation would require some complex mixing where you would continously alternates (e.g. every seconde) on the mixer the value for sensitivity and compensation.

With those 2 lines
#define SENSITIVITY_MIN_AT_PPM 10 // sensitivity will be changed by OXS only when PPM signal is between the specified range enlarged by -5 / +5
#define SENSITIVITY_MAX_AT_PPM 40
OXS will recognise that it has to adapt vario sensitivity when the PPM channel value is between 10 and 40 (in fact 6 and 44 due to some internal tolerances).
You still have to inform OXS which sensitivity you want when PPM is 10 and which one you want when PPM is 40.
This is done by the 2 other lines:
#define SENSITIVITY_PPM_MIN 20 // common value for vario is 20
#define SENSITIVITY_PPM_MAX 100 // common value for vario is 100
So here the sensitivity can be adjusted to any value between 20 and 100. If you want, you can change here the range of sensitivity if you want to experiment a larger range.

I hope this is clear enough.
If not just ask for.

rolfz · Post by **rolfz** » Wed Oct 08, 2014 1:02 pm

Thank you for all details,
I just made a test on the motorway (fix speed, slow-up slow down) followed by some more hilly places, and I realized standard setup as you mentionned is just doing fine.
If I move away from standard setup, speed (pitot) suddently goes to zero. So I will keep standard setup until I have more time to test and learn.

I recorded the data and converted to graph with excel.

mstrens · Post by **mstrens** » Wed Oct 08, 2014 1:17 pm

rolfz wrote:Thank you for all details,
I just made a test on the motorway (fix speed, slow-up slow down) followed by some more hilly places, and I realized standard setup as you mentionned is just doing fine.
If I move away from standard setup, speed (pitot) suddently goes to zero. So I will keep standard setup until I have more time to test and learn.

I recorded the data and converted to graph with excel.
OpenXsensor_test.JPG

4525DO sensor has some noise (like any sensor).
When the difference of pressure at 4525DO is small it is not possible anymore to calculate an accurate airspeed.
Calculated airspeed could also become negative but openTx does not accept negative value (for airspeed) and consider them as very a high value. This is very anoying.
That is the reason why OXS sent 0 as airspeed when the calculated airspeed is below about 10 km/h.

Mayeric · Post by **Mayeric** » Mon Oct 20, 2014 10:28 am

Just discovered this great development when searching on MS4525DO use for airspeed (pitot tube) application.
For a different application, (although a RC practionner, my current hobby is rather hangglinding) I am quite interested in putting together a small sensor hub that could integrate a GPS chip, and altimeter & variometer (eg. one MS5611), and airspeed sensor (MS4525DO on pitot tube) and "spit-out" on a wire some TTL-level data in NMEA format. The objective is to interface with a Kobo e-ink reader running XSoar, an open-source glider software.

Before getting more into the subject of potentially using OpenXsensor/Arduino in link with a Kobo, does any thoughts of potential conflicts/constrainst spring in mind (eg. limitations in the arduino I/O connectivity number or type) ?
Which arduino model to prefer, one objective being to limit the power consumption of the device as it will be powerer on the kobo battery itself ?

mstrens · Post by **mstrens** » Mon Oct 20, 2014 5:59 pm

Mayeric wrote:Just discovered this great development when searching on MS4525DO use for airspeed (pitot tube) application.
For a different application, (although a RC practionner, my current hobby is rather hangglinding) I am quite interested in putting together a small sensor hub that could integrate a GPS chip, and altimeter & variometer (eg. one MS5611), and airspeed sensor (MS4525DO on pitot tube) and "spit-out" on a wire some TTL-level data in NMEA format. The objective is to interface with a Kobo e-ink reader running XSoar, an open-source glider software.

Before getting more into the subject of potentially using OpenXsensor/Arduino in link with a Kobo, does any thoughts of potential conflicts/constrainst spring in mind (eg. limitations in the arduino I/O connectivity number or type) ?
Which arduino model to prefer, one objective being to limit the power consumption of the device as it will be powerer on the kobo battery itself ?

I have no knowledge about Kobo and Xsoar but here some advice about openXsensor that could help you.
The code in openxsensor is spiltted in different files. Most of them are not required for your project.
The easiest would be to use only part of the .ino file, the OXS_general, the OXS_MS5611 and the OXS_4525DO files; the other files are specific to measure voltages, current and to communicate with an RC receiver from Frsky.
I presume you would have to handle 1 or 2 serial ports (one to read the GPS, the other to send to the Kobo).
I presume that those serial ports does not require very high baud rates. Then, they could be implemented using software serials (there are libraries for arduino). In this case you can use several arduino pins to support those software serial port.

If you want to reduce consumption, I think you could use an arduino pro mini running at 8 mhz (3.3 volt).
This arduino is very small but has only 1 hardware serial port. Still this would not be an issue if you can implement your 2 serial ports via software.

sundancer · Post by **sundancer** » Fri Dec 05, 2014 10:16 am

Hi, interesting reating about the compensation - I am building my own small flight system for gliding - just for fun, and your code is great work and motivation! I have read whole thread, but I am not sure about few things:
1/ What configuration is needed to make the electronically compensated vario work. Baro + irspeed probe? Or 2 baros (1 for TEK) + airspeed?
2/ I have the ms4525 sensor, is there any tutorial about how to connect it properly?
3/ The ms45225 datasheet says that lowpower mode is available, is it worth turning it on for lower power consumption? What are the negativesof doing so?

mstrens · Post by **mstrens** » Fri Dec 05, 2014 2:38 pm

sundancer wrote:Hi, interesting reating about the compensation - I am building my own small flight system for gliding - just for fun, and your code is great work and motivation! I have read whole thread, but I am not sure about few things:
1/ What configuration is needed to make the electronically compensated vario work. Baro + irspeed probe? Or 2 baros (1 for TEK) + airspeed?
2/ I have the ms4525 sensor, is there any tutorial about how to connect it properly?
3/ The ms45225 datasheet says that lowpower mode is available, is it worth turning it on for lower power consumption? What are the negativesof doing so?

1) for electronically compensated vario you need 1 baro (MS5611) to give altitude an uncompensated Vertical speed + 1 MS4525 to give airspeed pressure and so rate of change of airspeed pressure.
The electronically compensated vario is calculated based on the vertical speed and the rate of change of airspeed pressure.
MS4525 sensor has to be connected to a prandtl probe (in order to get only the difference between the static and the dynamic pressure).
There is no need for a second baro sensor (MS5611). OpenXsensor allow a second baro sensor just for the case that the user want to have too a pnematically compensated vario (using then a TEK probe).
2) I presume you have already the datasheet for the MS4525. It is easy to get it on the web. This sensor has an I2C interface. This interface is used by openXsensor. So you only have to connect:
- VCC to vcc
- gnd to gnd
- SDA to SDA
- SCL to SCL
The other pins are not used. So you can consider that MS4525 is connected in parallel to MS5611. I2C is a bus and so is shared by all electonic components.
As said in the datasheed, it is good practice having a condensator (100nf) between vcc and gnd as close as possible from MS4525.
Take care of the voltages used by arduino, MS5611 and MS4525.
Personnally I used an Arduino 5 volt, a GY63 (that board contains all electronic components to let the MS5611 - working at 3.3 volt - to exchange with Arduino) and a MS4525 with vcc = 5 volt.
There are also some variants of the MS4525 that are foreseen for 3.3 v and I presume there would not work directly with an Arduino 5 v.
3) I have no experience with low power comsumption. I do not think that it makes sense. I saw that MS4525 is very noisy. In order to reduce the noise, code is build in order to read it as often as possible ( about every 5 msec) and to filter the "many" returned values (using moving averages + exponential smoothing).

I hope this help you in your project.

RaptorSense · Post by **RaptorSense** » Mon Dec 29, 2014 10:14 pm

Just discovered this thread. Really nice work, wow!

Last year I did some experiments with the HCLA02X5EU and the HCLA12X5EU from sensortechnics.com. Nice sensors but little too expensive and bulky for me. I was also planning to experiment with the MS4525. You wrote that the MS4525 is noisy. Is it at low speeds only or for the whole range? And, how noisy is noisy?

mstrens · Post by **mstrens** » Tue Dec 30, 2014 9:57 am

RaptorSense wrote:Just discovered this thread. Really nice work, wow!

Last year I did some experiments with the HCLA02X5EU and the HCLA12X5EU from sensortechnics.com. Nice sensors but little too expensive and bulky for me. I was also planning to experiment with the MS4525. You wrote that the MS4525 is noisy. Is it at low speeds only or for the whole range? And, how noisy is noisy?

I think that MS4525 can do the job (airspeed sensor and compensated vario - when associated with another sensor).
It is possible to read the sensor at high speed and so to filter a lot the measurements in order to reduce the noise.
It will not provide good airspeed measurement at low speed (e.g. less than 10 km/h) just because airspeed depends on SQRT of pressure and so ,for low airspeed, the difference of pressure to measure are very low (even lower than the ADC resolution). Furthermore there is (like for all those sensors, I presume) some drift (probably due to the temperature). A drift of just 1 ADC step has a big impact on the calculated airspeed at low speed but much less when speed increases.

In the first versions of OXS I wrote, I made the mistake to convert the pressure to airspeed, to calculate the variations of airspeed and finally to calculate the vario compensation.
In this process, I had to filter the calculations at several levels and I faced issues finding the right filters parameters.
It was not such an issue for airspeed measurement but wel for electronic vario compensation because the response time had to be similar to the response time provided by the baro filters (MS5611).

Finally, a good solution was found when I calculated the vario compensation directly based on the rate of pressure variation (instead of the rated of calculated airspeed variation).
The algorithm becames much easier and it was possible to get easily similar response times for baro and for compensation.
As you can see in the code, I read the MS4525 sensor faster than the MS5611 baro sensor. I first calculate a moving average (on 4 values) of the MS4525 pressure and I apply this moving average as input for the following calculations using the same kind of filtering as for the normal vario.

It is very difficult to experiment this at home because I have no wind tunnel. So nearly all tests were made with a glider thanks to Carbo. He installed on his glider a version of OXS with
- a normal vario
- a TEK probe
- a prandtl probe.
So it was possible to compare on the log the different measurements and check that the measurements confirmed the feeling.
When Carbo was satisfied, I published the version 2.0 of OXS. The current version 2.5 has only minor iprovements (or bug fixes) on other parts.
I have no feedback from Carbo since a few months but it is not really the best season in Europe for thermalling.

Best regards,
Michel

RaptorSense · Post by **RaptorSense** » Tue Dec 30, 2014 11:22 am

Hi Michel,

Like you wrote, even minimal noise from the differential sensors has huge effect on the airspeed readings at low speeds. That is inevitable. Maybe you can remember my project, I have chosen to use absolute sensors only but the effect is the same. In my case, lower than ~15 km/h is too noisy.
It is a challenge to filter the noise while keeping the reaction speed at acceptable levels. Doing this for multiple sensors while keeping them in sync doesn’t make it any simpler. It was even worse in my case due to my mistake of switching to the LPS331 sensors because of their size and measurement range. Unfortunately, their performance does not match their specs. Very noisy and lots of drift, it was a big mistake. In order to choose the best one, I have built a test setup to measure 5 alternative sensors (MS5611, LPS331, LPS25H, BMP180, BMP280) at the same time. The MS5611 and the BMP280 were the best. We have switched to BMP280 now because of its dimensions. The prints are ready, just waiting on the delivery of the fresh solder paste.

I have seen Carbo’s feedback, it is invaluable. Wind tunnel (I would love to have one) is good for calibration but the proof of the pudding is in the eating. Last six months, there was no real possibility to experiment and flight test for me. Let’s hope that 2015 will be a better year. Spring is coming and I definitely need some pudding

Cheers, Sinan

Carbo · Post by **Carbo** » Tue Dec 30, 2014 9:50 pm

mstrens wrote: When Carbo was satisfied, I published the version 2.0 of OXS. The current version 2.5 has only minor iprovements (or bug fixes) on other parts.
I have no feedback from Carbo since a few months but it is not really the best season in Europe for thermalling.

Hi Michel,

still absolutely happy with OXS, so there was no need for additional feedback. The only thing i thought about, was an idea from Henning (also a Member here), on his webspace:
http://henning.bplaced.net/project_myvario.html
He uses a second MS5611 to reduce the noise. So there seems to be a chance, to reduce filtering and the response time of the vario in OXS. To be honest, i never felt the need to have faster reaction time. But the hardware is still available, so if you want to test it (and to write the code), i am ready.

@ Sinan: On Hennings page you can see the dimensions of the MS5611 without the breakout board, maybe that is an option for you too.

Happy New Year!
Bernd

RaptorSense · Post by **RaptorSense** » Wed Dec 31, 2014 10:27 pm

Hi Bernd,

Henning’s project and his professional execution is superb. I am also jealous of his Jeti implementation. I am gooing to borrow a Jeti system to do mine.

This is my new board. I am just back home after one month, it’s the first time that I am holding it in my hand (or vinger?)

We have chosen to shrink it even further and then a MS5611 is huge. This board is 6mm wide and made for up to 5 pressure sensors (BMP280), an on-board processor and more. We shall see if it will work as expected once the fresh solder paste is delivered.

Happy New Year!
Sinan

mstrens · Post by **mstrens** » Thu Jan 15, 2015 4:27 pm

Carbo wrote: The only thing i thought about, was an idea from Henning (also a Member here), on his webspace:
http://henning.bplaced.net/project_myvario.html
He uses a second MS5611 to reduce the noise. So there seems to be a chance, to reduce filtering and the response time of the vario in OXS. To be honest, i never felt the need to have faster reaction time. But the hardware is still available, so if you want to test it (and to write the code), i am ready.

@Carbo,
I made just some changes to oXs in order to calculate an "average" vertical speed based on the values returned by 2 MS5611 sensors.
To use it, you just have:
- to activate the 2 sensors (VARIO and VARIO2)
- transmit a new field named VERTICAL_SPEED_A (instead of VERTICAL_SPEED)
You can then try to increase the sensitivity in order to reduce the reaction time keeping the noise at an acceptable level.

If you use PPM to select the source for vertical speed, you can also now use this "VERTICAL_SPEED_A" as primary or secondary source.

The new version is available at this link:
https://code.google.com/p/openxsensor/s ... iplex_v3.0

Please note that this version also support (to be tested) the Multiplex protocol. So to test it with a Frsky rx, do not forget to set the line #define MULTIPLEX as comment.

Mayeric · Post by **Mayeric** » Tue Jan 20, 2015 8:18 am

Really interesting thread... I am quite interested in making my attempt in link with the paragliding/hanggliding activity. My main concern now : where (in Europe/France) can you buy MS4525DO and MS5611 sensors on a per-unit basis without them being excesively expensive including delivery ?

maccross · Post by **maccross** » Tue Jan 20, 2015 12:32 pm

Hi

My applause and thanks to all the ones involved in this project and that shared their work.
This is my first openXsensor with air speed reading using the 4525DO from HK:
http://hobbyking.com/hobbyking/store/uh ... duct=62752

I'm getting readings in Alt, Vspd and Spd as can be seen here:
http://i802.photobucket.com/albums/yy30 ... 316627.jpg
http://i802.photobucket.com/albums/yy30 ... 15c491.jpg
http://i802.photobucket.com/albums/yy30 ... 4be7a7.jpg
http://i802.photobucket.com/albums/yy30 ... b634fc.jpg
http://i802.photobucket.com/albums/yy30 ... 6f5e8a.jpg

Next step shall be some air speed tests with the sensor in a pole in my car.
I used version 2.5. It seems to me Temperature (T1 and/or T2) is not any more sent as telemetry data.
Cheers

mstrens · Post by **mstrens** » Tue Jan 20, 2015 1:31 pm

maccross wrote:Hi

I used version 2.5. It seems to me Temperature (T1 and/or T2) is not any more sent as telemetry data.
Cheers

Why do you think that Temperature is not any more sent?

Please note that the Temperature provided by the MS5611 baro sensor is not really meaningfull. It is several degrees above the normal temperature. This is the result of fast reding the sensor.
I did not really check the temperature provided by the Airspeed speed sensor but I expect we should get the same isssue.

Therefore, if you want some accurate tempreature, best is to use a specific temperature sensor. Those sensors cost about 1 $ on ebay (see e.g. LM35 or LM335) and converts a temperature into a voltage. This voltage can then easily be read by oXs (as Volt1... Volt6) and then transmitted as Temp1 or Temp2. As far I know it should work. Please note that you have to take care using the right values for MVOLT_PER_STEP and OFFSET in order to convert the voltage to degree.

If this does not work, please send me you config file so I can look further.

maccross · Post by **maccross** » Tue Jan 20, 2015 4:57 pm

mstrens wrote:Why do you think that Temperature is not any more sent?

Maybe I was expecting the MS5611 temperature available to be sent as in former versions.
I never gave much attention to the MS5611 temperature accuracy, but always thought that having that reading was fun. And with the multiply/divide/offset fantastic configure coeficients any possible corrections due are a piece of cake to implement.
And you are correct, of the 3 openXvario/sensor quickly available 2 gave a temperature reading of 23, and one gave 29 celsius (this is the most correct reading, today is damn hot

). (lots of thermometers in my shop, from regular mercury to turkey, Galileu, thermocouple, IC.. no 2 thermometers give the same reading

)
My interest in temperature is not enough to add a temperature IC.
Cheers

RightRudder · Post by **RightRudder** » Fri Nov 25, 2016 4:10 pm

I am finding the use of the PPM a little confusing. I understand that by using a pot and a switch to multiply by -100 I can adjust the sensitivity of vario1 or vario2 but suppose I want to just use as vario the dTE and be able to adjust vario sensitivity with the switch one way and compensation with the switch the other way by using a single pot. Is it possible?

edit:
Or suppose I use a switch to select which input is used so that I can use two pots one for sensitivity and one for compensation on the same PPM channel in that case one pot controls PPM at say 988-1400uS and the the other controls PPM at 1600-2012uS. Will it work?

Carbo · Post by **Carbo** » Fri Nov 25, 2016 8:37 pm

There are 5 different vario types in oXs, but you have to decide for 2:

#define VARIO_PRIMARY FIRST_BARO // select between FIRST_BARO, SECOND_BARO , AVERAGE_FIRST_SECOND, AIRSPEED_COMPENSATED , BARO_AND_IMU
#define VARIO_SECONDARY AIRSPEED_COMPENSATED // select between FIRST_BARO, SECOND_BARO , AVERAGE_FIRST_SECOND, AIRSPEED_COMPENSATED , BARO_AND_IMU

You can switch between the two in flight with PPM. Positive PPM values switch to vario1 (primary vario), negative switch to Vario2 (secondary vario). This is useful, if you use two MS5611, one connected to a probe, that delivers a energy compensated pressure (e.g. Braunschweiger Duese), the other MS5611 used as a usual vario without energy compensation. Both varios can change their sensitivity with the PPM signal going form 10 to 40% (-10 to -40%). Weight 15, Offset (-)25 in the channel mixer does the job.
Another vario is electronic energy compensated with the airspeed data from an additional airspeed sensor. In this case you have constant sensitivity, but you can control the compensation with PPM going from 60 to 90. Weight 15, Offset (-)75, negative if this is the secondary vario.

IMU-vario and averaged vario are special cases, also explained in mstrens oXs.config.description.h.

A simultaneus control is not needed, because the airspeed compensated vario works with a fixed sensitivity, that can not be changed. OpenTX allows one or two pots, selected with a switch, to control the PPM signal. It depends on your personal preference. oXs can transmit the decoded PPM signal and the sensitivity as a sensor value, to see, if the controls work as expected.

Example from config.h:

#define T2_SOURCE PPM // select between TEST_1, TEST_2, TEST_3, , GLIDER_RATIO, SECONDS_SINCE_T0 ,AVERAGE_VSPEED_SINCE_TO , SENSITIVITY, PPM, VOLT_1, VOLT_2, VOLT_3, VOLT_4, VOLT_5, VOLT_6

Edit: You can change the sensitivity of the vario used for the electronic energy compensation, but the compensation works only with a fixed sensitivity of 50.

RightRudder · Post by **RightRudder** » Fri Nov 25, 2016 10:58 pm

I am not interested in using a tek probe so I don't need to have two GY63 boards and switch between vario1 and vario2. However I do like to use PPM to adjust vario 'sensitivity' depending on whether it is a strong day or a mild evening flight in floaty conditions. At the same time the strength of the energy compensation is something which will vary from model to model and position of the prandtl probe etc. I suppose I could find out what works with a particular glider and then fix the compensation value, but I thought it would be nice if I could adjust both sensitivity and compensation optionally. I tried setting up two curves on a switch so that the input comes from S1 or S2 and follows curve1 or curve2 depending on the switch position. It works very nicely in simulation. I'm just not sure how to get oXs to recognize that negative PPM adjustment (ie 998-1400uS) means change sensitivity and positive (1600-2000uS) PPM means adjust compensation strength. Is it possible to make this configuration?

Edit: I have done some testing. I have two curves and one goes 10-40 assigned to S1 to set sensitivity and the other goes 60-90 assigned to S2 to set compensation. I have Tmp2 defined to read back PPM and I see the value properly on the taranis telemetry. I have set Tmp1 to display sensitivity so when I rotate S1 min-max with SWA back I see PPM goes 10-40 and sensitivity goes 20-100. When I flip SWA and rotate S2 min-max then PPM goes 60-90 and sensitivity remains unchanged. So far so good, but I cannot get PRANDTL_COMPENSATION to show up. I have tried to assign it to different sensor ID's but it is never discovered. I have tried with oXs v2.5 and also with v7.

Carbo · Post by **Carbo** » Sat Nov 26, 2016 6:21 am

If you transmit the AIRSPEED_COMPENSATED vario, there is no difference in the telemetry screen. VSpeed remains the transmitted information. But VSpeed is now "energy compensated". If your plane increases speed, you will see and hear a positive VSpeed change. The only way to test it on the ground, is to puff carefully into the Prandtl probe and listen to the vario sound. If it signals climb, compensation is working.

There is yet no way in the telemetry to transmit a particular dTE sensor and use it for vario purposes. But mstrens oXs method is equivalent.

Btw: i use these announcements, to distinguish the varios.

comp_not.zip: (196.31 KiB) Downloaded 179 times

RightRudder · Post by **RightRudder** » Sat Nov 26, 2016 1:11 pm

Thanks Carbo, I understand what energy compensation is. I have nearly three decades of flying the full scale stuff, so I know how I like my vario to be adjusted and how like it to sound and react to the air. One thing is that vario sensitivity and vario compensation are two separate things and it would be good to be able to adjust them both independently. From reading this thread I understand that you are quite happy with the way the energy compensation works but I'm not sure depending on probe location that it works as well in all installations. One thing is that people here are using the word 'sensitivity' for the vario but it really means more about averaging and responsiveness of the vario. Accurately speaking sensitivity is the domain of the resolution of the sensor itself which is not adjustable. I am guessing that you are saying the current system is set up to require that the 'sensitivity' parameter of oXs be set with the same min and max value so it remains constant and then only the compensation strength is adjustable in flight because the reason being that adjusting the 'sensitivity' affects the processing delay of the baro signal which if it changes would introduce a phase delay between the baro data stream and the airspeed data stream which would mess up the operation of the vario. For sure the processing delay of both streams always has to be identical for the system to work. I'm not sure this is the case with the code at present. There is an adaptive algorithm which automatically adjusts the averaging window longer if raw vspeed is low and shorter if raw vspeed is high. This reduces noise at calm air conditions but I wonder if this introduces phase changes between the baro and total pressure in these two cases. Perhaps Michel can comment. My other problem right now is I can't get the compensation value PRANDTL_COMPENSATION to be transmitted as a telemetry field. Did you ever try it?

RightRudder · Post by **RightRudder** » Sat Nov 26, 2016 4:21 pm

I have the following in config.h

#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 , \
DEFAULTFIELD , VERTICAL_SPEED , 1 , 1 , 0 , \
DEFAULTFIELD , AIR_SPEED , 1 , 1 , 0 , \
T1 , PPM , 1 , 1 , 0 , \
T2 , SENSITIVITY , 1 , 1 , 0 , \
A3 , PRANDTL_DTE , 1 , 1 , 0 , \
A4 , PRANDTL_COMPENSATION , 1 , 1 , 0

And oXs_out_frsky.h says:

#define A4_FIRST_ID 0x0910

The sensor at ID 0x0910 is never discovered by open taranis.

mstrens · Post by **mstrens** » Sat Nov 26, 2016 7:19 pm

RightRudder wrote:I have the following in config.h

#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 , \
DEFAULTFIELD , VERTICAL_SPEED , 1 , 1 , 0 , \
DEFAULTFIELD , AIR_SPEED , 1 , 1 , 0 , \
T1 , PPM , 1 , 1 , 0 , \
T2 , SENSITIVITY , 1 , 1 , 0 , \
A3 , PRANDTL_DTE , 1 , 1 , 0 , \
A4 , PRANDTL_COMPENSATION , 1 , 1 , 0

And oXs_out_frsky.h says:

#define A4_FIRST_ID 0x0910

The sensor at ID 0x0910 is never discovered by open taranis.

Just to see if PRANDTL_COMPENSATION is available (as it should) could you try using another field to transmit it. (e.g. ACCx; please note that when using ACC fields, you probably have to use a multiplier too (100 I think) because openTx divides the transmitted values while dsiplaing it)

mstrens · Post by **mstrens** » Sat Nov 26, 2016 8:00 pm

RightRudder wrote:Thanks Carbo, I understand what energy compensation is. I have nearly three decades of flying the full scale stuff, so I know how I like my vario to be adjusted and how like it to sound and react to the air. One thing is that vario sensitivity and vario compensation are two separate things and it would be good to be able to adjust them both independently. From reading this thread I understand that you are quite happy with the way the energy compensation works but I'm not sure depending on probe location that it works as well in all installations. One thing is that people here are using the word 'sensitivity' for the vario but it really means more about averaging and responsiveness of the vario. Accurately speaking sensitivity is the domain of the resolution of the sensor itself which is not adjustable. I am guessing that you are saying the current system is set up to require that the 'sensitivity' parameter of oXs be set with the same min and max value so it remains constant and then only the compensation strength is adjustable in flight because the reason being that adjusting the 'sensitivity' affects the processing delay of the baro signal which if it changes would introduce a phase delay between the baro data stream and the airspeed data stream which would mess up the operation of the vario. For sure the processing delay of both streams always has to be identical for the system to work. I'm not sure this is the case with the code at present. There is an adaptive algorithm which automatically adjusts the averaging window longer if raw vspeed is low and shorter if raw vspeed is high. This reduces noise at calm air conditions but I wonder if this introduces phase changes between the baro and total pressure in these two cases. Perhaps Michel can comment. My other problem right now is I can't get the compensation value PRANDTL_COMPENSATION to be transmitted as a telemetry field. Did you ever try it?

For Dte Vspeed, oXs takes into account ppm values (if available) as wel for the sensitivity as wel for the compensation.
The calculation is performed in following way:
First the pressure from airspeed is multiplied by the compensation PPM parameter and some scaling factor in order to convert it in a kind of "altitude"
This airspeed "altitude" is added to the barro altitude. This makes a kind of total altitude.
This occurs 50 times per second.
The "total altitude" is then filtererd like for a normal altitude.
It means that oXs applies a low pass and a high pass (exponential) filter.
The difference between the values from the 2 filters gives a vertical speed (when combined with a scaling parameter to take care of the delay between of successive reading of sensors and of the values of the low and high pass).
This vertical speed is still to noisy and so oXs applies a final smoothing factor using the sensitivity parameters.
The sensitivity parameters depends on sesnsitivity PPM values (if PPM is used).
So compensation parameter should not interact with sensitivity generating some phasing isssue.

The Tx can transmit only one PPM value at a time but this is not a problem because for each of the 2 parameters oXs store the last PPM value received.
oXs can make the difference between a ppm value for sensitivity and a ppm value for compensation because each type has his own range (min/max) of values.
It seems me easier to use 2 differents pot (even you could use only one pot) , one for sensitivity and one for compensation.
You need a switch to force the Tx to transmit or the sensitivity PPM or the compensation PPM.
So you should use 2 lines in mixer list:
- one to convert the pot value into sensitivity PPM value ; this line is active when switch is ON
- another to convert the (other) pot value into compensation PPM value; this line is active when switch is OFF.
When you move the switch from ON to OFF , oXs will keep the last sensitivity PPM value for future calculations.
On the opposite, when the switch goes from OFF to ON, oXs will keep the last compensation PPM value for future calculations.
I hope this is clear enough. If not, just ask for more explanation.

RightRudder · Post by **RightRudder** » Sun Nov 27, 2016 1:32 am

Initially I tried with sensitivity on accX and compensation on accY but when I didn't get the compensation I suspected it wasn't allowed on Acc so I tried using temp and then A3,A4. Wherever I put it, it doesn't show up in discover sensors.

RightRudder · Post by **RightRudder** » Sun Nov 27, 2016 1:54 am

I have done something similar but using curves. I have 3 curves each with 2 points. Curve 1 goes from 10 to 40 and curve 2 goes from -10 to -40 and curve 3 goes from 60 to 90. The mixer for Ch8 uses curve 1 and pot S1 when switch A is up. When switch A is middle curve 2 is used with pot S2 and when switch A is down the mixer uses left slider with curve 3. I also have a logical switch and special function to momentarily override Ch8 to 100 for reseting the airspeed. have telemetry fields for CH8,PPM,SNS and CMP. The fields for Ch8 and PPM show agreement and reflect the correct values when I move switch A and the pots. The SNS field goes from 20-100 when switch A is up while PPM shows 10-40. With Switch A in middle SNS goes 20-100 while PPM goes -10 to -40 and when Switch A is down SNS doesn't change but also CMP shows nothing when the left slider is moved however CH8 and PPM do show a range from 60-90. I don't think oXs is outputting the value for PRANDTL_COMPENSATION.

openrcforums

New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)

Re: New beta version of openXsensor (=openXvario)