openrcforums

For my opinion the most important point is : sensor + arduino + GY 521 + C script embedded in the plane.
https://superair78.wordpress.com/4-la-t ... n-arduino/
LUA script is just a "cosmetic" tool to display the parameters on the radio. You can write a specific code for that.

Or Perhaps I don't even need a script..

João

Maybe naive question ( to mstrens): isn`t it possible to add FlySky iBus protocol to OXS project? I found some small projects for DIY sensor for FlySky ia6B/ ia10B receivers, but nothing so complex as OXS...

do you have a link to a documentation on the FlySky iBus protocol?

Not exactly...
Some basic wiring:
https://github.com/betaflight/betafligh ... -telemetry
Here is type definitions
https://github.com/qba667/FlySkyI6/blob ... elemetry.h
from this project:
https://github.com/qba667/MAVLinkToIbus ... LinkToIBUS
My list of some small projects/ libraries:
https://forum.arduino.cc/index.php?topic=548520.0
https://www.arduinolibraries.info/libraries/i-bus-bm
https://github.com/bmellink/IBusBM
http://blog.dsp.id.au/posts/2017/10/22/ ... -protocol/
https://gitlab.com/timwilkinson/FlySkyIBus
https://github.com/Yenya/ibus-altitude-sensor

I am not sure it should be possible to support this protocol with oXs.
This protocol uses 115200 baud rate which is quite fast for oXs because oXs does not use the hardware UART to communicate with the Rx. It uses a sofware serial UART because some protocol like FRSKY uses an inverted signal (not supported by the hardware UART).

oXs reserves then the hardware UART for reading the GPS.

mstrens wrote: ↑Fri Sep 20, 2019 7:59 pm I am not sure it should be possible to support this protocol with oXs.
This protocol uses 115200 baud rate which is quite fast for oXs because oXs does not use the hardware UART to communicate with the Rx. It uses a sofware serial UART because some protocol like FRSKY uses an inverted signal (not supported by the hardware UART).

oXs reserves then the hardware UART for reading the GPS.

Oh, that`s pity.
However thanks for reply.

This will be a very newb question.. In config basic you have Data to transmit ..on each item you can choose volt 1, volt 2 etc. Exactly what do the volt 1 volt 2 , ads volt1 etc. represent ?..I have fumbled my way thru to have a ms5611 , mpu6050 , GPS , current sensor , voltage sensor all working great. But in reality I have kinda just stumbled along ..For instance if I wanted to display fuel..In data to transmit which voltage would I choose ?
Just want to understand more

Thanks
Allen

Hi Allen,

not sure, if my boring german video can be helpful for you. You can watch me configuring a simple voltage-measurement. Don't try subtitles or automatic translation, unless you want to laugh It's hard to understand for native germans also
https://www.youtube.com/watch?v=ZLKmGbSvDp8
The safest way is to work with mstrens oXs_config_description.h, which is the official manual.

Carbo I love your videos !!! I've got everything working , i was just wondering in extra items to display, what is the meaning of volt 1, volt 2 adsvolt 1 etc. . And if i wanted to display fuel in mah how would I get it to work . I've read the description file many times..maybe I missed it..Wouldn't be to suprising for a OKIE to miss something

Thanks
Allen

antlerhanger wrote: ↑Sat Oct 05, 2019 9:15 pmI've got everything working , i was just wondering in extra items to display, what is the meaning of volt 1, volt 2 adsvolt 1 etc. . And if i wanted to display fuel in mah how would I get it to work.

VOLT_1, VOLT_2, VOLT_3 , VOLT_4, VOLT_5 , VOLT_6, ADS_VOLT_1, ADS_VOLT_2, ADS_VOLT_3, ADS_VOLT_4 are oXs internal variables for voltages, coming from Arduino analog-in or from ADS1115 16bit A/D. In oXs_config_basic.h you can assign them to nearly any FrSky/OpenTX variable. It is very flexible, you can use an acceleration variable to transmit a voltage (but take care of precision).

If you use OpenTX a calculated sensor "Consumption" with your current sensor as source calculates mAh. No need to use the FrSky/OpenTX Fuel variable. In oXs it is only possible by default to transmit a voltage in "Fuel".

"2.1 - Frsky data" in oXs_config_basic.h shows the FrSky/OpenTX variables on the left side and the available oXs internal variables on the right side. You decide, which data you transmit in which field.

Come on, it's easy I only needed to send mstrens about 214 emails to understand the basics

Thanks for the information !!! I have my current sensor on a2 on the arduino .. My current reading on the radio is dead on in telemetry . Even in fuel I now get total mah cunsumed but it reads the same as mah ..I guess what I was looking for is a percentage of the total mah used from the battery (which is a 3 cell 2200 mah bat. ) ..I use erskyTX not openTX , so there is probably a little difference there .. It's no biggie I was just wanting to see if I could make it work that way. I have everything working as far as sensors..Ms5611,npu6050, current sensor, I used the older voltage sensor on A0 and it reads dead on . Gps works so I was just being greedy I guess

Thanks for the help
Allen

I don`t know, whether it was here, but just briefly tested this GPS:
https://www.banggood.com/BN-200-Small-S ... rehouse=CN
It works, can run on 10Hz, first fix after received from BG < 3min, hot fix < 5sec. Good price, good dimension, I will continue testing
Question to mstrens: isn`t it possible to send number of fixed satellites via telemetry?

In this sketch you can find the modified files. If you modify the config files for your need it should work. IIRC changes are in openXsensor.ino and oXs.gps.cpp.

https://openrcforums.com/forum/viewtopi ... 07#p144819

Carbo thanks. Do You use any keywords at Your changes to be found?
One more question: Is there any flag of GPS 3D fix?
It can be included in satnum:
if 3D fix == 0 => satnum = satnum
if 3D fix == 1 => satnum = 100 + satnum

EDIT: OK, I found

test1.value = GPS_numSat ;
test1.available = true ;
test2.value = GPS_hdop;
test2.available = true ;

in *.ino.

What is it GPS_hdop and GPS_fix_type ?

ddano007 wrote: ↑Tue Oct 22, 2019 8:26 amWhat is it GPS_hdop and GPS_fix_type ?

Dilution of Precision, there are some articles on the web. Btw. some think oXs HDOP is indeed PDOP, but i did not dig deeper. Not sure about GPS-fix-type. Eventually @mstrens knows exactly. 2D/3D fix probably.

Meanwhile I've found the changes for number of sats and HDOP in oXs:

I just put a new version of oXs on github.
I added 2 options in oXs_config_advanced.h in order to fill TEST1 with number of sat and TEST2 with hdop.
As asked, number of sat is increased by 100 when there is a GPS 3D fix (or higher).

Please note that this version contains a new functionality but it is not yet documented.
oXs can be connected to a sx1276 modem device.
It allows to transmit some GPS data using this long range modem device.
There is another set of programs that allows to use another sx1276 modem to receive the data connected to an arduino and a display.
This is foreseen to retrieve a model if it is not anymore with the TX.
It is even possible to put the receiving part in another model and to fly over the aera where the model was lost.
This increase a lot the possibility to get a signal from the lost model.
The display keeps the last GPS position received and so when the second model goes back you can get the position of the lost model.
oXs in the lost model can be connected using a separate small battery in order to increase reliability.
His consumption is low, because it sent only when the device with the display ask for data.
I can make a full doc if request.

mstrens wrote: ↑Tue Oct 22, 2019 10:12 am I just put a new version of oXs on github.
I added 2 options in oXs_config_advanced.h in order to fill TEST1 with number of sat and TEST2 with hdop.
As asked, number of sat is increased by 100 when there is a GPS 3D fix (or higher).
...

Good job, Your project has one big problem, has no donation link and You are quite far from me to send You a beer. Non alcohol, of course
It works, some photo from my today`s testing:
Start... no 3D fix, just 4 sats 3D fix at 6 sats final status I send it as 10*AccX and 10*AccY, so my user`s config in Taranis X9D: My OTX version My test devices Great thanks!

Guys, is it possible to use MS5611 as temperature source ...

#define T1_SOURCE MS5611

... in FrSky HUB/ SPORT protocol? It is an option in Jeti...

//#define TEMPERATURE_SOURCE NTC // select between MS5611 and NTC

..., will it work in FrSky too? Thanks.

It should be possible but it is not reliable.
oXs read the sensor 50 times /sec. This increase by a few degrees the temperature of the sensor.

Hi mstrens.

See, that you a new version 8.2.13 is out.

// --------- 12 - Locator ---------------
#define A_LOCATOR_IS_CONNECTED NO // select between YES , NO

Would be nice to have some words explaining in 'oXs_config_description.h'

Best regards - KH

Ok, I will write some doc about the locator.

mstrens wrote: ↑Fri Oct 25, 2019 9:48 am It should be possible but it is not reliable.

No...
Not working with only

#define T1_SOURCE MS5611

in oXs_config_basic.h
I tried to add

#elif defined(T1_SOURCE) && ( T1_SOURCE == MS5611)
p_measurements[16] = &oXs_MS5611.varioData.temperature ;
idToReply |= 0x10 ;

to oXs_out_frsky.cpp, but no result...

This option was not foreseen in the code.
Still if you want to test it, you can try adding following lines at the end of the function calculateAllFields() in file .ino (it is around line 1219)

if ( oXs_MS5611.varioData.climbRate.available ) {
test1.value = oXs_MS5611.varioData.temperature ;
test1.available = true ;
}

Just tested the configurator in WIN 10 64 bit and WIN 7 64 bit.

@mstrens. You are presenting a lot of new features to us

br KH

It is not new features. It is just an easier way to make the setup.

I replaced the version of oXsConfigurator on Github.
The new version support more parameters and protocols.
It also allows to read directly the doc provided in oXs_config_description.h

I did not test all parameters.
So, if you find bugs, just let me know

Thank you soooo much Michel.

João

mstrens wrote: ↑Sat Oct 26, 2019 4:47 pm Ok, I will write some doc about the locator.

Thank you for adding those lines in latest 'oXs_config_description.h'.
Now I think, I understand. Components and wiring.

These are the modules, used.
https://de.aliexpress.com/item/32792288 ... b201603_55

br KH

I presume it is the same.

Here the link of what I used
https://de.aliexpress.com/item/32847199 ... 4c4dAeBvai

You need 2 modules (one for oXs and one for the "locator receiver"