OpenTX 2.1 telemetry system preview

openTx has introduced a range of new features, ideas and bling. It is fast becoming the firmware of choice for many users. openTx will run on ALL current hardware platforms, including the gruvin9x and sky9x boards. Work has already started to support the new FrSky X9D radio!
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

2.1 makes it possible to integrate mavlink due to its flexibility, there are however no plans by the core team to do it at this point. Any third party is welcome to integrate it.

Diablol
Posts: 39
Joined: Fri May 23, 2014 4:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Diablol »

How is it progressing? A lot of work to do for a first final? Difficult?

Good job so far.

How is the further progress planed? When can you expect first docs for lua access?
ilihack
Posts: 2
Joined: Tue May 12, 2015 4:23 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by ilihack »

Thank you Kilrah for you Answer. :)
okay i made an new request on the GitHub/Master core branch for OpenTx.

if they say no, than i try the Teensy solution merci.

greats.
ilyas
frater
Posts: 77
Joined: Sat Aug 30, 2014 11:04 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by frater »

Are the current nightlies capable of accessing the telemetry from LUA?
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by bertrand35 »

Yes!

Diablol
Posts: 39
Joined: Fri May 23, 2014 4:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Diablol »

and how??
Patterndave
Posts: 1
Joined: Thu Jun 11, 2015 11:04 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Patterndave »

Will the telemetry latency be reduced with this new version? The reason I am interested is that I have noted a .5 second time lag in log files from a N2 airspeed sensor and I have an application for airspeed that has shown sensitivity to this lag.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

OpenTX does not introduce any delay in the telemetry feed, if there is some it would come either from the sensor or RF chain.

Pressure sensors require quite a lot of filtering to get decent signal to noise ratios and 0.5s sounds already quick for an airspeed sensor, so I'd think most of that delay is introduced by the sensor itself.
pekote
Posts: 7
Joined: Sat Apr 18, 2015 4:03 am
Country: Argentina

Re: OpenTX 2.1 telemetry system preview

Post by pekote »

This telemetry update is getting more and more similar to the DCS (Distributed control systems) industrial systems I use to work.

I/O configuration, ranges, alarming, etc... I think that there are a few things that could be missing like "data quality" (it could be probably implemented), data time stamp, alarm lists and event lists... but this is probably too much for a radio.

Well done!!

Looking forward to see it implemented asap!!
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by bertrand35 »

Diablol wrote:and how??
It's the same than before, except labels which now are the same than the ones in your telemetry screen:
For example: getValue("Alt")

You can have max / min for all telemetry values with getValue(<label>+) and getValue(<label>-)
For example: getValue("Alt+")
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by bertrand35 »

pekote wrote:This telemetry update is getting more and more similar to the DCS (Distributed control systems) industrial systems I use to work.

I/O configuration, ranges, alarming, etc... I think that there are a few things that could be missing like "data quality" (it could be probably implemented), data time stamp, alarm lists and event lists... but this is probably too much for a radio.

Well done!!

Looking forward to see it implemented asap!!
It is implemented!
You can download Companion 2.1 and flash OpenTX 2.1 from there.
Here is the link for Companion 2.1:
http://downloads-21.open-tx.org/companion/
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

I think what he means is "released" :)
Diablol
Posts: 39
Joined: Fri May 23, 2014 4:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Diablol »

I kind of read some things about the SWR "problems" in 2.1...but what exactly happened with it.
Because I have no SWR value in 2.1?! But I need it. Can someone please explain the status. :?:
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

It's supposed to be like before I.e if your module hardware version supports SWR it shows up, otherwise it doesn't.

Envoyé de mon GT-I9505 en utilisant Tapatalk
User avatar
bob195558
Posts: 2377
Joined: Sun Dec 16, 2012 7:24 pm
Country: United States
Location: New England, Vermont
Contact:

Re: OpenTX 2.1 telemetry system preview

Post by bob195558 »

The SWR dose not show a value until you almost loses the telemetry signal it dose not work like the good old TSSI signal.
When you loses the SWR signal, Taranis will tell you, plus you will have no telemetry data.
The RSSI RX signal is one of the most important of your telemetry sensors. :)

Bob B.
Er9x on 9x radio, with Smartieparts Programmer and TelemetrEZ Board.
ErSky9x on Taranis, Sky9x, 9Xtreme radios.
3D-Printing: (https://openrcforums.com/forum/viewforum.php?f=129).
Diablol
Posts: 39
Joined: Fri May 23, 2014 4:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Diablol »

hm so you both say the opposite?

I also think it should be like before. But I HAD SWR with 2.0.x and NOT with 2.1. ? So is that normal or not?
I think SWR has not much to do with the RSSI. It is a small indicator how well the antenna is placed. And the position especially for mods are not trivial.
Last edited by Diablol on Fri Jun 19, 2015 8:06 pm, edited 1 time in total.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

SWR is completely unrelated to RSSI, is not a "signal" and Bob's answer is completely out (sorry).
If you lost SWR between 2.0 and 2.1 there might be a bug worth reporting. Make sure you're using the latest builds first and don't forget to state which exact radio version you have. My tests with my 2 radios some time ago were OK.

Envoyé de mon GT-I9505 en utilisant Tapatalk
Bamfax
Posts: 5
Joined: Fri Jun 19, 2015 11:37 pm
Country: Germany

Re: OpenTX 2.1 telemetry system preview

Post by Bamfax »

bertrand35 wrote:@diablol don't hesitate to check with the logic analyser, I am speaking about SPORT delays. None of the forks I tried answered correctly to the receiver polling! The result: you get duplicate sensors (each new ID received creates a new sensor ...) until the limit of 32 sensors is reached, it was just not useable.
I started from 'master' on chsw, did you check it?
Trying to have multiple RPM sensors logging for my quad, I was happy to throw away my old models and have a go at 2.1. It is one mighty telemetry overhaul which really makes that easy - thank you very much for it.

Betrand, I have tried your fixed Mavlink2FrSky commit with 2.0.99 on Taranis and I can confirm that it does not populate duplicate zombie sensors in the taranis telemetry settings. I had checked with Wolke's/Wolkstein's fork, this does generate zombie sensors, which are created at beginning, and then are never updated again. I have not yet had the chance to take a look at other forks.

But to me it also looks like what Diablol reported, the FrSkySPort_SendPackage() are slow, at an interval of 1s and more. What I did was to just connect a Teensy 3.1, reduce your fork to just the RPM sensor logging, and dump each SendPackage() on the serial. I did not incorporate the serial.c changes you mentioned. Could that be it - how would I incorporate those? (sorry, I am not into these dev things).

Here is the log of the serial dump, with my single RPM sensor logging two dataIds:

Code: Select all

Millis: 5638,  sensorId: 5,  dataId: 501, value: 1388
Millis: 9383,  sensorId: 5,  dataId: 500, value: 1742
Millis: 13127,  sensorId: 5,  dataId: 501, value: 1780
Millis: 16871,  sensorId: 5,  dataId: 500, value: 1158
Millis: 20615,  sensorId: 5,  dataId: 501, value: 1028
Millis: 24359,  sensorId: 5,  dataId: 500, value: 1048
Millis: 28104,  sensorId: 5,  dataId: 501, value: 1961
Olli
Bamfax
Posts: 5
Joined: Fri Jun 19, 2015 11:37 pm
Country: Germany

Re: OpenTX 2.1 telemetry system preview

Post by Bamfax »

I had a quick look at Pawelsky's FrSky S.Port Telemetry library (http://www.rcgroups.com/forums/showthread.php?t=2245978) and with the included example ino it looked very good at the first glance. No stale zombie sensors in Taranis / OpenTX 2.0.99. Updates seemed to come in fast (telling by quick star flickering, not looking at millis in depth). Maybe someone else can have a look and confirm.
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by bertrand35 »

Bamfax wrote:
bertrand35 wrote:@diablol don't hesitate to check with the logic analyser, I am speaking about SPORT delays. None of the forks I tried answered correctly to the receiver polling! The result: you get duplicate sensors (each new ID received creates a new sensor ...) until the limit of 32 sensors is reached, it was just not useable.
I started from 'master' on chsw, did you check it?
Trying to have multiple RPM sensors logging for my quad, I was happy to throw away my old models and have a go at 2.1. It is one mighty telemetry overhaul which really makes that easy - thank you very much for it.

Betrand, I have tried your fixed Mavlink2FrSky commit with 2.0.99 on Taranis and I can confirm that it does not populate duplicate zombie sensors in the taranis telemetry settings. I had checked with Wolke's/Wolkstein's fork, this does generate zombie sensors, which are created at beginning, and then are never updated again. I have not yet had the chance to take a look at other forks.
Ah thanks!
Bamfax wrote:But to me it also looks like what Diablol reported, the FrSkySPort_SendPackage() are slow, at an interval of 1s and more. What I did was to just connect a Teensy 3.1, reduce your fork to just the RPM sensor logging, and dump each SendPackage() on the serial. I did not incorporate the serial.c changes you mentioned. Could that be it - how would I incorporate those? (sorry, I am not into these dev things).
I didn't try to improve speed at all, only fix the protocol which was sent, it was really wrong.
I talked with Adela @ FrSky, we will add new fields for Ardupilot / OpenPilot.
I just need a couple of hours in my spare time to spend on the Teensy and it will be done.

Bertra,d
rdeanchurch
Posts: 750
Joined: Tue Dec 27, 2011 11:22 pm
Country: United States
Location: Carson City, Nv

Re: OpenTX 2.1 telemetry system preview

Post by rdeanchurch »

Is there anything significant we should read into Companion 2.0.99 being changed to 2.1 in nightly builds?

Companion does work much better, S1 and S2 are now present and conversion from 2.0.17 to 2.1 is quite good.
All telemetry values missing for SF is all I noticed.
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

2.1.0 is going to be released in a couple of days (assuming nobody finds a show-stopper in the meantime of course). Obviously as a ".0" release we recommend that only adventurous people who know what they're doing go with it.

All telemetry-related settings will be lost during the upgrade as I mentioned in this thread's first post, the new system is so different that it's impossible to convert settings automatically.
rdeanchurch
Posts: 750
Joined: Tue Dec 27, 2011 11:22 pm
Country: United States
Location: Carson City, Nv

Re: OpenTX 2.1 telemetry system preview

Post by rdeanchurch »

Yes, but I thought I would be able to select
SFx Ly Play Value Alt (or other telem. items.)
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
Endolf
Posts: 3
Joined: Mon Mar 24, 2014 8:52 pm
Country: -

Re: OpenTX 2.1 telemetry system preview

Post by Endolf »

Kilrah wrote:2.1.0 is going to be released in a couple of days (assuming nobody finds a show-stopper in the meantime of course). Obviously as a ".0" release we recommend that only adventurous people who know what they're doing go with it.

All telemetry-related settings will be lost during the upgrade as I mentioned in this thread's first post, the new system is so different that it's impossible to convert settings automatically.
Been looking forward to this for a while, but I'm guessing 2 days before a show weekend isn't a good time to try it :p.

I guess my Monday evening is planned then :)

Thank you to all those who've worked on opentx.

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

Re: Re : OpenTX 2.1 telemetry system preview

Post by Kilrah »

rdeanchurch wrote:Yes, but I thought I would be able to select
SFx Ly Play Value Alt (or other telem. items.)
Read the first post to understand how it works. There are no more any "default" telemetry items for you to choose, they are dynamically populated as you connect them to the receiver and power the radio/receiver up. Then you can choose them.

Envoyé de mon SM-G920F en utilisant Tapatalk
rdeanchurch
Posts: 750
Joined: Tue Dec 27, 2011 11:22 pm
Country: United States
Location: Carson City, Nv

Re: OpenTX 2.1 telemetry system preview

Post by rdeanchurch »

Am I understanding this correctly?

So in Companion there is no way to setup a model and define logical switches or Special functions that use telemetry values.
It must be done on the transmitter with a receiver and the telemetry sensors to be used.
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

You can just power up the transmitter once with the sensors you want connected so they get detected and stored, then read the memory into companion and continue your work there.

Starting from a blank model in companion is possible but indeed impractical, i.e you'd have to enter all IDs manually to "create" the sensors entries yourself.
Bamfax
Posts: 5
Joined: Fri Jun 19, 2015 11:37 pm
Country: Germany

Re: OpenTX 2.1 telemetry system preview

Post by Bamfax »

I am very happy with what I'm seeing in 2.0.99.

Just one question so far: How would I operate a bitfield like mavlink base mode / MAV_MODE_FLAG? The calculated fields do not seem to cover this. Should I send the bitfield over as raw and just convert it in a lua?
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 telemetry system preview

Post by Kilrah »

Yes that would sound like the best way to do it. Defining masks and meanings in the native telemetry system would be quite complicated.
Bamfax
Posts: 5
Joined: Fri Jun 19, 2015 11:37 pm
Country: Germany

Re: OpenTX 2.1 telemetry system preview

Post by Bamfax »

When logging the GPS field to SD, the field in the csv is named "GPS(>N)" and has a 5- or 6-digit int value. This is on 2.0.99 and 2.1. GPS Lat and Lon is displayed just fine elsewhere. The GPS data is coming down as AppID 0x800, as before on my 2.0.x OpenTX. I am a bit puzzled how now to get the lat/lon values in the logfile. Calculated fields does not seem to cover this. How do I get latitude and longitude logged properly? Should I send Lat/Lon down as extra float values? Sorry if I missed sth obious here.

Playing around with it for a while, I noticed the GPS sensor of the model does not aumatically come back when deleted. When now added manually, it is not possible to configure it as a "GPS type" sensor. The field can be created and a value is read from the telemetry system, but this value is then the 5- or 6-digit int value mentioned above. So this is probably the a variant of the unconverted GPS lat/lon values. Companion also does seem not offer a "GPS type" for manual configuration.

Testing some more:
- Clearing all Sensor IDs also brings the GPS sensor ID back and then it's also re-added automatically when deleted. Now it's on position number 7, before it was on pos 4. I probably had edited the sensor IDs too much and confused the automatic re-add feature.
- Nevertheless, also with the sensor being added automatically, still the same strange int value is being logged.

Post Reply

Return to “openTx”