Introduction to the openx vario/altimeter

[rainer]

it is already hard to wait that month if you realy want to start with a project. but if you then get nothing or the wrong piece....Arrrrrrggg!
i´m waiting for 4 more. that should arrive next week or so. You want one?

[jhsa]

yeah, I would, thanks for the offer Rainer.. but I need a refund from the seller.. this sensor was already a bit out of my budget
But I was really excited to get started. This even got me into gliders again.. and I like the planes as noisy as I can get. but was really looking forward to it as I like this project

João

[jhsa]

Rainer, currently we are using pin 2 of the arduino for the PWM signal from the receiver..
Isn't that pin also used for the cell voltage??

Thanks

[jhsa]

AAHH, ok.. sorry.. didn't think about it.. I'm too new to all this arduino stuff. even if I built my own.
Hmmm, that doesn't mean I know how to use it..

João

[rainer]

your are right. and additional comment could have done its magic...

[rainer]

I build another openXvario this morning. this time i unpacked a D4R-II and directly connected the oXv to it. Then it all went into one shrink tube.

it doesn't add much weight or size, but all of the new functionality. and if you use a small DLG or similar, you save all the additional Cables to connect power, RX and PPM SIgnal.

Rainer

[jhsa]

it looks good..

[Rob Thomson]

Very nice!

Sent from my GT-I9300 using Tapatalk 2

[rainer]

just did a measurement.
A "normal" oXv consumes 21mA
the oXv + D4R-II combo consumes about 80mA

[RightRudder]

Very nice indeed!

[Rob Thomson]

Well...

Spent some me quality time with the various today.

It is very good. Certainly let me know about a thermal I had one visual clues of!

The only thing that is really annoying me is that the altitude does not default to zero.

I know in can reset this on the tx.. But I always forget.

Is there a magic way the various can assume zero on power up?

Sent from my GT-I9300 using Tapatalk 2

[rainer]

Sure, look here:

Code: Select all

#define FORCE_ABSOLUTE_ALT // If defined, the height offset in open9x will be resetted upon startup, which results
                           // in an absolute height display in open9x . (You can still change to a relative display
                           // by pressing [MENU] in the telem.screens
                           // If not defined, open9x will use the first transmitted altitude as an internal offset,
                           // which results in an initial height of 0m

comment out that line and open9x/tx will learn the offset and start with 0

[RightRudder]

I think I may finally receive my arduino this week. I ordered it on Feb 12. ! The sensors (ordered at the same time) came weeks ago.

[RightRudder]

Well that wasn't so bad. I tried for a while to program the arduino with a USB asp but eventually gave up in disgust. Luckily I had a little board lying around with a prolific USB to serial chip and it worked to program the arduino because I don't have an FTDI basic. Since I want to use the FAS-100 and there is currently no support for it with the oXv so i had no choice but to use the analog out option. I made a little pictoral of the process in case anybody wants to use oXv along with a FAS-100 and a frsky D8R-II receiver.
First thing to do is remove the case of the D8R and unsolder the 9 pin header which would normally connect to A1,A2 and the serial Rx. Then solder the yellow rx wire and black ground wire to the telemetry connection points as shown in the photo.

[RightRudder]

Next the oXv is prepared. I did it pretty much as per the instructions on the wiki except I chose alternate locations for the power and ground to the MS-5611 pressure sensor board.

I had a 33uF tantalum cap which was fairly small so I used it for the analog filter. I want to try the in flight tuning of the kalman coefficients so I connected the PPM input to CH8 of the rx and mapped this to the pot P2 on the 9x.

[RightRudder]

I don't have a clear photo but the next thing I did was solder the analog out (blue wire) to the A2 input beside the yellow wire on the D8R-II rx and then ran the wires for Vcc, Gnd, and PPM around the edge of the D8R board and soldered to the points on the back of the header for the servo connections.

Next I put some mylar as insulation between the oXv and the D8R board, and I was also worried that the reset button could be activated so I added a small piece of wood at the end of the oXv between the boards to revent this. It can be seen through the shrink wrap in the photo:

Open a hole in the shrink wrap for the F/S switch on the D8R and mark the servo plug orientation on the side of the shrink wrap for later reference. The channel order also.

[RightRudder]

At last it is all done. The rx with vario attached actually is smaller than before the case was removed. Here it is mounted in one of my gliders:

Seems to be working good. I have set the settings to -3, -0.5, +0.2, +3 for testing at home otherwise the vario is chirping falsely. I'll adjust the positive inner threshold from +0.2 to 0 or a small negative value for flight testing. So far so good. One question though in the telemetry settings on the 9x does it matter what I put for the A2 range and offset? How does one calibrate the analog input to actual m/s climb rate?

Thanks again Rainer. This is awesome. It has long been my dream to have an audio vario in a model glider. Now I can use this in the mornings to sample the air before I decide if it is worth dragging the big stuff out of the hangar!

Joe

[rainer]

Hi Joe,
great Post and thanks for all the Pictures!
The telemetry settings for the A1/2 input do matter! The offset should be set to a value represent 0m/s vertical speed. so if your plane is lying on the table, you would have to set the offset to a value where you reach a value around 0m/s on the display.
You should adjust the range to reflect the output voltge of the filter. As the oxV will by default output a voltage 0f 0 to 3.2 volts for vertical speeds of -3 to +3 m/s the range should be set to 6m/s.

Depending on the sensibility you set in the code or in your case via the pot on the tx, you should normally be able to set a smaller quiet zone than -0.5 ..+0.2. I had some problems with interference for my attempt to mount the oXv directly on the receiver boad, so it might be that you are experiencing the same problem here.

As you are not using the RS232 connection you should comment out the

// #define PPM_ProgrammingMode

and define the following line:

#define PPM_AllwaysUsed

Have fun,

Rainer.

[RightRudder]

Yes I commented out all of the serial output possibilities and set the PPM to always. It is obvious the remote gain control is working by just lifting the model up and down inside the house with my hand with different settings of the pot. I did have the wrong (too high) value for the range on A2. I wonder if that also could be a reason the vario is nervous. To give me an idea of what should be achievable if there is no noise problem from the receiver what can you typically set it to?

[rainer]

My default test setup is normally -3 -.1 +-.1 +3 for the Limits.
When i was testing with the analog output option i used a range of 6m/s with the offeset adjusted to a point where the noise was about equal to the positive/negative side.
With the filter set to an unsensitive setting this would work without false alarms. With about medium filter, this could create a few false indications.
Right now i don't have a unit with the analog option available for testing so i can't re-test right now.

[dinamich]

This thread has sparked my interest. So I have ordered Arduino board and barometric sensor and am now waiting patiently for postman.

In the meantime I have played with noise filters. I used simple Processing sketch to generate a sine wave signal with interpolated random noise. Then I run this noisy signal trough three different filters to see their performance.

First picture shows example of signal and filter outputs:

• white is clean sine wave
• red is sine with random noise - this is the input to all filters
• yellow is Simple infinite impulse response filter (IIR)
• turquoise is moving average filter
• purple is Kalman without prediction (same code as yours)
• item 1 shows IIR filter coefficient
• item 2 shows how many past samples are averaged in moving average filter
• item 3 shows Kalman filter coefficients

Playing with different filter coefficients for this input signal I have found out:

• IIR and Kalman without prediction give exactly the same result - when coefficients are properly adjusted
• since Kalman requires more computation, and IIR gets the same result, it is better to use IIR filter
• Moving average filter look like it has slightly less delay than IIR filter for the same smoothness of output signal (see first picture). But it requires more RAM and CPU cycles to compute.

Second picture shows a example where IIR and Kalman filters give same result.

Kalman coefficients adjusted to a value that produces almost the same output as IIR. This was intentional, so that yellow signal is still visible. If I wanted I could completely cover yellow signal with purple.

For IIR filter I used very simple equation:

The only constant is k
O is output
x is input (sensor data)

Output is O = O_previous * (1 - k) + x * k

[hr]

I will probably wait for hardware to arrive and then do some more testing on real input signal from barometric sensor. Here are a couple of ideas that I plan to implement:

• Try to get readings from barometric sensor as frequently as possible. Maybe use the time between start of conversion and reading of result for something else (filtering, sending data...) instead of just waiting doing nothing.
• Test if reducing oversampling and as a result getting faster readout from sensor (more data points per second) improves or worsens performance
• Do not read temperature of barometric sensor every time the pressure is read. Once a second is plenty.
• Do the filtering on raw sensor ADC value an only preform complicated conversion to altitude when necessary.
• Try some other filter to get lower delay and smoother signal

Keep up the good work. I will keep you updated on my progress and will release all my code to public.

[RightRudder]

Moving average takes more cycles to compute than IIR? Really? Is this due to C implementation? I work only in assembler so I don't know the details of compiler optimizations but I was really surprised to read that bacause I use averaging filters a lot and they do require memory but the processing is lightning quick at least when coded in assembler.

[dinamich]

Well, it depends on number of moving average samples. But for each sample you have one addition. So for N samples we get N additions and one division. Meanwhile IIR always uses two multiplications and one addition.

Here is the Processing sketch that I used in my previous post.

[rainer]

Hi dinamich
I already tried decoupling the measurement of temperature from pressure. it did not work as expected and created much more noise. It seems to be very important to use the same point in time for both measurements as the noiuse is synchrously between these two values.
The moving avaerage is the filter i used, before switching to the kalman. The main problem is the slow measurement rate. in order to create a more or less stable reading you would need a bigger amount of samples, which increases the delay quite heavily. as we have a delay of at least 10 to 12 ms for each measurement, and we want to transmit a new calculated value every 100ms, this would decrease the number of available values to something lless than 10 samples.
the calculation of the climb speed is again more complicated, as we need a bigger amount of valid height measurements in order to calculate the vertical speed. and if we want to calculate a vertical speed every small calculation error multiplies if we want to get climb speed changes with less than a second delay.

It might be worth to attempt to use the sensor delay time for the processing part though.

If you want to visualize the sensor data / filter data the needed code to ouput the data via the serial interface is already in the sketch, i did the same when implementing the kalman filter. i should have a basic sketch to visualize the data on my hdd if you are interested.

Rainer

[dinamich]

I find it strange that that the temperature must be read so frequently. The real temperature of sensor certainly can not change that quickly. What I think is causing this is that some low frequency noise is affecting ADC inside sensor. When you are reading pressure and temperature every time, you also get almost the same noise level each time (in both measurements). This probably then cancels out some of the noise.

What I will try to do:
* read temperature every second (or max 10 times per second) and filter it. Then use filtered value in all calculations.
* read pressure as much times per second as possible, filter it and only calculate altitude when necessary (probably every 200ms when we need to send a reading to FrSky RX).
* play with electrical filters on supply side of pressure sensor - this is what is probably causing additional noise in sensor readings.
* my aim is to do such high level of filtering on raw data, that each time I calculate altitude form filtered data it has the value that is directly usable: as altitude, and as rate of climb (subtracting previous altitude)


If it's not much trouble, I would like to see your sketch for visualization/serilal data sending. But in any case I will probably write/modify my own.

[bertrand35]

Just a little post to tell Rainer that I tested 3 varios during the week-end with the Taranis radio and his one is the best (by far!)

[noobee]

i think if you maintain a fixed-sized deque and the sum of N samples, then, after the initial N samples, the subsequent computation would be O(1) instead of O(N).

sum -= oldest
sum += newest
avg = sum/N

Well, it depends on number of moving average samples. But for each sample you have one addition. So for N samples we get N additions and one division. Meanwhile IIR always uses two multiplications and one addition.

Here is the Processing sketch that I used in my previous post.

[bertrand35]

This exact code is already available in openTX (function evalVario) ... in case it helps!

[RightRudder]

Just a little post to tell Rainer that I tested 3 varios during the week-end with the Taranis radio and his one is the best (by far!)

Care to comment which varios were tested? I'm just curious.

[Rob Thomson]

Winged shadow.
Openxvario
New frsky vario.



Sent from my GT-I9300 using Tapatalk 2