OpenXSensor SPORT Interface

[NeilRogers]

excellent Bruneaux

[MikeB]

//<<<<<<< .mine
//#include "SoftwareSerial.h"
//=======
//>>>>>>> .r194

SVN adds that when you do an "svn update" and it finds a conflicting change. I removed
"#include <../../../../libraries/SoftwareSerial/SoftwareSerial.h>"
on the same line. Just delete those lines from your copy.

Mike.

[RightRudder]

I now have a functioning air speed sensor! YAY!!!

We had freezing rain and slick roads so I don't know if it is properly calibrated. Very close.

Bruneaux

I have access to a proper wind tunnel at the university where I work. I could help with that if you like. Congrats on getting it going!

Joe

[Carbo]

OpenXSensor SPort Vario and Altitude are working perfect. The Kalman-Parameter seems to be changed, but it is not possible to display it in the telemetrie screen T2 is always 0 (#define SEND_SensitivityAsT2 // Kalman Param R in Temp2).
Fuel (#define SEND_VRefAsFuel) is also 0, should be the internal voltage.
Temperature (#define SEND_TEMP_T1 // MS5611 temperature as Temp1) also not displayed.
With OpenXVario without SPort i can see the data.

Whats my mistake?

[NeilRogers]

On the sport interface only vspd & Alt parameters are transmitted back to the tx currently

It's early days for sensor with the sport interface a working version was only designed by MikeB 4 days ago.

I've only bench tested so far but hope to test live tomorrow wind direction permitting

[MikeB]

Yes, only Vspd and Alt are returned. The Kalman parameter is controlled by the PPM signal on IO2. If you have a PPM signal on this pin it will affect the sensitivity.

I'll get back to this in a while, we need to be sure the SPort interface is reliable. I've got a couple of other things I need to deal with first though.

Mike.

[Bruneaux]

I have access to a proper wind tunnel at the university where I work. I could help with that if you like. Congrats on getting it going!

Joe

Joe,

Thanks for the thought. I don't know if I need that precision! And getting it to/from Canada would be an issue. I'll run it up and down the interstate at 80mph and see where I'm at. It should scale linearly, so I'll graph a few data points so insure that. When I'm done packaging it up into a Arduiono Nano I might ship one to you to see how close I have it. Good?

I'm working on a tachometer and wanted to use the "attachInterrupt(1, Tick, CHANGE)" but I keep colliding with
"Arduino\hardware\arduino\cores\arduino/WInterrupts.c:309: multiple definition of `__vector_1'"
when I pull in <arduino.h>.

I know Mike is quite busy. Anyone else have any ideas?

Bruneaux

[Bruneaux]

I just realized that "SoftwareSerial.h" might be the collision. Checking and removing it in my module. . .

Update:

Didn't find it in "openXsensor.ino". But I think it is where the problem is.

Hmmm.

Update2

It could be in the PPM code. I'm taking it out, I don't use currently.

AHHH!!!

//#define PIN_PPM 2 // default: 2 the pin to read the PPM Signal on coming from the receiver.
// // you can uncomment this line if you want to completly disable the remote control functionality

that did it, but there is a question in my mind of "why?". Oh well, as they say, I'll burn that bridge when I get to it.

[NeilRogers]

At last, the wind direction was good for a live test although the lift was poor on the slope.
The good news, the vario worked faultlessly no signs locking over 3 20 minutes .
I've include the telemetry logs for interest.

Thanks for all your work, Mike it look great

[RightRudder]

Hi Neil

Any chance you could post that log as a regular .xls or an open office format? My version of open office can't digest .xlsx but I would like to look at a 3:20:00 flight record!
Congrats on getting it going. I myself just moments ago got r195 flashed and got a working S-port alti/vario working on my brand new taranis. Love this forum. Thanks to all involved.

Joe

[NeilRogers]

Hi Joe,

The sensor has run faultlessly with no locking, here's old version xls.

Neil

[RightRudder]

Huh. That's interesting. The logged vertical speed data doesn't seem to correlate with the altitude data. I'm used to looking at these sorts of altitude/vario graphs and the vertical speed is basically the slope of the altitude graph. Where you see a large change in altitude the vspeed graph should maintain a non zero positive or negative value for the duration of that altitude change. But your data looks like random spikes in the v-speed record. I even tried plotting the v-speed data on a separate chart so as to amplify the vertical range of the plot to have a better look at the data. It doesn't look right to me but if the audio seemed to be working for you (mine does here) then this means opentx has got an issue with telemetry logging. Didn't I see an open issue about this on the wiki?

Joe

[NeilRogers]

Hi Joe
As a sloper I only really looked at Alt and occasional vario sound check which sounds ok. I have noticed a bit of altitude drift.

It difficult to assess the true vspd with the long 500ms recording rate when I was fly fast aerobatic gliders


I've been a bit busy so I've not played around with the sensor too much, I was planning to run the frsky HP in parallel and compare the result but not had the time yet.

[mstrens]

Hello Rightrudder,

I am new on the forum and I follow this project since a few weeks.
First, I would like to thank all members spending time and effort in order to provide such good opensource project.

I have build an openxsensor the last days.
It works and I decided to try adding some code in order to transmit an external analog voltage on an X8R receiver using the Sport (like it works with the hub protocol).

Therefore I looked at the code.

I think that there is a bug in the vertical climb rate calculated by the arduino.
The original program intent to calculate the climb rate in the following way:
There is some code to calculate from time to time a ratio between pressure and altitude.
Another part of code calculates the sum of 20 differences of pressure measurements, multiplies it by the ratio pressure/altitude and finally divides it by the enlapse time for the 20 pressure measurements.

I calculate the climb rate in another way :
Each 20 pressure (=altitude) measurements, I calculate directly the difference between the last and the first altitudes and I divide this by the enlapsed time. This is much easier to program.
The climb rate I calculate seams to be greater than the original climbrate.
I did not look further at the original code in order to find a bug.

I think too that the calculated enlapsed time is sometime wrong because it uses a function "micros()" from arduino library and that this function use the Timer0 which is disabled during the transmission of data on the SPORT.
In some cases, I have seen that the enlapsed time (calculated by the difference between 2 successive "micros()" commands) is negative.
It should probably be better to use the Timer1 from the arduino (the one already used by Mike to handel the UART on the SPORT).

Please note that I just started learning C++ and Arduino a few weeks ago and I can't certify that I am 100% right in what I discovered and tried to explain.

I hope that my comments can help a programmer with greater experience to fix eventual bugs in this great openxvario project.

NB: sorry if made mistakes in the text but enghish is not my mother langage.

Michel

[RightRudder]

Hi Michel

Thanks for the post and welcome to the forum. You have to remember that the pressure sensor has noise so if you calculate the V-speed the way you are saying, then you are including the insantaneous noise value which becomes a part of the v-speed result. Sum of 20 differences smooths out the noise (which is random sometimes positive sometimes negative) so you get a smoother and more accurate value that way. I don't think timer0 would be disabled by mike's code (I'm only guessing here since I don't speak C) but perhaps timer0's INTERRUPT is temporarily disabled while timer1 is dealing with serial comms. I do assembler programming and this is a common situation where one can check for PENDING interrupts. So if timer0 underflowed while the processor was busy servicing the timer1 ISR then at the end of that ISR the timer0 interrupt would be pending. But the timer0 is still running counting down from 0xFFFF So one only needs to add the 2's complement value of the timer0 to the timer preload value in order to get an accurate value for the time period which elapsed while the timer1 ISR was in action. This is a very common programming trick and I'm guessing that would be used here. I hope so!

Joe

[MikeB]

I thought I only disabled the TIMER 0 interrupt for the duration of each single byte transmitted (about 173uS), then allow TIMER0 to interrupt if it is pending.

Since the function micros() returns an unsigned value, the difference between two calls to it CANNOT be negative as the difference will also be unsigned.

Mike.

[RightRudder]

I wonder if he meant that the timer value is negative? The interupt flag goes up when the timer underflows right? So if he read the timer value before the MSB changed he would think it was a negative value. If he is using an emulator on the arduino in the atmel IDE he could be talking about the timer value??

[Kilrah]

Of course if he's interpreting the timer value as signed it will be negative - but that would be the error, it should be treated as unsigned

[mstrens]

Hi RigthRudder,

About using the pressure (=original code) instead of the altitude (my code) in order to calculate the clim rate should not make any difference.
In fact original code (in the file OXS_MS5611.CPP) calculates first the sum of 20 differences between a previous pressure and a new one at the instuction "crsum+=(lastPressure-pressure);". Afterwards, this is converted in altitude (using a ratio "metersPerMbar") and then in cimbrate (dividing by the enlapse time).
It means that , when used for calculating the climrate, crsum is equal to:
(pressure1 - pressure0) + (pressure2 - pressure1) + (pressure3 - pressure2)+ ... + (pressure20- pressure19) where pressure0 is the last previous value, pressure1 the one entering the first time in the loop, ... and pressure20 the last value (after 20 loops)
So, this is exactly the same as calculating only once (pressure20 - pressure0) because the "+" and the "-".
In fact the noise is "eliminated" because the program uses pressures values only every 20 cyclus (and because there is already a Kalman filter).

Therefore it is equivalent , I think, to calculate directly (Altidude20 - Altidude0) and so avoiding calculating in another part of the program the ratio "metersPerMbar" to convert the pressure into altitude just before calculating the climb rate.
The result should be the same but the code would be simple and there would be less risk of bugs.
I did not looked at the reason but, as said before, I found that the results were not the same.


About "negative" values of timer :
The program use an Arduino function named micros(). This function return an unsigned long. It uses the Timer0 and it requires that interrupts on timer0 is enable to provide correct values.
If interrupt on Timer0 is disabled during e.g. 173 us and if you call this function during this time, the value return will be wrong.
In fact the returned value is calculated using as well part of Timer0 register (to get the micro second) as well a memory variable keeping the millisecond (and those are updated only if the interrupt is enabled).
I found some reports on this problem on the Arduino forums.

I had very strange behaviour in the program I tried to write and therefore I search for an explanation.
During some tests, I saw that the value displayed on the PC monitor by a second command "serial.println(micros())" was lower (a few micro seconds) than the value displayed by a previous command.

I reported this because I hoped that some of you had more experience in order to fix those kind of issues.

I forgot yesterday to mention another possible bug:
The SPORT protocol uses the value 0x7E for the polling of devices.
I presume that this value may never be send by a (slave) device.
In some programs (OpenTX -Taranis, Analog SPORT from Mike) I found that there was some code in order to replace the byte 0x7E by 2 bytes. I did not find such a conversion in the OpenXvario SPORT code. I think that such a conversion is done for the byte 0x7D too.
Are those conversions not required?

Michel

[MikeB]

Bother! I missed the byte stuffing out, I was too busy making the timing work correctly. It's added to my "todo" list.

Mike.

[Bruneaux]

Question for those that have a sensor running.

Are you running the 5v ( spec'd 6-12v) Arduino or the 3.3v Arduino?

I have been told that my batch of Arduono's might have been corrupted by letting the 5v rail drop too low, and thus corrupting the boot loader. My BEC shows 4.98v.

Mike, do you think that the 8Mhz/3.3v Arduino will have timing issues?

Thanks

Bruneaux

[MikeB]

The ATMEGA328 (20mHz) is specified to still run reliably at 16 mHz at a supply voltage as low as 3.78V. As it takes quite a low current, the 5V regulator drops very little voltage, even if it is no longer regulating due to the input voltage dropping below 5V. I would be surprised if the bootloader has become corrupted.

The SPort code is written specifically for a 16mHz clock at present, it doesn't run at 8MHz.

Mike.

[jhsa]

If you think the bootloader is corrupted, just burn it again

[Bruneaux]

Jhsa,

I can't get it to sycn up via the USB cord so I have to buy the bootloader with the FTDI or SPI and hope that will revive them. Or throw them away. Dunno.

Bruneaux

[Kilrah]

You need an AVR programmer like an usbasp, yes.

[jhsa]

not with the FTDI. I think you have to use the other programmer..

[Bruneaux]

Kilrah,

Yes, that is I am looking at:

http://store.atmel.com/PartDetail.aspx? ... escription

But I still worry why my boards failed. 4 of them. Bad batch?

Bruneaux

[RightRudder]

Well I was curious so I threw a crude hypobaric chamber together and threw the system in and recorded a few climbs and descents using a 100ms log period. Seems like the v-speed is being logged just fine. I guess the file Neil posed logging at 500ms on the slope wasn't just showing much obvious. If anybody is interested I made a graph and saved it as an xls spreadsheet. Hopefully open office saved it correctly and will open with excel properly.

Hypobaric test_1.xls

(125.5 KiB) Downloaded 164 times

[MikeB]

I don't have much time, but I've thrown this together without any testing:

Aserial.cpp

(14.79 KiB) Downloaded 279 times

I think it should handle the byte stuffing. If anyone has a chance to try it it would be helpful.

Mike.

[mstrens]

Mike,

thanks for handling the byte stuffing.
I test it and it seems ok.
To test it, I changed the code where you fill TxData in this way
if ( pdata->dataLock == 0 )
{
TxData[0] = pdata->data[0] ;
TxData[1] = pdata->data[1] ;
TxData[2] = pdata->data[2] ;
TxData[3] = 0x7D;
TxData[4] = 0 ;
TxData[5] = 0 ;
TxData[6] = 0 ;
}
And I get the right value 0x7D as climb rate on the Taranis display (125).
I did it for 0x7F too and its is OK.

Michel