New beta version of openXsensor (=openXvario)

Development & General Chat for the superb openxvario project.

Moderator: rainer

Post Reply
mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Nov 27, 2016 8:17 am

I checked the code and you are rigth: PRANDTL_COMPENSATION is never send by oXs.
It is a bug in the documentation.
In fact it was available in some previous version when dte was compensation Vspeed was first calculated and then summarised to uncompensated Vspeed.
I had to change this because dte calculated this way was not good mainly due to different delays/filters applied on each part of the sum.

That is the reason why oXs now first summarise the "raw altitudes" and applies the filters on the sum. So compensation alone is not available anymore.
In order to get something similar, you should have now to calculate the difference between dte and uncompensated Vspeed. This can easily be done in XLS based on the log values.

If you really want it directly from oXs you can try adding following 2 lines of codes:

airSpeedData->compensation = compensatedClimbRate - oXs_MS5611.varioData.climbRate ;
airSpeedData->compensationAvailable = true :

after line 721 which contains:
compensatedClimbRateAvailable = true ; // allows SPORT protocol to transmit the value every 20 ms .

Please note that I did not test this new code so there could be a bug.


RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Sun Nov 27, 2016 5:20 pm

Yeah I did not find that line at line 721 and I have been using oXs v2.5
I did find it at line 356 and added the two lines which compiled fine but I got still no detection of the sensor (A4) used for CMP.
So I went back to page 3 of this thread and downloaded the file you posted "openxsensor_2014_09_06_v2.rar" to try that version.
Still I did not find that code at line 721 so I think I have the wrong version. Still I tried the edit and compiled but got no detection of the prandtl_compensation.

Edit: Sorry ,mistake, on that downloaded version I found the code at line 479. I added the two lines but got a compile error :
exit status 1
'airSpeedData' was not declared in this scope
when I commented the two lines it compiled fine, but obviously no detection of A4 sensor for PRANDTL_COMPENSATION


It is good to know that the version works as you said by combining both the compensation data and baro data early with equal process delay. I am also glad that it is still possible to adjust the sensitivity and compensation independently as I had hoped. It would be nice to be able to see these PPM values on the TX though as I would like to read the compensation value once I find the right value through flight testing and then I can go back and hard code it in the sketch so it frees up one pot for another purpose. Thanks for your explanation.

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Sun Nov 27, 2016 6:26 pm

The line number 721 refers to openXsensor V5 (available on github in one branch). I though that you were using this version.

You can get PPM value back on TX if you ask for it in your config.h file. You have to transmit it an existing Frsky field (like T1, T2, ACC, ...)

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Sun Nov 27, 2016 10:14 pm

I got the v5 code. There is a compile error on the first of the two lines you asked me to add:

'airSpeedData' was not declared in this scope

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Mon Nov 28, 2016 1:19 am

I tried modifying those two lines after 721 to:

oXs_OutFrsky.airSpeedData->compensation = compensatedClimbRate - oXs_MS5611.varioData.climbRate ;
oXs_OutFrsky.airSpeedData->compensationAvailable = true ;

so now the sensor at A4 is discovered but the value is always zero :(


RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Mon Nov 28, 2016 1:59 am

I added a multiplier of 100 in the data to send field and now I see some values in the PRANDTL_COMPENSATION telemetry field on Taranis. However these values change in a similar way as the dTE telemetry field and are influenced by changing the left slider ie when the PPM goes from 60-90 these numbers get more reactive. But this isn't the value I was asking for, I was interested in seeing the value defined as COMPENSATION_PPM which on this sketch should range between 80-140 if the PPM ranges from 60-90.

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Mon Nov 28, 2016 8:01 am

The field you are asking for is "compensationPpmMapped".
It is not foreseen to transmit this field to the Tx but you have 2 solutions to know it.
- transmit the PPM value. You can then easily convert the PPM value into a compensation_PPM because the conversion is linear (range 60-90 gives range 80-140)
- change the first line I asked to add :
Instead of "oXs_OutFrsky.airSpeedData->compensation = compensatedClimbRate - oXs_MS5611.varioData.climbRate ;"
Put this : "oXs_OutFrsky.airSpeedData->compensation = compensationPpmMapped ;
and keep the config.h setup you were using.

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Mon Nov 28, 2016 12:11 pm

Wonderful. That has done it. Thank you Michel

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Wed Dec 21, 2016 6:57 pm

mstrens wrote: 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.

How frequently is the altitude data sent to the Rx via SPORT?

How frequently is it read by openTX?

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Wed Dec 21, 2016 8:15 pm

It is difficult to provide an answer because it depends on the number of sensors.
Altitude is declared "available for sending" once every 100msec.
Still, when the value is "available for sending", it will not be sent immediately because in SPORT protocol the sensor has to wait for a polling from the Rx. Frequency of polling depends on the number of sensor device ID present on the SPORT bus.
Furthermore only one value can be sent in reply of a polling and there are normally severals type of data (e.g. Alt and Vspeed) to be send on the same device ID. So the different data are sent in reply of several pollings.
If you are using oXs only for Alt and Vspeed, I expect that TX would get a new Alt once every about 120/150 msec.
If there are other sensors (Volt, GPS, ...), it will increase but I do not expect it will exceed about 400msec.
You can make some tests looking at the log file (setting one log every 1/10 sec).
I do not know the frequency of processing on the Tx side.
Please note that the enlapsed time between 2 values received on TX side can be irregular ( even if the enlapsed time between 2 calculations in oXs is regular (nearly) 100mec)

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Thu Dec 22, 2016 12:01 am

I read somewhere else (GPS thread I think) that SPORT Rx polls the interface every 22mS but that if oXs is configured to respond to more than one address it could get polled as frequently as every 12mS is it correct?

I'll explain why this is important. I am using this with a flybarless helicopter. The flybarless gyro has a rescue function that will flip the heli upright and level and then make it climb. This rescue function responds to a PPM channel which pilots normally assign to a switch on the TX. Remembering to hit the switch in a panic moment can be difficult and takes time. I am using the altimeter and a logical switch to activate the rescue autonomously whenever it is enabled and the helicopter altitude is less than a threshold. It works but could be improved. This feature can save a lot of money in crash damage for a pilot who is still learning the difficult skills of heli flying. Most pilots who fly helicopters like to fly at less than 20 meters height. Depending on the vertical momentum and other factors like the response lag and power to weight ratio of the heli it will eat up some altitude in the rescue process. This requires the threshold altitude for the logical switch must be sufficiently high to guarantee success in every case. If I can reduce the response time it will help a lot. Another option I am investigating is to use more logical switches and make the altitude threshold dynamic depending on vspd so that if vspd is low the threshold altitude can also be low but if vspd is higher (negative) then the rescue altitude threshold is also higher. I would like to make oXs as fast as possible at least for Alt and Vspd and other data could be sent much slower.

How do I use these lines in oxs_out_frsky.h?
#define INTERVAL_FRAME1 200
//#define INTERVAL_FRAME2 1000

Can I reduce the interval frame constant? Is there a way to define which data goes at which frame rate?

Joe

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Thu Dec 22, 2016 8:21 am

The line #define INTERVAL_FRAME1 200 is used only in HUB protocol. So it does not matter for SPORT.
If you want to get Alt as fast as possible, you could :
1- change one line in oXs_ms5611.cpp:
instead of nextAltMillis = altMillis + 100 ;
put nextAltMillis = altMillis + 10 ;
So, in this case oXs will calculate Altitude each time it goes through this code (so in fact every 20 msec instead of 100 msec).
2 - if you do not need Vspeed, you could avoid to send it to TX. So, if there is no other sensor and if you make previous change, oXs will send Alt about every 22msec. If you make previous change but keep Vspeed and if there is no other sensor, Alt wil be sent every 44msec (because oXs has to send Vspeed too). In order to disable sending Vspeed, you can change one line in oXs_ms5611.cpp
instead of varioData.climbRate.available=true; // allows SPORT protocol to transmit the value
put varioData.climbRate.available=false; // allows SPORT protocol to transmit the value
3 - The altitude calculated by oXs used some filtering in order to reduce the noise from the pressure sensor. Filtering generates some delay too. You can reduce the delay if you reduce the filtering. You can change one line:
instead of altitude += 0.04 * (varioData.rawAltitude - altitude) ;
put altitude += 0.1 * (varioData.rawAltitude - altitude) ;
or even altitude += 0.2 * (varioData.rawAltitude - altitude) ;

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Thu Dec 22, 2016 9:04 am

I did experiment with something similar before. But the telemetry being sent (HUB protocol) was too slow and I needed a really fast response. I think even the S.PORT might still be too slow to send the info to the radio.
I wanted the radio to reduce the maximum throttle value proportionally and just enough to keep the voltage of the battery above a certain threshold. This would avoid damaging the battery.
It kinda worked, but it oscillated due to the telemetry being too slow.
I might go back to this someday :)

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

ReSt
Posts: 1532
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by ReSt » Thu Dec 22, 2016 10:20 am

@ João
I wanted the radio to reduce the maximum throttle value proportionally and just enough to keep the voltage of the battery above a certain threshold. This would avoid damaging the battery.
some years ago I have built a small circuit with a PIC processor that does exactly what you describe. It's switched into the throttle channel output of the receiver and monitors the throttle channel signal and up to three lipo cells. When the voltage of any of the cells goes below a specified voltage (3.00) the throttle that is output to the ESC is more and more shortened until the voltage increases above the low voltage value.
It has some more functions than this.

PM me if you are interested

Reinhard

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: RE: Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Thu Dec 22, 2016 10:24 am

ReSt wrote:@ João.

PM me if you are interested

Reinhard
Of course I am :)
But it would be nice if the radio could do it :)
Will PM you

Thank you

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Thu Dec 22, 2016 2:40 pm

Thanks for the help Michel I will investigate these options. My hardware is designed to send 4s voltages and current as well as RPM so if each is sent on one polling period at 22mS then the data rate for any one would be 7x22ms=154mS if I understand you correctly. If the TX can only process the telemetry every 100mS then it doesn't make any difference if oXs sends it faster but I don't know how fast openTX can deal with the data. Does anybody here know?

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Thu Dec 22, 2016 5:47 pm

The last version of oXs (version 7) replies to different device ID's dpending on the type of data to be sent.
It uses one device ID for alt+ Vspeed, another one for voltage, another one for current and another one for RPM (and another one for GPS).
If you send data in 4 groups, there will be (4+1) * 11msec = 55 msec between 2 polling of the same device ID.
So, if you send ALT and Vspeed (which are in the same group), Alt will be sent once every 110 msec.
If you apply the change I propose in order to avoid sending Vspeed, Alt will be sent once every 55 msec (if you also aply the change in order to let oXs make the Alt available as fast as possible).

Take note that this is a major difference with version 5 of oXs.
In version 5, oXs replies only to one device ID. If no other sensor than oXs is connected, the polling of oXs occurs every 22msec.
When this polling occurs, oXs sent one data that is "availalble".
All data are not available with the same frequency. E.g. standard, Vspeed is available every 20 msec, Alt every 100 msec, Volt every 500 msec, ...
So if all data are sent, the enlapsed time between sending 2 Altitudes can vary a lot: it can be as short as 2*22 msec but also as long as about 6*22msec depending on which data become available.

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 8:13 pm

Where can I get the latest openXsensor?? I googled the Github page but the latest version I could find is 2.5?? :o
Where did all the tutorials go?? :o
Thanks

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Wed Jan 25, 2017 8:39 pm

Are you sure? I downloaded this version from Git today
Attachments
openXsensor-master.zip
(1.02 MiB) Downloaded 39 times

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 8:45 pm

Thanks. Link? I only found this for download..

https://github.com/openXsensor/openXsen ... _Downloads

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 8:50 pm

Ok, got it.. must download the Master..

Thank you

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Wed Jan 25, 2017 9:06 pm

Yes I am a bit lost sometimes too because there are several versions floating around the WWW and on different forums etc tweaked by this and that guy but when you open them up in the IDE you don't see a header file that tells you the date, version, revision history etc. I wish we had that. I can recognize early versions instantly but when you get to v.5 and v.7 I can't recognize which is which and what has been changed and where. Maybe I am just getting old. :(

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 9:15 pm

Funny that you say that, i was just trying to find out what version the oXs is at..
I remember that there was some documentation on how to connect stuff?
I would like for example to start reading individual cells on my models, as some of my batteries are getting a bit old and cells are not discharging equally, specially in winter. Would like a circuit diagram example, but can't find anything :(
Maybe I'm getting old too.. ;)
João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 9:25 pm

It would be nice if one could for example just use an Attiny85 flash with just a few features from oXs, like cells, or voltage and current.. Small number of pins anyway..
we could make some really simple and small oXs with just a few features.
I know the complete code wouldn't fit the ATtiny85, but maybe only some basic features would?
I don't need a complete arduino for only measuring the cells, or current. I have the feeling that it is a waste of a good board that could be used on something that needed more pins..
Just an idea..

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Wed Jan 25, 2017 9:32 pm

As far as I know the code size mainly depends on the defined features. If you only define a voltage sensor the compiler output should be quite small. Try it!

RightRudder
Posts: 241
Joined: Tue Jan 15, 2013 9:41 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by RightRudder » Wed Jan 25, 2017 9:34 pm

Also the oxs_config_description file has grown and contains much information including the circuit diagram example you are looking for

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Wed Jan 25, 2017 9:55 pm

Ok, will look.. thanks

But even if I reduce size, would it work on an ATTiny85?

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Thu Jan 26, 2017 10:03 am

RightRudder wrote:Yes I am a bit lost sometimes too because there are several versions floating around the WWW and on different forums etc tweaked by this and that guy but when you open them up in the IDE you don't see a header file that tells you the date, version, revision history etc. I wish we had that. I can recognize early versions instantly but when you get to v.5 and v.7 I can't recognize which is which and what has been changed and where. Maybe I am just getting old. :(
When the configurator has been created, one file containing the version number has been added. This file is named "version.oxs".
The issue is that this file is not displayed when you are in arduino IDE.

I can add a version number in the config.h file so it will be clear.
So, I can also remove the file "version.oxs". This file was only used by the configurator but this program is not supported anymore.

Normally the latest stable version is in the master branch on github. It is version 7.

I already put a beta version 8 as attachement on this forum because a user was asking to support bmp280 baro sensor.
This beta version supports also (at least partly) Jeti telemetry protocol.
Still this beta version is not yet stable because I did not yet tested the code for handling external 16 bits ADC.
When this part is tested, I will put this version 8 on Github.

mstrens
Posts: 1299
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens » Thu Jan 26, 2017 10:12 am

jhsa wrote:It would be nice if one could for example just use an Attiny85 flash with just a few features from oXs, like cells, or voltage and current.. Small number of pins anyway..
we could make some really simple and small oXs with just a few features.
I know the complete code wouldn't fit the ATtiny85, but maybe only some basic features would?
I don't need a complete arduino for only measuring the cells, or current. I have the feeling that it is a waste of a good board that could be used on something that needed more pins..
Just an idea..

João
oXs contains lot of code that refers directly to internal architecture of AVR328 (register, timers, ...).

I do not think it can run on ATtiny85.
Perhaps it should be possible to rewrite the code to support ATtiny85 (removing some of the functionalities) but I do not plan to do it.

User avatar
jhsa
Posts: 19121
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: New beta version of openXsensor (=openXvario)

Post by jhsa » Thu Jan 26, 2017 11:44 am

mstrens wrote:
oXs contains lot of code that refers directly to internal architecture of AVR328 (register, timers, ...).

I do not think it can run on ATtiny85.
Perhaps it should be possible to rewrite the code to support ATtiny85 (removing some of the functionalities) but I do not plan to do it.
Thanks for your reply. I suggested this because it is really a shame having to waste a complete arduino pro mini, or if building from scratch, a full m328, if your model just need the cells reading, or voltage and current, or voltage and temperature and RPM, like some IC powered model would..
And an ATtiny could make things smaller also.
Maybe someone in the future needs it and do it. I would if I knew how :) ;)

I believe that removing the whole vario code on the ATiny version would make the code much lighter and simpler?

Just an idea.

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW


Post Reply

Return to “OpenXVario - an open source vario supported by the open source firmwares!!”