openrcforums

Posted: **Thu Dec 17, 2015 9:31 pm**

Yes, it is right.

Still I should have to finalise newer version (Hott, GPS, accelerometer/gyro, glider ratio, ...)
The wiki/download should be updated too.

Posted: **Sun Jan 17, 2016 7:37 pm**

Hi,

I finish to tuned "ALT_TEMP_COMPENSATION" variable, with last version.

It seems the ratio is about 333 for 1 meter of drift.

In "oXs_config_description.h", you had a value of 1000 for 3 meters of drift.
I will have to insert a value of 1400, in order to correct a drift of 4 meters.

After inserting this value, altitude is stable.

Posted: **Mon Jan 18, 2016 11:09 am**

I expect that the value to use for compensation varies from one MS5611 to another.

It is fine that this compensation works in your case.

In some tests I made, I was not able to find a value that really works on several days.
It seems to me that the value to use for compensation varies from one day to another.
I have no explanation.

Posted: **Mon Jan 18, 2016 4:47 pm**

Flew for the first time in ages today and noticed that after flying for 15 mins or so I landed and alt was at zero....
I thought the altimeter was not working at first because I used to get a drift of around 15 to 30ft...
Stock settings... Really good stuff!

BTW , is d8 working yet on the GPS or IMU versions?
Just wondered as I have 2 GPS units waiting to be built and installed into gliders with d8r. Rxs ..
No rush if its not, too cold to fly really, I was just flying to test out a new x4r which was sent as a replacement for one that stopped working a few months ago and weather has been not flyable since....

Posted: **Tue Jan 19, 2016 11:28 am**

nigelsheffield wrote:
BTW , is d8 working yet on the GPS or IMU versions?
Just wondered as I have 2 GPS units waiting to be built and installed into gliders with d8r. Rxs ..
No rush if its not, too cold to fly really, I was just flying to test out a new x4r which was sent as a replacement for one that stopped working a few months ago and weather has been not flyable since....

Normally latest version (V7.0) should support GPU and IMU with Frsky Hub protocol (other protocol too).
Still it has not been tested with this protocol.
It has been tested with SPORT protocol and it seemed OK.
So, you can test it with Hub protocol, I will fix the reported bugs (if any).
I just pushed this last version on github in the master branch.

For those that should encounter issue with this new version, the previous stable version (V5.0) is available as a release.

Posted: **Tue Jan 19, 2016 11:47 am**

Ok great thanks , I will try it soon and report back!

Posted: **Tue Jan 19, 2016 5:46 pm**

With V7.0, I can't read MS5611 temperature using TEST_1.

FrSky SPORT fields selector changed, and sensors Instance too.

Posted: **Tue Jan 19, 2016 6:04 pm**

I presume you got a compilation error.

In V7.0, I changed some data structure (in order to save some flash memory using a more standardise way to transmit over SPORT).

Therefore you should put those lines at the end of a (new) function calculateAllFields () in the .ino file.

test1.value = oXs_MS5611.varioData.temperature ;
test1.available = true ;

Posted: **Tue Jan 19, 2016 8:42 pm**

I don't have any compilation error.

I add these lines into readSensors function, like I do in v5.0 :

Code: Select all

#ifdef VARIO
  newVarioAvailable = oXs_MS5611.readSensor(); // Read pressure & temperature on MS5611, calculate Altitude and vertical speed; 
  if ( oXs_MS5611.varioData.absoluteAlt.available == true and oXs_MS5611.varioData.rawPressure > 100000.0f ) actualPressure = oXs_MS5611.varioData.rawPressure / 10000.0 ; // this value can be used when calculating the Airspeed
  test1Value = oXs_MS5611.varioData.temperature ;
  test1ValueAvailable = true ;
#endif

But into Taranis, now I don't have "Tmp1" sensor (but something like "Cels" as I remember. I'll check tomorrow)
I make my config like that :

Code: Select all

// ***** 9.1 - Frsky data *****
//#define VFAS_SOURCE     VOLT_1                 // select between VOLT_1, VOLT_2, VOLT_3 , VOLT_4, VOLT_5 , VOLT_6
//#define ACCX_SOURCE     TEST_3                   //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO 
//#define ACCY_SOURCE     VOLT_3                 //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO 
//#define ACCZ_SOURCE     TEST_3                 //  select between TEST_1, TEST_2, TEST_3, GLIDER_RATIO
//#define T2_SOURCE       PPM                      //  select between TEST_1, TEST_2, TEST_3, , GLIDER_RATIO
#define T1_SOURCE       TEST_1                   //  select between TEST_1, TEST_2, TEST_3 , GLIDER_RATIO

Posted: **Tue Jan 19, 2016 8:46 pm**

I find some new Values :

- test1.value
- test1Value

I need to use which one ?

Posted: **Tue Jan 19, 2016 9:12 pm**

It is strange that you did not get a compilation error using testValue = ....
When I try it, I get a compilation error because this variable does not exist anymore in V7.0

As said in previous message you must now use new variable (being part of a structure (this explain the dot).
test1.value = oXs_MS5611.varioData.temperature ;
test1.available = true ;

And it is more logical to put those lines at the end of the function calculateAllFields () because I moved all extra calculations (after readSensors) in this new function.

Note : if "test1.available" is not set to true, oXs does not send the value to Tx.

Posted: **Tue Jan 19, 2016 9:26 pm**

Fabe wrote: But into Taranis, now I don't have "Tmp1" sensor (but something like "Cels" as I remember. I'll check tomorrow)

In the new version, oXs sent automatically cells voltage if number of cells is defined. You do not have to add some lines to force oXs to transmit the cell voltages (at least in Frsky and Hott protocols)

Posted: **Wed Jan 20, 2016 4:51 pm**

mstrens wrote:It is strange that you did not get a compilation error using testValue = ....
When I try it, I get a compilation error because this variable does not exist anymore in V7.0

As said in previous message you must now use new variable (being part of a structure (this explain the dot).
test1.value = oXs_MS5611.varioData.temperature ;
test1.available = true ;

And it is more logical to put those lines at the end of the function calculateAllFields () because I moved all extra calculations (after readSensors) in this new function.

Note : if "test1.available" is not set to true, oXs does not send the value to Tx.

I activate "test1ValueAvailable" variable.
Define variables are still present in code.

Posted: **Wed Jan 20, 2016 5:07 pm**

I do not understand why you say that define variables are still present in code.
In V7.0 on github master branch, you have

Code: Select all

struct ONE_MEASUREMENT test1 ; // used in order to test the transmission of any value
struct ONE_MEASUREMENT test2 ; // used in order to test the transmission of any value
struct ONE_MEASUREMENT test3 ; // used in order to test the transmission of any value
//int32_t test1Value ;// used in order to test the transmission of any value
//bool test1ValueAvailable ;
//int32_t test2Value ;// used in order to test the transmission of any value
//bool test2ValueAvailable ;
//int32_t test3Value ;// used in order to test the transmission of any value
//bool test3ValueAvailable ;

So the "old" variable are as comment (with "//" in front.

You now have use the variable "test1" which is a structure with 2 members ("value" and "available").

Posted: **Wed Jan 20, 2016 5:09 pm**

Well, I make some tests.

Now it's working, I can have MS5611 temperature into transmitter

I use test1.value.

By the way, if you comment this line, it returns a "Cel" field into SPORT :

Code: Select all

#define NUMBEROFCELLS 0   // Put this line as comment or set value to 0 (zero) if you do not want to transmit cell voltages.

I need to set it to "0" in order to skip this telemetry value.

Anothers questions :

- is altitude is send in cm or m to transmitter ?
- what is the main difference with BMP085 ? Very less accuracy ?

Thanks a lot for your projet !

Posted: **Wed Jan 20, 2016 6:18 pm**

I do not understand why NUMBEROFCELLS should be set to 0 because code is following

Code: Select all

// pointer to Cell_1_2
#if defined(PIN_VOLTAGE) && defined(NUMBEROFCELLS) && (NUMBEROFCELLS > 0)      
   p_measurements[2] = &oXs_Voltage.voltageData.mVoltCell_1_2 ; 
#else
    p_measurements[2] = &no_data ;
#endif

// pointer to Cell_3_4
#if defined(PIN_VOLTAGE) && defined(NUMBEROFCELLS) && (NUMBEROFCELLS > 2)      
   p_measurements[3] = &oXs_Voltage.voltageData.mVoltCell_3_4 ; 
#else
    p_measurements[3] = &no_data ;
#endif

// pointer to Cell_5_6
#if defined(PIN_VOLTAGE) && defined(NUMBEROFCELLS) && (NUMBEROFCELLS > 4)      
   p_measurements[4] = &oXs_Voltage.voltageData.mVoltCell_5_6 ; 
#else
    p_measurements[4] = &no_data ;
#endif

Having a condition like #if defined(PIN_VOLTAGE) && defined(NUMBEROFCELLS) && (NUMBEROFCELLS > 0) means that data is sent only if 3 conditions are simultanously fulfilled:
- PIN_VOLTAGE is defined
- NUMBEROFCELLS is defined
- NUMBEROFCELLS is greater than 0

Atitude is transmitted to Tx in cm. This does not mean that altitude is as accurate as cm. In many cases, you will notice a drift of altitude even if the sensor do not move. The reason is that
- the atmospheric pressure varies over time
- the internal temperature of the sensor varies and this has an impact on the returned values (even if there is some compensation).

Based on what I read on forums, it seems that BMP085 and BMP180 are less accurate than MS5611.

Posted: **Thu Jan 21, 2016 6:08 pm**

Hi,

I made some flights today : everything works perfectly !

Thanks a lot

Posted: **Thu Jan 21, 2016 6:29 pm**

I tested on a x6r today and it worked fine.
I tested on the only hub RX I have free which is midelica diy one, the vario worked and GPS data was there but distance was wrong on taranis , I think this was probably the RX side though..
Fabe , did you test on hub or s.port?
If I get chance tommorow I will pull out a genuine frsky hub RX and test again.
Great work!

Posted: **Thu Jan 21, 2016 6:55 pm**

GPS distance is calculated by TX and not by oXs.

If distance is wrong, I see 3 possible reason:
- calculation on Tx side is wrong. I would be surprised that it should be the reason because it would already have been notified
- longitude and latitude sent by oXs are wrong (e.g. wrong format). This could easibly be checked comparing the values on Tx side with the current location with e.g. Google map.
- oXs sent as first values inconsistent data (long and lat = 0; the right longitude and 0 as latitude). Tx calculates distances from this inconsistent origin. To check if this is the reason of the issue, you could let the Rx/oXs/GPS running and make a reset or a power down/on of the Tx.

Posted: **Thu Jan 21, 2016 7:10 pm**

I did reset on tx, which on the x6r zeroes the distance, on the diy RX did not work, I think it's RX side , Midelic said he will be releasing update for hub telemetry soon so that may fix it, I don't think anyone has trested GPS on his diy rx code yet.
Will try the frsky d8r tommorow if no one else has tested it before me.

Posted: **Fri Jan 22, 2016 6:38 am**

nigelsheffield wrote: Fabe , did you test on hub or s.port?
Great work!

I made test with s.port, oXs v7.0 and vario, not GPS

Posted: **Sat Jan 23, 2016 2:41 pm**

Ok I tried on the d8r and there is a problem,
first there is no GPS speed showing
Then after a minute or so all readings go crazy, jumping to extreme values, this includes altitude, v.speed, and GPS data.

I have GPS and IMU enabled, and frsky hub and s.port enabled so it automatically knows if its connected to s.port or hub.
S.port works fine.
Nigel.

Posted: **Sat Jan 23, 2016 2:43 pm**

Oh and I set GPS update to 10hz if that makes a difference.

Posted: **Sat Jan 23, 2016 4:07 pm**

Thanks for the feedback.
I will try to reproduce the issue. I have a D4r-II to test the hub protocol.

Posted: **Mon Jan 25, 2016 4:03 pm**

I put a new version of oXs on github (on master branch).

I think it will fix the issue you had with Hub protocol (avoiding crazy values).

Note: I added also some code for Hub protocol in order to transmit GPS data only when GPS got a fix. This avoid getting wrong relative altitude when first values are not accurate. In order to get a fix, It can take some min before getting a fix ( and GPS should ideally be outside).

I checked the code for GPS speed but I did not find a bug.
Please note that the GPS has first to get a fix and has to move (e.g. walking) in order to display a speed.

I first tested on a breadboard that was on a table. I got zero on Tx display which is normal.
Still I made a test version where gps speed was multiplied by 1000 and then I got some changes on Tx display (due to minor GPS variation).
So I expect that transmission is working.

Posted: **Mon Jan 25, 2016 4:26 pm**

Ok I will test later this aft.
Regards speed I tested on s.port walking and got 1 to 2, but on hub got nothing...but will try again and report.
Thanks!

Posted: **Mon Jan 25, 2016 5:18 pm**

seems to all be working now on d8r, including speed and no crazy readings!
thanks.
nigel.

Posted: **Mon Jan 25, 2016 9:14 pm**

sorry to bother you again lol,
but did you turn sensitivity down on imu at some point because reaction times seem similar again to no imu?
nigel.

Posted: **Tue Jan 26, 2016 8:59 am**

No, I did not change sensitivity on imu.
In fact, the vertical speed calculated with imu does not take into account the parameters from config file about sensitivity or from ppm signal.

Reactivity with imu is based on 3 parameters defined in a Kalman filter. At this time I just put 3 parameters that seems to give similar "noise" as with the "normal" sensitivity. Still, with those parameters, if noise seems similar, the reaction time with imu is clearly reduced (about 0.4 sec less) as showed in some of my reports or in a post from Carbo.
Please note that Vertical speed on imu is not automatically transmitted to Tx. You have to specify in the config file which vertical speed (e.g. from mS5611 alone or from ms5611+imu) you want.
So you have fill a line like this (on github, it was filled in rder to send FIRST_BARO and it is perhaps the reason of you issue).
#define VSPEED_SOURCE BARO_AND_IMU // select between FIRST_BARO, SECOND_BARO , AVERAGE_FIRST_SECOND, AIRSPEED_COMPENSATED , BARO_AND_IMU or PPM_SELECTION

Posted: **Tue Jan 26, 2016 1:14 pm**

Got it thanks!

openrcforums

OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code

Re: OpenXSensor project page on google code