New beta version of openXsensor (=openXvario)
Moderator: rainer
Re: New beta version of openXsensor (=openXvario)
@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?
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
Yes, I tried to modify those definition and nothing happened.
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 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
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
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?
When You will do next OXS upgrade, is it big job to modify the communication to use 16-bit array instead of 8-bit?
Re: New beta version of openXsensor (=openXvario)
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.
Re: New beta version of openXsensor (=openXvario)
OK, so let it be. I`m at around 35% used memory including DS1820 one wire files
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
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...
Re: New beta version of openXsensor (=openXvario)
OpenTX expects to receive GPS speed in knots as that's what the FrSky protocol defines, so you shouldn't send in km/h.
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
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.
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.
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
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.
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.
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
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
Re: New beta version of openXsensor (=openXvario)
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.
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.
Re: New beta version of openXsensor (=openXvario)
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.
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.
Re: New beta version of openXsensor (=openXvario)
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...
![Laughing :lol:](./images/smilies/icon_lol.gif)
It looks like implementing OneWire to OXS is not easy job for me...
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
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
// 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
Re: New beta version of openXsensor (=openXvario)
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.
Re: New beta version of openXsensor (=openXvario)
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.
Option debug in oXs activated but I no see values in port monitor, only setup settings.
I use airspeed 4525 sensor.
Re: New beta version of openXsensor (=openXvario)
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
It is eventually much easier to flash D-RX with D16 firmware:
https://www.rcgroups.com/forums/showthr ... st42583371
Re: New beta version of openXsensor (=openXvario)
Flash D-Rx with D16 only STM32 but my clone RX with AtMega.
Re: New beta version of openXsensor (=openXvario)
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
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
Re: New beta version of openXsensor (=openXvario)
A4 and A5 (i2c bus) is OK for both. They are differentiated by the i2c adress.
Re: New beta version of openXsensor (=openXvario)
thanks i will try
Re: New beta version of openXsensor (=openXvario)
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.
Protocol selection for FlySky
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.
I already have two in commission using BMP 280 on Frsky protocol.
Thanks,
Jim.
Re: New beta version of openXsensor (=openXvario)
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)