Merging/expanding OpenXVario branches

Development & General Chat for the superb openxvario project.

Moderator: rainer

RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Merging/expanding OpenXVario branches

Post by RaptorSense »

Hi OpenX* developers,

While playing around with the OpenXSensor code, I had a vision to merge various branches into one solution to support alternative sensors and multiple telemetry protocols.

Currently, I am adapting the OpenXSensor code in order to work with my self-developed sensor instead of a MS5611. The sensor is connected through the serial port and sends also airspeed and dTE. I have also the code for a single LPS331 sensor through I2C. Adding support for other sensors like BMP180 or MS4525DO should also be easy.
For the telemetry, there is already support for FrSky Hub, FrSky Sport and Jeti but Jeti support is now in a separate branch. I have also (partially) working code for the Multiplex Sbus protocol that could be added. There is enough knowledge available on the Net for other protocols.

Merging these pieces into a single codebase can improve this project significantly. In order to do so, we have merge and refactor the code to make it more modular. A clear plug-in architecture could stimulate others to add support for various sensors and telemetry protocols.

What do you think, is this worth the trouble (and feasible)?

Cheers, Sinan
Last edited by RaptorSense on Mon Jun 16, 2014 12:55 pm, edited 1 time in total.

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

Re: Merging/expanding OpenXVario branches

Post by jhsa »

wouldn't that make it more difficult for users to configure it??
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: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

Thanks for the interest you have for openXsensor.

I think that it makes sense to add more functionalities to openXsensor like airspeed mesurement, dTE calculation, support of other telemetry protocols and, for FrSky, automatic detection of the protocol to apply (hub or Sport) depending on the type of Rx.

It would be better to support other protocol inside the same branch instead of using different branches. So, it would be easier to provide and maintain all functionalities for all protocols.
Still this is not easy for the developpers because no one developper have all the hardware in order to check the code. E.G. I have only a Taranis with X8R and D4II.

I am not convince that it make a lot of sense supporting several sensors in order to get the same measurement (e.g. for altitude). A sensor like a MS5611 seems to be a good compromise between price (about 10$) and precision. It is very easy to find. So why adding others sensors for altitude and vertical speed.
I expect that most people building an openXsensor just buy the recomended hardware if it is cheap, easy to find and to assemble.

For the airspeed (and then dTE), I presume that the easier choise would be a sensor using I2C like the MS5611.
Bruneaux already use such a sensor with a high precision. I would have to make some research to find the reference.

This is just my meaning.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

jhsa wrote:wouldn't that make it more difficult for users to configure it??
One improvement could be to develop a kind of wizard in order to let the user answer some questions about the functionalities he want to activate and his hardware. This wizard could then generate automatically the config.h file.

Everything is possible but it requires time and some programming skills.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Merging/expanding OpenXVario branches

Post by jhsa »

yep, that is a good idea.. ;)
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

RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

Thank you for the quick response,
mstrens wrote: It would be better to support other protocol inside the same branch instead of using different branches. So, it would be easier to provide and maintain all functionalities for all protocols.
This is exactly what I was thinking about.
mstrens wrote: Still this is not easy for the developpers because no one developper have all the hardware in order to check the code. E.G. I have only a Taranis with X8R and D4II.
Availability of hardware remains a problem for the developers. I am a happy 9X and Taranis user but my friends at the club prefer the Multiplex and Jeti hardware. I could borrow a Multiplex set to implement the SBus protocol for them but it was not possible yet to get a Jeti system to test the Jeti code.
mstrens wrote:I am not convince that it make a lot of sense supporting several sensors in order to get the same measurement (e.g. for altitude). A sensor like a MS5611 seems to be a good compromise between price (about 10$) and precision. It is very easy to find. So why adding others sensors for altitude and vertical speed.
I expect that most people building an openXsensor just buy the recomended hardware if it is cheap, easy to find and to assemble.
For the pressure, MS5611 is still one of the best sensors on the market but there are also alternatives to experiment with like the LPS331 or BMP280. In fact, my dream of creating a modular architecture was more in the direction of supporting all kinds of other hardware like inertial sensors, AD converters, GPS, etc.
mstrens wrote:For the airspeed (and then dTE), I presume that the easier choise would be a sensor using I2C like the MS5611.
Bruneaux already use such a sensor with a high precision. I would have to make some research to find the reference.
Thanks for pointing to the Bruneaux’s work. I was looking for the field-id for ASPD and it seems that his airspeed sensor already uses the ASPD field.
jhsa wrote:wouldn't that make it more difficult for users to configure it??
mstrens wrote:One improvement could be to develop a kind of wizard in order to let the user answer some questions about the functionalities he want to activate and his hardware. This wizard could then generate automatically the config.h file.

Everything is possible but it requires time and some programming skills.
Indeed a good idea to develop a wizard for generating legal config.h files.

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

Re: Merging/expanding OpenXVario branches

Post by mstrens »

RaptorSense wrote: Thanks for pointing to the Bruneaux’s work. I was looking for the field-id for ASPD and it seems that his airspeed sensor already uses the ASPD field.
I am not sure that ASPD and dTE are already full supported by openTX. Those fields have been added to the list of telemetry fields (and as sources) by I think that there is not yet code to map the telemetry data from SPORT to those fields.
OpenTx developper should have to confirm this.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

That was my impression too but their product page says:
Just plug it in, and select the ASPD in your Taranis telemetry screen
http://www.alofthobbies.com/n2-airspeed.html
Sounds good...
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

RaptorSense wrote:That was my impression too but their product page says:
Just plug it in, and select the ASPD in your Taranis telemetry screen
http://www.alofthobbies.com/n2-airspeed.html
Sounds good...
Ok, I had an old information.
I just checked the source code of openTX and I find some code for Airspeed.
Here are the dataId that are used
#define AIR_SPEED_FIRST_ID 0x0a00
#define AIR_SPEED_LAST_ID 0x0a0f

Still I don't see code for dTE.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

Thanks for checking the OpenTX code. I was just writing a message to Bruneaux to ask for the dataid for ASPD.

For now, I am sending the dTE values through the VARIO_FIRST_ID and misusing T1 for the 'normal' vario.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

It’s working; I can display the correct airspeed on my Taranis screen and listen to the sound of the TE vario (at 3:30 in de morning :roll: ).

I don't understand the meaning of the vario settings in Taranis. I was hoping to create a silent zone but didn’t succeed yet. We will find out tomorrow, now it's time for zzzzzz......
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

RaptorSense wrote:It’s working; I can display the correct airspeed on my Taranis screen and listen to the sound of the TE vario (at 3:30 in de morning :roll: ).

I don't understand the meaning of the vario settings in Taranis. I was hoping to create a silent zone but didn’t succeed yet. We will find out tomorrow, now it's time for zzzzzz......
You can find more information on the vario settings in Taranis on this link
viewtopic.php?f=86&t=5081

There was a change from release 2.0.0.
It is still possible to have a dead zone if you want but you must define 2 logical switches based on the vertical speed ( or later on dTE) and then you activate the vario tones based on those logical switches.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

Thanks for the link, very helpful. It was just too late to recollect the new 2.0 logic.

I am trying to port the code to an 8MHz board now. Let's see how that works.
User avatar
Tempo
Posts: 83
Joined: Tue Feb 04, 2014 4:04 pm
Country: -

Adding Multiplex-Sensor-Bus MSB protocol

Post by Tempo »

RaptorSense wrote:Hi OpenX* developers,
...
For the telemetry, there is already support for FrSky Hub, FrSky Sport and Jeti but Jeti support is now in a separate branch. I have also (partially) working code for the Multiplex Sbus protocol that could be added. There is enough knowledge available on the Net for other protocols.
...
Cheers, Sinan
@Sinan
Friends with Multiplex equipment are interested in openXsensor.
I´m interested in implementing MSB-protocol to openXsensor. Adding alternative protocoll to FrSky-SmartPort or -Hub
Would you share your working code ?

@mstrens
Would you give assistance ?

(I can use my ACT-RC-system with MultiplexSensorBus for tests.I have added a selfmade and programmable unit for data output.)
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Adding Multiplex-Sensor-Bus MSB protocol

Post by mstrens »

Tempo wrote:
RaptorSense wrote:Hi OpenX* developers,
...
For the telemetry, there is already support for FrSky Hub, FrSky Sport and Jeti but Jeti support is now in a separate branch. I have also (partially) working code for the Multiplex Sbus protocol that could be added. There is enough knowledge available on the Net for other protocols.
...
Cheers, Sinan
@Sinan
Friends with Multiplex equipment are interested in openXsensor.
I´m interested in implementing MSB-protocol to openXsensor. Adding alternative protocoll to FrSky-SmartPort or -Hub
Would you share your working code ?

@mstrens
Would you give assistance ?

(I can use my ACT-RC-system with MultiplexSensorBus for tests.I have added a selfmade and programmable unit for data output.)
For sure I can help you.
Please note that:
- if you plan to integrate Multiplex code, best would be to start from the new version from OXS that I am working on (and so, not on the current version available on google).
As you probably know, the future OXS version will support 2 MS5611 and a 4525DO (airspeed). There are also some bug fixes.
If you want, I can send you already the current code, but there will probably be some further light changes.
- the Jeti branch as not been maintained since several months (I never worked on) and there should be some work to merge it with the current Frsky version.
User avatar
rainer
Posts: 391
Joined: Tue Jan 01, 2013 9:20 pm
Country: Germany
Location: near Düsseldorf

Re: Merging/expanding OpenXVario branches

Post by rainer »

The main intention when i restarted from oXv to oXs was to seperate the various code pieces into individual classes. the communication to the groundstation was seperated from the sensor logic.
So in general i would recommend to create new classes for different telemetry protocols as the main oXs code should be prepared for this.
build your own vario ==> https://github.com/openXsensor/openXsensor/wiki (Formerly https://code.google.com/p/openxsensor/ and https://code.google.com/p/openxvario/)
User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: Merging/expanding OpenXVario branches

Post by Rob Thomson »

Hey guys...

Whats the status on the jeti branch?

I have aquired a DC16.

Does it all work? Or testing needed?

Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

Rob Thomson wrote:Hey guys...

Whats the status on the jeti branch?

I have aquired a DC16.

Does it all work? Or testing needed?

Rob
During the last 9 months, I made quite many changes to openxsensor but only for the Frsky protocols (hub and sport).
I never looked at the jeti branch. So I have no idea if it works or not (and which functionalities are implemented and which are not).
Perhaps some one else can provide more info.
User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: Merging/expanding OpenXVario branches

Post by Rob Thomson »

Did the original jeti branch work?

My time ia a touch limited - but assuming that the original works I will sort out a jeti code port and test.
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
User avatar
Henning
Posts: 14
Joined: Fri Feb 15, 2013 8:28 am
Country: Germany

Re: Merging/expanding OpenXVario branches

Post by Henning »

Hello Rob,

congratulation to the DC-16 transmitter - its REALLY a nice big block of HW (and SW), isn't it? ;-)

And yes, the original Jeti openXvario branch works well. I designed a DIY PCB for it (all-in-one, much smaller than a Pro Mini but HW compatible), then built up 5 sensors of this type and used it for > 1 year with my DC-16 in different models (gliders and electric).
Of course, the branch is based on a old openXvario source, so I think the improvements done there could be worth doing a "clean" integration into the current, more modular code concept.

As I wrote in another thread, I changed the code to C in the meantime (also using Barry-Dorr filtering instead kalman and a menu-driven configuration by jetibox emulation of DC-16), so I did not continue working with the openXvario code since then.

Regards,
Henning
User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: Merging/expanding OpenXVario branches

Post by Rob Thomson »

Henning wrote:Hello Rob,

congratulation to the DC-16 transmitter - its REALLY a nice big block of HW (and SW), isn't it? ;-)

And yes, the original Jeti openXvario branch works well. I designed a DIY PCB for it (all-in-one, much smaller than a Pro Mini but HW compatible), then built up 5 sensors of this type and used it for > 1 year with my DC-16 in different models (gliders and electric).
Of course, the branch is based on a old openXvario source, so I think the improvements done there could be worth doing a "clean" integration into the current, more modular code concept.

As I wrote in another thread, I changed the code to C in the meantime (also using Barry-Dorr filtering instead kalman and a menu-driven configuration by jetibox emulation of DC-16), so I did not continue working with the openXvario code since then.

Regards,
Henning
Hello

Indeed. Its the only radio I have liked as much as the opentx / er9x based radios.

Simply fantastic!

I would love to look at building one of your varios. Do you have any more information?

Rob
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
User avatar
Henning
Posts: 14
Joined: Fri Feb 15, 2013 8:28 am
Country: Germany

Re: Merging/expanding OpenXVario branches

Post by Henning »

Hi Rob,

if you don't mind my german description, you can find some info here:
myVario Homepage

The pictures should tell the story - otherwise google translate may help ;-) ?

Image

Regards,
Henning
User avatar
tilmanb
Posts: 347
Joined: Thu Oct 11, 2012 9:36 pm
Country: Germany
Location: Karlsruhe, Germany

Re: Merging/expanding OpenXVario branches

Post by tilmanb »

Nice boards.
Would you mind sharing your designs. Perhaps one could manufacture a small production run.
I suppose it could still run openxvario?
Same goes for the sources. Can't tell what is worth to be merged into the openxvario by but the remote configuration but is clearly a nice thing to have.

I'm not making demands. But if I see things like that instantly see potential for cross insemination.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Adding Multiplex-Sensor-Bus MSB protocol

Post by RaptorSense »

mstrens wrote:
Tempo wrote: @Sinan
Friends with Multiplex equipment are interested in openXsensor.
I´m interested in implementing MSB-protocol to openXsensor. Adding alternative protocoll to FrSky-SmartPort or -Hub
Would you share your working code ?

@mstrens
Would you give assistance ?

(I can use my ACT-RC-system with MultiplexSensorBus for tests.I have added a selfmade and programmable unit for data output.)
For sure I can help you.
Please note that:
- if you plan to integrate Multiplex code, best would be to start from the new version from OXS that I am working on (and so, not on the current version available on google).
As you probably know, the future OXS version will support 2 MS5611 and a 4525DO (airspeed). There are also some bug fixes.
If you want, I can send you already the current code, but there will probably be some further light changes.
- the Jeti branch as not been maintained since several months (I never worked on) and there should be some work to merge it with the current Frsky version.
Sorry for this very late reply, I couldn’t participate in this discussion for a while.

Just discovered the new openXsensor and the myVario project for Jeti. Very nice to see these new developments. I will download the new openXsensor sources to see if I can merge the Multiplex protocol implementation.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

If you want more explanation on OXS in order to implement multiplex protocol, just ask for.
E.g. it is easy to provide you the names of the variables that contains the fields that couls be transmitted.
In order to integrate both protocols into one version (to setup with some #define), I think it is important to use timer1 for serial communication.
Take care that timer 1 is used not only for serial comminication but also for RPM and micros() + millis(). So, best would be to reuse similar code to Aserial.
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

I see that the current code (new oXs 2.5) is still based on the old ASerial.cpp whereby the soft serial functionality is mixed with the FrSky protocol. A more modular setup would make it easier to extend the code.
In my vario, a custom version of the standard Arduino soft serial library is used for all protocols. I have just added minimal half duplex functionality and adapted some timing values for 8 MHz. Unfortunately, my code base is developed completely independent of oXs, so it is not possible to just copy/paste some code. I will try to refactor the oXs code to make it more modular and send a proposal here.

The standard Arduino micros() and millis() are working fine for me but I am not sure about the RPM. Would it conflict with the Arduino soft serial?
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Merging/expanding OpenXVario branches

Post by MikeB »

The standard micros() and millis() leave interrupts disabled for too long for reliable SPort data transfer using soft serial at 57600 baud.
That's why I wrote the different versions.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by mstrens »

MikeB wrote:The standard micros() and millis() leave interrupts disabled for too long for reliable SPort data transfer using soft serial at 57600 baud.
That's why I wrote the different versions.

Mike.
Mike,
If remember correctly,
- you wrote the Aserial (instead of the standard software library) because, in SPORT, OXS had to react in a quite short time to a pooling request coming from the TX.
- we had some issues too with the original millis() or micros(); a newer returned values was not always greater than a previous one (I think).

So, there are good reasons to keep Aserial in OXS.

Still, I think that it should not be too difficult to adapt the code in order to use it for multiplex protocol.
In fact, as said in the file, Aserial is based on some code made by Atmel. You can look at Atmel AVR304: Half Duplex Interrupt Driven Software UART.
The easiest would probably be to add a completely new file (named e.g. Mserial for Multiplex serial) that would be included instead of Aserial when multiplex protocol is used.

One attention point to check: if multiplex protocol works at a low speed, it could be that it would require another value for the timer 1 prescaler. This would then generates some issues for the services that use timer 1 too. An alternative could then be to use another timer for serial communication.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Merging/expanding OpenXVario branches

Post by MikeB »

You are correct with regarding Aserial and the SPort response time and also millis() and micros().

Timer 1 wraps round in 4.096 mS, so this is the longest bit time for a serial interface. This corresponds to 250 buad which is already very slow.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
RaptorSense
Posts: 30
Joined: Sun Feb 16, 2014 11:50 pm
Country: -

Re: Merging/expanding OpenXVario branches

Post by RaptorSense »

I have done it slightly different.
- Adapted the standard Arduino SoftSerial to work in half-duplex mode
- Used a custom interrupt-free timer for the timing

The timer code is very simple:

Code: Select all

// 2-4-2014    Sinan Inanc
// 22-6-2014   Seconds function removed, 
//             _timerBlockBase added to save one multiplication
#include "TimeKeeper.h"

  // cs12  cs11  cs10
  //   0     1     0   clk/8
  //   0     1     1   clk/64
  //   1     0     0   clk/256
  //   1     0     1   clk/1024
void TimeKeeperClass::Init()
{
  TCCR1A = 0;   // Timer1, reset all bits to enable normal timer mode
  TCCR1B = 5;   // Prescaler,  1 0 1   clk/1024
  _tickDuration_ms = 1000.0 * 1024.0 / (double)F_CPU;
  _timerBlockBase = 0;
  _timerBlockCount = 0;
  _prevTimerTick = 0;
}

double TimeKeeperClass::Milliseconds()
{
  if (TCNT1 < _prevTimerTick)
  {
    incrementTimerBlockCount();
  }
  _prevTimerTick = TCNT1;
  return _tickDuration_ms * (double)(_timerBlockBase + TCNT1);
}

void TimeKeeperClass::incrementTimerBlockCount()
{
  _timerBlockCount++;
  _timerBlockBase = _timerBlockCount * 65536;
}

TimeKeeperClass TimeKeeper;
It is not an universal solution. You have to call the Milliseconds() function regularly to let it work correctly. But thats no problem in this case and as far as I can see, it doesn't conflict with other libraries that I am using.

Post Reply

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