OpenXSensor SPORT Interface

[MikeB]

Yes, those are the interrupts.

Mike.

[NeilRogers]

Michel,

Enclosed is a live data session from the slope using your software, I've not had a chance to do much analysis yet.
I changed the log recording to 100ms
Just let me know if you want some more data or program changes I'm on the slope quite a bit.
Neil

[mstrens]

Neil,
thanks for the data.
I will further look at them but I already see some strange results.

What is you feeling about the sensitivity of the vario? Does it react quickly enough?

Michel

[NeilRogers]

Hi Michel
Unfortunately conditions and wind noise meant I couldn't assess the vario audio too well.
I'm current using run parameters of -10 -.5 .5 10,

I still think altitude drift up on my sensor.

I ll try and do some testing but weather looks poor over the next few days

Neil

[Bruneaux]

As far as finding a way to deal with the TWI interrupts there is an I2C library that was developed to NOT use interrupts. It was develop in 2011 and 2012 and polls for the data rather than waiting for interrupts.

Since the Wire.h library is basically 'blocking' (when asking for data from the sensor) then the use of polling vs interrupts is mostly of no consequence.

Here is the info. And there is a ZIP of the library near to bottom.

http://dsscircuits.com/articles/arduino ... brary.html

I don't seem to be seeing the problems with my sensors (not using the vario) so I'll hold on to this library just in case. I have seen a tiny anomaly in my tachometer (interrupt driven) but I can't say that it makes much of a difference.

Bruneaux

[mstrens]

Bruneaux,
thanks for the info about TWI interrupts but I don't get issues anymore with the function micros() since I changed the code related to the transmit (in "case TRANSMIT :" ,I do not exit the interrupt anymore before 8 bits are send).

Michel

[mstrens]

Neil,
When I analyse your log file, I see that:
- vertical speed is normally positive when Altitude increase (and the opposite). This seems OK. Still the value of vertical speed seems NOT OK compared to the change of altitude per enlapsed time. I would have to check but perhaps you have an setup on Taranis that is Imperial and not Metric. In such a case, it could be that Altitude is converted by the Taranis but not the climb rate. I will try to make a test about this. OpenXsensor does not know the Taranis set up and transmit always the altitude in meter and the vertical speed in meter per second.
- even if you set up the Taranis to log telemetry every 0.1 sec, Taranis can't do it exactly and you get only about 9 logs per second. So, you should take this into account when you calculate a climb rate in the XLS.
- sometime during more than 0,3 sec there are no change in the altitude recorded in the log. Most probably this results from losses of some telemetry data because, normally, openxsensor calculates Altitude every 18 millisec and send it most of time every 0,04 second and in the worst case after about 0,15 sec. I do not know why.
- vertical speed is based on the difference between 10 calculations (NOT transmission and NOT recording in the log) of Altitude. A new value should be calculated every 180 millisec. A new value should be transmitted approximatly every 0,2 sec. In the log, I see quite big differences (sometime a new value after 0,1 sec, sometime only after 0,7 sec). I do not know why.
- due to the way vertical climb rate is calculated (average of 10 Atltitudes but all of them are not in the log), the several delays generated by transmission and logging, the losses of some data, it seems me not relevant trying to compare the vertical speeds calculated on one side by the openxsensor and on the other side based on the log.

In order to increase the accuracy of openxsensor, I made several changes I will explain in a next post.
I will join this new version in the next post.

Michel

[mstrens]

Neil,

Here the new version. Changes concern :
- Vertical speed is calculated each time a new Altitude is calculated (so around every 18 millisecond)
- in order to avoid big changes form vertical speed between 2 calculations, I apply an exponential smoothing. So vertical speed is :
96% X previous vertical speed + ( ( 1 - 96%) X (New altitude - Previous altitude) / ( enlapsed time between 2 pressure reads)).

With a parameter = 96%, it smooths the data nearly like an average on 20 values but changes ares faster reflected.
NB : It is possible to adjust this parameter if the sensitivity has to be increase/decrease.
- I transmit the calculated vertical speed as fast as possible (in best case every 22 millisec, in worst case it should be around 100 millisecond). So if some data are lossed in the transmission, the Taranis should still get as fast as possible the best actual value and produce the sound accordingly.
- I therefore transmit the Altitude less often (normally once every 400 millisec more or less)

I made a test at home with this version.
I go up and down about 2,5 meters 3 times (in 6-10 sec each time).
I put the log in attachement.
The first movements at the beginning of the log occurs when I stand up and open a door. Don't look to much at them.
The calculated vertical speeds seems me OK. It is about 0.3 meter/sec up and -0.2 meter/sec down when I go up and down.

It would be nice if you can test this version and give back some feeling about the sensitivity.

Michel

[NeilRogers]

Hi Michel,

Although the taranis is set for feet not metres, all the logging is recorded in metric.

I'm just back online, the weather is very extreme in the SW England I've just got the mains power restored.

I've program the sensor with your new version and I'll run live asap.
Static testing here looks good vspd values and audio wise, I've change parameters to -10 -0.1 0.1 10 it looks like it would be ok with the small dead band.

Weather not looking good tomorrow and the next window will be Friday, unfortunately work is in the way.

Thanks neil

[nickk103]

Given the good work you folks have been doing, thought I should share some findings. I have been doing some intensive testing of the SPORT telemetry data between an XJT SPORT module interface and an X8R's SPORT interface. So Tarannis is not in the picture. My interest is purely in the reliability of the telemetry data stream. Now I realize that the telemetry stream is essentially informational data as opposed to "mission critical" data, but I still would like to assign a confidence level to the quality of the data stream. By way of background, I have 3 physical I2C devices interacting with a single sensor (as seen by the X8R). So the sensor is an I2C master but a slave on the SPORT serial "bus". The sensor uses the Atmel-328P clocked @ 20MHz. I am currently seeing no timing or interrupt issues. I have monitored the data delivered by the sensor, in response to polls from the X8R, and all looks good. On the XJT end I am seeing an unexpectedly large number of CRC errors. Hence, the test cases below. Note the focus of my tests are on the 4 octet sensor data, followed by the CRC. Case 1) is just a baseline test and works as expected. Case 5) is just a mess, and packets like these would normally be just thrown away as bogus. However, these test cases are very consistent and repeatable so I can't account for it in any of my code nor can I blame random RF issues. Why would the setting of a single MSB within a single octet of the user data cause such massive data alignment problems? I am not going to speculate about whether the bug is in XJT or X8R firmware, I have no real way of knowing. What is clear, is that I am having to throw away a lot of good telemetry data, which is unfortunate. So this is just an fyi.

Regards,
Nick

Case 1)
Sent: content.data[] = {0x01, 0x02, 0x03, 0x04};
Rcvd: [0xfd][0xfb][0xf9][0xf7]-[0x55]

All octets are OK & the CRC (of entire packet) is correct. The 3 octet packet preamble is not shown for clarity.

Case 2)
Sent: content.data[] = {0x01, 0x02, 0x03, 0x80};
Rcvd: [0xfd][0xfb][0xf9][0xff]-[0x53]

Only 1st three octets are OK !?

Case 3)
Sent: content.data[] = {0x01, 0x02, 0x80, 0x04};
Rcvd: [0xfd][0xfb][0xff][0xdf]-[0xa]

Only 1st two octets are OK !?

Case 4)
Sent: content.data[] = {0x01, 0x80, 0x03, 0x04};
Rcvd: [0xfd][0xff][0x7e][0x5f]-[0x5]

Only 1st octet is OK !?

Case 5)
Sent: content.data[] = {0x80, 0x02, 0x03, 0x04};
Rcvd: [0xff][0xbf][0xf7]-[0x53]-[0x0]

One octet is missing, the others are incorrect. CRC is in the wrong position & the trailing null padding is bogus. This packet is just a mess !?

[mstrens]

Nick,

I will make a test sending the same data as your but using Openxsensor, X8R and Taranis (which normally use internally an XJT module) and I will keep you inform.

I would like first to be sure that I understand correctly what you are dooing.
By example, in case 1 your devise send 3 bytes (0X10 and 2 bytes for the device ID) , then the 4 bytes of data (0x01, 0x02, 0x03, 0x04) and 1 byte as CRC.
On the SPORT from the XJT module, the first byte of data (normally 0x01) is transmitted as 0xfd.

This means that the signal is inverted.
I think that SPORT protocol uses an inverted signal (e.g. the start and stop bits must be at level HIGH for the SPORT). This is not the most common practice for a serial port.

I presume you should add an inverter (hardware or software) on the signal comming from the XJT.
Hope this help.

Michel

[Bruneaux]

Mike and Michel,

I am just wondering if there has been any consensus on which approach to the problem (interrupts being missed) will be committed in the next release.

Bruneaux

[nickk103]

Michael,

Thanks for your response. Please see my comments.

>I will make a test sending the same data as your but using Openxsensor,
> X8R and Taranis (which normally use internally an XJT module) and I will
> keep you inform.

Many thanks, that would be appreciated. An independent test would be helpful. Keep in mind that in your testing you will not be able to see the lost packets.

>I would like first to be sure that I understand correctly what you are doing.
>By example, in case 1 your devise send 3 bytes (0X10 and 2 bytes for the device ID),
>then the 4 bytes of data (0x01, 0x02, 0x03, 0x04) and 1 byte as CRC.
>On the SPORT from the XJT module, the first byte of data (normally 0x01) is transmitted as 0xfd.

You are correct though I would not use the term device ID since these two octets are passed end-to-end and play no role in transmission/reception. They are there to implicitly disambiguate the user data and type. I know you already know this but I just wanted to be clear that these two octets play no role in polling the physical device.

>This means that the signal is inverted.
>I think that SPORT protocol uses an inverted signal (e.g. the start and stop
>bits must be at level HIGH for the SPORT). This is not the most common practice
>for a serial port.

Correct. As long as the data is encoded consistently then it can be decoded.

>I presume you should add an inverter (hardware or software) on the signal coming
> from the XJT. Hope this help.

Since I have full software control at the XJT end, I do software inversion. However, if octets are missing as in case 5) I'm stuck. I should add that at the XJT end, I use a ttl to usb cable which does introduce one more variable. I am looking into eliminating that variable.

Regards,
Nick

[mstrens]

Bruneaux, Mike,

There is no consensus about a new release (as far I know).

I do not know the exact reason of the missing interrupt leading to wrong values returned by micros(). I am not sure that they are related to TWI.
I noticed that when I change the code inside the "case TRANSMIT : " (see previous post) I do not get the issue anymore.
The code that I proposed is quite simple and seems safe ( it is better to always avoid interrupt while transmitting a byte).
So why not including it in a new release?
I propose that Mike decides on it because he is the one who write the original code.

The new release should include 2 other changes made by Mike:
- the byte stuffing (0x7E, 0x7D)
- the code regarding "if (micros()>lastmicros+9000){" (and a second similar line) in the MS5611.cpp file. (to check if there are no similar changes in other files)

On the other side, I worked on another version for the SPORT protocol which:
- transmit not only altitude and vertical speed but also 2 voltages (VCC and an external one - based on voltage divider) according to a setup
- transmits the data as soon as possible depending on pooling and data availability. Each type of data (altitude, vertical speed, ...) get his own flag "available"
- calculates each data continously (without waiting than a previous value has been transmitted). If a new value (on a specific type) is available before the previous one has start being transmitted, then the new value replace the previous one ( = priority to the latest value)
- calculates the vertical speed as fast as possible (each 18 msec instead of 360 msec about) using an exponential smoothing
- transmits the vertical speed more often than the altitude (and voltages) in order to get a better vario sound.

Still this version is not candidate for publishing on github because:
- it has not yet been tested live in a glider to validate the way vertical speed is calculated. Neil should probably test it next weekend.
- it does not contain anymore lot of code for hub protocol. This code should be added again if only one version must be maintained.
- not all data allowed in the hub protocol can already been transmitted via SPORT based on the setup in config.h file.
- I read that Kilrah already had a version to transmit more data (perhaps all) in the SPORT protocol. This version is perhaps better than mine.
- I do not update some data that could be transmitted (like max and min vertical speed).
- there is a lot of code related to DEBUG to remove
- some comments are in french and not in english

I do not know who should decide what could be set in a future release to be published on github.
I am new on the project and I am just learning programming in C on micro.

Anyway if someone is interested, he can already check/test my version which is available as attachment in a previous post from Sat Jan 04, 2014 9:20 pm.
I will appreciate any feedback.

Michel

[mstrens]

Nick,
I can't do exactly the same test as you did but I changed the code of an openxvario in order to let him send the folowing set of data (nearly you case 5) :
0x10, 0x10 , 0x02 , 0x80, 0x02, 0x00, 0x00 and a CRC that openxvario calculates.
On the Taranis display I get on field VFAS ( =field for data ID = 0x210) the decimal value "64" which is equivalent to 640 (because one digit is not displayed).
640 decimal = hex 00 00 02 80.
So it seems me OK.

I presume that the error you get result from inverted signal on XJT.

Michel

[nickk103]

Michael,

Thanks for the test results, it's one more data point for me. I intend to focus on the XJT end. We shall see.

Nick

[MikeB]

I haven't had time to do much on this. I'll need a few more days on other things, then I'll pay more attention!

nickk103: The SPort signal is inverted, so idle is low, start bit is high, data inverted and stop bit low. If you put this into a UART, it won't synchronise properly and you won't simply get inverted data.

Sent: content.data[] = {0x01, 0x02, 0x03, 0x04};
Rcvd: [0xfd][0xfb][0xf9][0xf7]-[0x55]

If you got inverted data, you should expect to receive [0xfe][0xfd][0xfc][0xfb]
so I don't think your setup is valid, you MUST invert the signal before putting it into any UART (hardware or software).

Mike.

[nickk103]

Mike,

I wasn't expecting simple bit inversion to work, but I was expecting two's compliment decoding to work consistently. I had not factored in the ftdi chip in the USB connector. Eliminating ftdi from the setup appears to have done the trick.

Nick

[nickk103]

Well it's great to be finally getting consistent heading,altitude,pitch,yaw & roll data out of the SPORT interface. No more blaming alpha particles

Nick

[NeilRogers]

Hi Michel

I managed to get out to the slope a day early.

The direction wind was pretty bad for flying with crosswind, but ideal for testing the vario operation, there were big areas of strong lift and heavy sink varying locations as the direction varied.

I had a dead band set to - + 0.5 the vario audio worked extremely well and reacted really quickly to the sink and lift conditions.

Overall it worked excellently.

The only issue I can see on my sensor is the positive altitude drift, but it does not seem to effect the vario vspd operation.

I've not had a chance to analyse the logs yet

Thanks for your software Michel

[NeilRogers]

Hi Michel

I ve run some more live tests this afternoon.

I've ordered the SPort gps just available this afternoon from T9 in uk, so shortly I'll be able to do direct altitude comparisons.

Neil

[mstrens]

Neil,
thanks for the test results .
I had no time yet to analyse them. I will do it begin of next week.
The most important is that you found that it works fine.

On my side I got the opportunity to fly yesterday with the oxs in a small glider and quite light wind at slope.
I found that the oxs gives correct information. I had a set up -0.3 +0.3 on the taranis and I got no false sound and a quite fast reaction time.
I imagine that I could even change reduce the dead band down to -0.2 +0.2.
It seems me much better than the high precision vario from Frsky.

During some tests at home I also noticed an altitude drift.
I think that the reason is because the sensor needs some delay to get a stable temperature.
The program queries the sensor about pressure and temperature as fast as possible and this increase probably the temperature of the sensor at the beginning before the temperature become stable.
In theory the sensor provides parameters to compensate the temperature drift but it seems that it does not compensate well at the beginning.
I already put a wait time of 3 seconds at start up in the program so oxs do not send immediately the altitude and vertical speed.
Perhaps I have to increase this delay.
I imagine that this issue could easily be solved if the receiver is switch on some seconds before the Taranis is switch on (or if the taranis is swithch off and on after some seconds).

On the other side, I continue to look for improving.
I saw that the sensor is quite noisy. There are already some filters in the program to reduce the noise and they work quite well.
Still the noise reduction could, normally, be improved if the sensor are read more often.
In the version you test, the sensor was read every 18 msec.
I made new changes and I could reduce the time down to 11 msec.
Then I discovered that the temperature returned by the sensor had a much bigger impact than I expected.
As the program was reading the sensor temperature with a very low precision, I decided to read whith hight precision.
I think I got good results but the delay become 19 msec.
I will further investigate if it make sense to read the temperature sensor with high precision but less often (e.g. once every 10 pressure reading) and applying some filters on it. Then I hope to get a delay around 11 msec again with nearly the same precision .

I am checking too if it is possible to apply better filters to calculate the vertical speed. I found something perhaps usefull in another project "paparazzi".

I will keep you inform.
Michel

[MikeB]

I've just done an investigation regarding compiling the Arduino code in general. I've found that if I have a copy of the Arduino library file "wiring.c" (actually as "wiring.cpp" in the project, I can override the default interrupt routines for timer0 and the routines millis() and micros() with my own. The same should be true for the I2C code, just not tested that yet.
One of the reasons for trying this is it is then possible to include the option ISR_NOBLOCK in the interrupt. This causes interrupts to be immediately re-enabled at the start of the interrupt, thus allowing other interrupts in.
It also means we can have full control of the code, without using Arduino library routines, but still allow the use of the Arduino build/download mechanism.

As time permits, I'll follow this up.

Mike.

[nickk103]

Mike,

Just an fyi. I have pretty much given up on using the Arduino-IDE and now use Eclipse+avr plugin exclusively. My decision was based (partly) on the need for better tools and productivity (refactoring etc.), but also the need for more control over the Arduino Library routines. I use the library routines for both ARM and Atmel based projects. So managaing the cross development toolchains can get to be a challenge in the wrong environment. I routinely override default implementations to accomplish what I need to get done. Most importantly, unlike the Arduino-IDE, I don't rebuild the .o files every time I need to generate a new .hex file. I simply link my code against a pre-built static Arduino library and can control much more closely what goes into the library (given the inherent problems associated with a mix of .c & .cpp source files.

Nick

[MikeB]

I like that idea in general, but there are (many) users of this that only know/have the Arduino-IDE. So to keep this easy for them I'm trying to work round it.

Mike.

[NeilRogers]

A little bit of interesting info

I've just received the gps and static tests no movement shows the linear drift of altitude of the oxs with Michel's software in the spreadsheet and the gps varying randomly.

Interesting the gps and SPort oxs updated the taranis data (r2923), the frsky HiVario interfered with gps and no data was rx from either sensor.
Note frsky hiVario works on its own, but interferes whether 1st or 2nd on the daisychain.

Unfortunately its looking bad for any live tests this week or weekend weather is rain, rain and more rain

Maybe I get some reading time on the hardware instead.

Neil

[mstrens]

Neil,
Thanks for you data.
About the altitude drift, the most logical explanation would be that the atmospheric pressure changes over time.
Still I presume that that is not the only reason because the drift is so big with your oxs.
I notice 7.5 m after 10 minutes and 13 m after 23 min.

I made several tests today.
Each test goes over 10 min enlapsed time. The sensor stay on the table during the 10 min.
A test with the original oxs program gives a drift of 2 m after 10 min.
The same sensor with my program gives about 1.5 m.
Idem but reading the sensor once per sec instead of 50 reads/sec gives 1 m.
Using a second sensor with my program and 50 reads/sec gives for 3 successive tests 2,5 m, 2 m and 1,5 m.

I made the test sending directly data from the sensor to the PC.
So I was able to know the sensor temperature.
I noticed that the temperature of the sensor increase continously over the 10 min (e.g. going from 20 up to 27 degree Celcius).
If I decrease the frequency of reding the sensor from 50 down to 1 per sec, the drift in temperature (and in altitude) is reduced.

There is a strong relation between the pressure and the temperature returned by the sensor.
The sensor contains some calibration parameters to compensate the impact of temperature on pressure.
The oxs program takes them into account but I presume that the calibration values are not accurate enough to compensate correctly.

I presume that those parameters are worse for your sensor than for the 2 sensors that I used for my own test because I get less drift than you.

Do you have another OXS to make another test.

I do not see a solution for this issue except than applying a correction on the calibration in the sensor.
The main issue is that those corrections are complex to define and are specific to each sensor.
It means that for each sensor, some tests should be performed and the program adapted.

I would be usefull if other users could communicate their experience.

Michel

[mstrens]

Here the result of some tests/changes I made.

I looked if it was possible to improve the already excellent oxs regarding the variometer function.
I tried several things:
-1) increase the frequency of reading the sensor in order to get faster reaction out of Kalman filter:
- 1a) start already the process for reading a new altitude even if the previous altitude was not yet transmitted over the SPORT (done and OK)
- 1b) as soon as a pressure and a temperature are read, start immediately with the order to read a new pressure because program has to wait 9 millisec to get an answer. So, do not perform complex altitude calculation as soon as a pressure and a temperature are read but perform those calculations during the wating time for the sensor. Done and OK : this save about 6 millisec on a loop of 18 millisec.
-2) avoid big variations from the temperature used to calculate the pressure. I noticed that the temperature was read from the sensor with the lowest resolution. Therefore, when the value change, it change a lot and this create extra noise on the altitude that has to be filtered. I tried several ways to improve this.
- 2a) increase the resolution on A/D temperature. It is easy but has a drawback because it require 9 millisec instead of 0,6 millisec. So it goes against target 1
- 2b) apply a smoothing function on the temperature returned by the sensor before calculating pressure and altitude.
- 2c) combine 2a and 2b : increase the resolution but read the sensor only once on 10 iterations and interpolate in between.
After several tests, I kept the solution 2a (highest resolution, temperature read as fast as pressure, no smoothing on temperature).
-3) calculate a vertical speed each time new pressure and temperature are read. In original program vertical speed was calculated only once every 20 pressure/temperature and the value was the average.
I applied a smoothing function (similar to the Kalman filter) on the vertical speed. This reduces the noise on the vertical speed in the same way as the original Kalman filter did it for the altitude.
It allows sending more ofte a realistic vertical speed to the transmitter via the SPORT.
-4) replace/change Kalman filter.
I noticed that the already implemented Kalman filter gives exactly the same results as a more simple smoothing function after about 300 iterations.
I tested the (much more complex) Kalman filter used in the project Paparazzi. This project uses a model which integrate velocity and acceleration on top of altitude.
The results were not better, so I did not keep it.
I tested an Alpha/Beta filter which has a similar complexity as applying 2 apart smoothing (first one on altitude and next one on vertical speed).
The Alpha/Beta filter gives similar results as 2 apart smoothing.
So at the end, I opted for 2 smoothings because it is easy to implement and to understand.

I made 2 tests with the same hardware to compare the new program and the original one.
The results are in attachment.
In each test, I start the sensor on a table, wait about 10-20 sec , go 3X up and down about 2,5 m in 5-6-7 sec, stay at the same level 5-10 sec between each up/down.
So the vertical speed should be around 0 , +40 cm/s , 0 , -40 , 0 , +40, 0 , -40 , 0 , +40 , 0 , -40 , 0.
In practice, it should be normal having some "noise" around those values because the sensor is noisy, the pressure even at home is not 100% stable and I did not move up and down at constant speed.
It is quite easy to reduce this noise by increasing the filters but it is important to check that this does not introduce a big delay between a movement and change in the vertical speed.
For those 2 tests I used the same filtering set up (= the default value of 300 for the kalman gain).
The attachment gives the results.
There is one sheet per test.
Each sheet have 2 charts.
- the first one gives the Altitude and the vertical speed. It allows to see the noise in the measurements.
- the second gives the original (not filtered) pressure measurements (quite noisy) given by the sensor and the vertical speed. It allows to estimate the delay of reaction (time between a variation of pressure and the vertical speed).

You can see that:
- the new program reduces significantly the noise as well on the altitude as on the vertical speed. It is much easier to recognise the up and down.
- the new program responses (nearly?) as fast as the original one. This reaction time (about 1 sec) seems me OK.
- the new program gives a vertical speed that is nearly twice the value from the original one. The value from the new one seems me ok (40 cm/sec based on the scenario).

Notes:
- the altitude given by the new one is different because I used another rule to convert pressure to altitude. I worked based on a fix temperature of 15 degree instead of the temp from the first sensor reading because anyway we are never sure that the sensor temperature is the same as the air temperature outside the airplane.
- the pressure and altitude displayed for the new program are 100 X bigger. This was done to improve accuracy of internal computing.

Please, let me know if you find some errors or if you seem other ways for improvement.

Michel.

[NeilRogers]

Hi Michel
Thanks for the information
Unfortunately I've only the one sensor, the primary role is of course vspd for me for thermal soaring application so the small drift in altitude is too much issue.
While developing its worth feeding back as much information as possible
The key element is the excellent vspd performance.
Although it would be interesting to see what level of altitude drift others have.
If weather's kind I'll try and get some gps v oxs alt comparisons from live flights asap
cheers neil

[NeilRogers]

Hi Michel
I manage to run a live test of the vario against gps altitude with very interesting result.

The vario and gps gives very similar attitude results certainly better than I expected with the gps lagging behind the vario.

Neil