New beta version of openXsensor (=openXvario)

Development & General Chat for the superb openxvario project.

Moderator: rainer

User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

@msterns:I made OXS with volt_1&2 send as A3 and A4 and it replaced A3&4 send by R8 RX. Where can I change A3& A4 ID in OXS, please?

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

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

All ID's from FrSky are defined in file oXs_out_frsky.h

e.g.
#define A3_FIRST_ID 0x0900
#define A3_LAST_ID 0x090f
#define A4_FIRST_ID 0x0910
#define A4_LAST_ID 0x091f

Still I fo not directly use those "define".
I use an array in oXs_out_frsky.cpp:
const uint8_t fieldId[22] = { 0x10 , 0x11 , 0x30 , 0x30 , 0x30 , 0x21 , 0x20 , 0x60 ,0x90, 0x91 , 0x80, 0x80 , 0x82 , 0x83 , 0x84 , 0x50 , 0x40 , 0x41 , 0xA0 , 0x70 , 0x71 , 0x72 } ; //fieldID to send to Tx (to shift 4 bits to left

The sequence in this array is fixed.
In order to save space in this array,
- I do not store 2 bytes but only 1 (the mid part); so 0X0910 becomes 0X91
- I always use the frst ID (so last 4 bits = 0) when sending the data to Tx
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

mstrens wrote: Wed May 06, 2020 7:11 am All ID's from FrSky are defined in file oXs_out_frsky.h

e.g.
#define A3_FIRST_ID 0x0900
#define A3_LAST_ID 0x090f
#define A4_FIRST_ID 0x0910
#define A4_LAST_ID 0x091f

Still I fo not directly use those "define".
Yes, I tried to modify those definition and nothing happened.
mstrens wrote: Wed May 06, 2020 7:11 am I use an array in oXs_out_frsky.cpp:
const uint8_t fieldId[22] = { 0x10 , 0x11 , 0x30 , 0x30 , 0x30 , 0x21 , 0x20 , 0x60 ,0x90, 0x91 , 0x80, 0x80 , 0x82 , 0x83 , 0x84 , 0x50 , 0x40 , 0x41 , 0xA0 , 0x70 , 0x71 , 0x72 } ; //fieldID to send to Tx (to shift 4 bits to left

The sequence in this array is fixed.
In order to save space in this array,
- I do not store 2 bytes but only 1 (the mid part); so 0X0910 becomes 0X91
- I always use the frst ID (so last 4 bits = 0) when sending the data to Tx
Thanks, so the solution for me could be to replace ...,0x90, 0x91 ,... sequence in that array with ...,0x95, 0x98 ,... IDs? Will OTX recognize them as A3 and A4 ?
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

The Tx will recongnise as A3 an message having an ID between 0x0900 and 0x090f
For A4 , it will be between 0X910 and 0X91f

The #define ... lines are just for documentation. So if you change them, it has no impact.
The program uses the code from line
const uint8_t fieldId[22] = { 0x10 , 0x11 , 0x30 , 0x30 , 0x30 , 0x21 , 0x20 , 0x60 ,0x90, 0x91 , 0x80, 0x80 , 0x82 , 0x83 , 0x84 , 0x50 , 0x40 , 0x41 , 0xA0 , 0x70 , 0x71 , 0x72 } ; //fieldID to send to Tx (to shift 4 bits to left

The position in this line is related to the oXs name (e.g. the 9th code (here 0X90) is for A3, the 10th (here 0X91) code is for A4.
If you replace 0X91 in this line by e.g. 0X93, and if you have e.g. #define A4_SOURCE ADS_VOLT_3, oXs will transmit the value of ADS_VOLT_3 using the code in the 10th position so using now 0X93. Still when oXs fill the code in the message being sent, it will convert 0X93 to 0X0930 (adding a 0 before and a 0 after in order to respect the message format).
This code 0X0930 will be received by Tx but it will not be recognised as A4 by the TX because it is not in the range 0X910/ 0X91f
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

OK, I will try it and will report the result...
When You will do next OXS upgrade, is it big job to modify the communication to use 16-bit array instead of 8-bit?

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

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

ddano007 wrote: Wed May 06, 2020 4:11 pm OK, I will try it and will report the result...
When You will do next OXS upgrade, is it big job to modify the communication to use 16-bit array instead of 8-bit?
It is not a big job but I did it in this way in order to save space in memory? Currently it is already probably not possible to activate all options because the AVR328p chip is short on memory.

I do not understand why you want to use A3/A4. I expect (not 100% sure) that OpenTx allows to use any ID and that you can assign the name your self.
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

mstrens wrote: Wed May 06, 2020 7:28 pmIt is not a big job but I did it in this way in order to save space in memory? Currently it is already probably not possible to activate all options because the AVR328p chip is short on memory.
OK, so let it be. I`m at around 35% used memory including DS1820 one wire files :roll:
mstrens wrote: Wed May 06, 2020 7:28 pmI do not understand why you want to use A3/A4. I expect (not 100% sure) that OpenTx allows to use any ID and that you can assign the name your self.
Because in one heli I have 2 BECs, so would be fine to have 6 analogs: Uesc, Iesc, Ubec1, Ibec1, Ubec2 and Ibec2. But I tried to replace IDs in array to 0x95 and 0x98 and it works. In T16 I can rename them...

Today I was testing OXS during flight ( GPS + 2xTemp) and GPS speed seems to be quite high. At the end I put model with powered on to car going home and: 35kmh was 61kmh in T16, 50khm was 89kmh and 100kmh was approx 180kmh on T16. It looks like knots to kmh conversion.
This is my OXS GPS config:

// --------- 9 - GPS --------------- see oXs_config_advanced.h for additionnal parameters (normally no need to change them)
#define A_GPS_IS_CONNECTED YES // select between YES , NO

and

// --------- 9 - GPS ------------------------------------------------------------------------------------------------
#define GPS_SPEED_IN_KMH // uncomment this line if GPS speed has to be sent in km/h instead of knot/h (only for Frsky protocol)
#define GPS_SPEED_3D // uncomment this line if GPS speed has to be the 3d speed instead of the 2d speed (note: 3d is probably less accurate - to test)
#define GPS_REFRESH_RATE 5 // rate at which GPS sent new data; select between 1, 5 or 10 (Hz). Default = 5 Hz; Ublox NEO6 does not support 10 hz

In T16 I have GPS speed in kmh. I changed second config to

// --------- 9 - GPS ------------------------------------------------------------------------------------------------
#define GPS_SPEED_IN_KMH // uncomment this line if GPS speed has to be sent in km/h instead of knot/h (only for Frsky protocol)
//#define GPS_SPEED_3D // uncomment this line if GPS speed has to be the 3d speed instead of the 2d speed (note: 3d is probably less accurate - to test)
#define GPS_REFRESH_RATE 10 // rate at which GPS sent new data; select between 1, 5 or 10 (Hz). Default = 5 Hz; Ublox NEO6 does not support 10 hz

and will test tommorrow...
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: New beta version of openXsensor (=openXvario)

Post by Kilrah »

OpenTX expects to receive GPS speed in knots as that's what the FrSky protocol defines, so you shouldn't send in km/h.
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

Kilrah wrote: Wed May 06, 2020 8:32 pm OpenTX expects to receive GPS speed in knots as that's what the FrSky protocol defines, so you shouldn't send in km/h.
OK, my fault, thanks :oops:
User avatar
Gruni0662
Posts: 3
Joined: Sun Jun 07, 2020 10:20 am
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Gruni0662 »

Hello,

i am new to this forum and i am looking to sort a problem with tho oXs software regarding Jeti EX/nonEX protocol.

I/we are using Jeti TU-modules in MPX-EVOs. nonEX-modules.

I understand, that oXs is supporting just EX-protocol, but while toying around, that, if i compile a firmware with just the flow meter active, the old Jetibox shows proper text instead of the .-.-.-.-.-. output when the vario is active.

So, is there any way to get the vario working with nonEX-protocol? What has to be changed?
Or is there already a .h or .cpp around to sort that problem.

Many thanks for any reply,
greets, Gruni
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

When you try the vario, did you also connected a baro sensor (MS5611, BMP...) to the arduino.
Compiling declaring a baro in the config but without having a baro sensor connected just blocks the arduino because it is waiting for data on the i2c bus.
This is not the case for the flow sensor because it does not use the i2c bus.
That could be the reason why getting .-.-.-.

Normally there is no difference in the way flow sensor and vario are transmitted.
User avatar
Gruni0662
Posts: 3
Joined: Sun Jun 07, 2020 10:20 am
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Gruni0662 »

Hello mstrens,

the baro BMP280 is connected, the vario is working in all MPX, FRSKY and HOTT.
Just the Jetibox/mini is showing no vario if configured as Protocol JETI.

Since the hardware stays is the same ( i configured one oxs with all four systems) it must be the software, here the JETI.

As the software regarding Jeti is dealing with the EX-protocol, that must be the problem.
Its just funny, that a proper text stream is showing up when configuring the flowmeter, even without the hardware.

Using the JetiPROFIBox, the datas for vario are shown ok. Its just a problem with Jetibox and Jetiboxmini.

My guess is, it depends on the oXs_out_jeti.cpp and/or oXs_out_jeti.h

So, what to do? And/or where to do?

Greets Stefan
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

Indeed the code that is Jeti protocol specific in the 2 files that you said.
I have no Jeti hardware; so I can't make tests.
The code I used for Jeti was based on some code that I found on internet a few years ago.
Most users that I know that uses oXs with Jeti connect directly oXs to the receiver and they get the data (e.g. the vario, Alt, Gps.
User avatar
Gruni0662
Posts: 3
Joined: Sun Jun 07, 2020 10:20 am
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by Gruni0662 »

Of course. I/we do the same, oXs is directly connected to the RX Dataport.

The difference might be, that the pilots you know are using original Jeti TXs like DC16, DS16,DS24 or DS12/14 ;-> and not the TU/TME-Modules in the TX like Evo, MC22, F14 and so on.

If the oXs is connected directly on an old Jetibox, they will see just the .-.-.-.-. line ;-<

We are using the old Jetiboxes with 4 keys.

Do you remember the old code from the past that you mentioned?

By the way: great work! Its working perfectly on the other systems. Thanks for that.

Greets Stefan
sandyjain
Posts: 2
Joined: Mon Oct 12, 2020 6:18 am
Country: India

Re: New beta version of openXsensor (=openXvario)

Post by sandyjain »

Kilrah wrote: Wed May 06, 2020 8:32 pm OpenTX expects to receive GPS speed in knots as that's what the FrSky protocol defines, so you shouldn't send in km/h.
I have set up my OXS for GPS Speed in KMH.
In my OTX in telemetry I have defined GPS speed in KMH.

In testing in my car, the Telemetry GPS Speed matches with the car odo and google maps on phone.

Yet in my MPX Funjet, the speeds are shown upto 416 KMH... why ?

Cheers..
Sandy Jain
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

Michel, is it possible to identify, when SPORT packed was sent?
I need to synchronize OneWire communication with SPORT communication and this seems to me the way: start OneWire communication just after SPORT data were sent.
Thanks, Daniel.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by mstrens »

In oXs_out_frsky.cpp, you can find this code (from line 1612)
else // 8 bytes have been send
{
frskyStatus |= 1 << sensorIsr ; // set the bit relative to sensorIsr to say that a new data has to be loaded for sensorIsr.
state = WAITING ;
When the program enter this "else" section, it means that a data frame has just been sent.
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

mstrens wrote: Tue Nov 17, 2020 11:55 am In oXs_out_frsky.cpp, you can find this code (from line 1612) ...
Great thanks, however I was not successful ...
Without DS1820 reading to SPORT sychro I had sometimes "peaks" on SatNums caused by SPORT communication problem. With sychro I have peaks on Alt cased by OXS timing influenced by DS1820... :lol:
It looks like implementing OneWire to OXS is not easy job for me...
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

Hi, guys.
I bought Aggressor FPV plane and installed Matek`s F411WSE flight controller there. I`m going to learn something about setup & tuning of INAV, however I noticed an interesting thing: at today`s flying INAV was reporting up to 25 satellites. In INAV I have enabled also Galileo satellites.
I have Beitian BN-220 GPS there, the same type, as I`m using with OXS in other planes. In OXS logs I can see up to 14 satellites.
Question maybe to mstrens: Could the difference be caused by using/ not using of Galileo satellites? Is OXS using Galileo satellites?
Thanks,
Daniel
User avatar
kalle123
Posts: 905
Joined: Sat Mar 29, 2014 10:59 am
Country: -
Location: Moenchengladbach

Re: New beta version of openXsensor (=openXvario)

Post by kalle123 »

At least Galileo shows up in oXs_gps.cpp

// Here the code to activate galileo sat. (This has not yet been tested and is based on I-NAV code)
0xB5,0x62,0x06,0x3E, 0x3C, 0x00, // GNSS + number of bytes= 60 dec = 003C in HEx
0x00, 0x00, 0x20, 0x07, // GNSS / min / max / enable
0x00, 0x08, 0x10, 0x00, 0x01, 0x00, 0x01, 0x01, // GPS / 8 / 16 / Y
0x01, 0x01, 0x03, 0x00, 0x01, 0x00, 0x01, 0x01, // SBAS / 1 / 3 / Y
0x02, 0x04, 0x08, 0x00, 0x01, 0x00, 0x01, 0x01, // Galileo / 4 / 8 / Y
0x03, 0x08, 0x10, 0x00, 0x00, 0x00, 0x01, 0x01, // BeiDou / 8 / 16 / N
0x04, 0x00, 0x08, 0x00, 0x00, 0x00, 0x01, 0x01, // IMES / 0 / 8 / N
0x05, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x01, // QZSS / 0 / 3 / N
0x06, 0x08, 0x0e, 0x00, 0x01, 0x00, 0x01, 0x01, // GLONASS / 8 / 14 / Y
0x30, 0xD8, // checksum


cu KH
User avatar
ddano007
Posts: 41
Joined: Thu Nov 13, 2014 8:40 pm
Country: Slovakia
Contact:

Re: New beta version of openXsensor (=openXvario)

Post by ddano007 »

kalle123 wrote: Fri Jan 08, 2021 7:34 am At least Galileo shows up in oXs_gps.cpp...
Thanks for tip, I will check my configuration a will try to make some tests on weekend.
EDIT 9.I.
So short report from today`s testing:
1, I checked my OXS config and I have enabled Galileo in oXs_gps.cpp as it is above ( to be exact: in INAV I have BN-200 or 220, in OXS have BN-180 ).
2, I had 12 sats out of home
3, I tried to disable GPS & GLONASS and leave only Galileo active, but the same result.
4, after I downloaded ublox center, connected BN-180 via FTDI to laptop and enabled Glalileo ( by default it was disabled )
5, after this I had 18 sats on OXS and the same number on INAV.
Next step will be on-fly comparison on- field.
At this moment it looks like BN-180 will not accept config from OXS... If anybody has an idea, what can I try, write it down.
AlessB
Posts: 31
Joined: Wed Mar 01, 2017 9:09 am
Country: Ukraine

Re: New beta version of openXsensor (=openXvario)

Post by AlessB »

Hi can i get the airspeed sensor values in the FrSky Hub protocol? I read docs, GPS speed not send values (GPS not activated only vario). Can I mapping field to send airspeed. I use ErskyTx in TX.
Option debug in oXs activated but I no see values in port monitor, only setup settings.
I use airspeed 4525 sensor.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: New beta version of openXsensor (=openXvario)

Post by Carbo »

Airspeed is not foreseen in hub-protocol. It should be possible to send airspeed using other fields like T1. But it is not prepared.

It is eventually much easier to flash D-RX with D16 firmware:

https://www.rcgroups.com/forums/showthr ... st42583371
AlessB
Posts: 31
Joined: Wed Mar 01, 2017 9:09 am
Country: Ukraine

Re: New beta version of openXsensor (=openXvario)

Post by AlessB »

Flash D-Rx with D16 only STM32 but my clone RX with AtMega.
bobcolo
Posts: 2
Joined: Sat Feb 20, 2021 10:05 am
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by bobcolo »

hello

I want to have to have on same arduino nano vario MS5611 and accelero MP6050 but both use same PIN A4 and A5
is there any possibility to use A0 and A1 for one of theme

thanks
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: New beta version of openXsensor (=openXvario)

Post by Carbo »

A4 and A5 (i2c bus) is OK for both. They are differentiated by the i2c adress.
bobcolo
Posts: 2
Joined: Sat Feb 20, 2021 10:05 am
Country: -

Re: New beta version of openXsensor (=openXvario)

Post by bobcolo »

thanks i will try
AlessB
Posts: 31
Joined: Wed Mar 01, 2017 9:09 am
Country: Ukraine

Re: New beta version of openXsensor (=openXvario)

Post by AlessB »

I tried to use airspeed in D8 protocol. I did it. Data is transmitted through the T2 field. I tried debug mode 4525 sensor. Didn't compile due to errors in the code.
Endorphin
Posts: 167
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Protocol selection for FlySky

Post by Endorphin »

Can someone please advise what protocol selection I should enable in the openXsensor for FlySky receivers.
I already have two in commission using BMP 280 on Frsky protocol.

Thanks,

Jim.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: New beta version of openXsensor (=openXvario)

Post by Kilrah »

Flysky isn't supported AFAIK.
It is compatible with :

The Multiplex receivers
The Frsky receivers : D series (HUB protocol) and X series (Smart Port protocol).
The Graupner receivers (Hott protocol)
The Jeti receivers (EX protocol only)

Post Reply

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