Optional data in the oxs telemetry fields

[Kilrah]

Ahhh I think I now remember something about the possibility to send info into the Dist field when not used. That is valid for the hub protocol, it never made it into the SPORT code as far as I know.

TBH the entire telemetry code should be rewritten and improved one day with mapping possibilities added. It was originally written just for FrSky telemetry (hub only) with minimal footprint for the 9x's limited resources, and no plans for expandability or versatility.

[MikeB]

It gets quite tricky when undocumented values are used. The GPS Dist ID of 0x3C is a 'soft' value used internally on openTx, but not recognised on er9x/ersky9x.

The telemetry was indeed originally written for the FrSky Hub, but is now being used for the (now out of production) "Winged Shadow How High" and for the DSM telemetry on the 9XR-PRO. I do have some mapping internally, so I could handle the DIST ID.

I've added these "Scalers" to ersky9x and I'm adding them to er9x for the '128 and '2561 processors. They take up too much flash to be able to add them to 'standard' er9x for the '64 processor.

The idea is to provide a "bridge" from inputs (sticks, trainer, channels, telemetry, gvars, Scalers) to give values available for use elsewhere. Scalers may be used as mix sources and anywhere a telemetry value can be selected.

Scalers have the following fields:
An offset (currently -1024 to +1024)
A multiplier (currently 1 to 256)
A divisor (currently 1 to 256)
Optionally negate the result.
Specify how many decimal places are in the result (0, 1 or 2)
Choose when to apply the offset (+offset *multiplier / divisor OR *multiplier / divisor +offset)
Allocate a 'unit' to the result (e.g. volts, amps).
Provide a 4 character name.

The unit is available for display and voice purposes, and the name is displayed instead of "SC1" to give a meaningful display.

Mike.

[mstrens]

Ahhh I think I now remember something about the possibility to send info into the Dist field when not used. That is valid for the hub protocol, it never made it into the SPORT code as far as I know.

TBH the entire telemetry code should be rewritten and improved one day with mapping possibilities added. It was originally written just for FrSky telemetry (hub only) with minimal footprint for the 9x's limited resources, and no plans for expandability or versatility.

Kilrah,
You say "That is valid for the hub protocol, it never made it into the SPORT code as far as I know".
I presume that I must understand that it is not valid for a Taranis TX using internal XJT even if the Rx is a D serie using the hub protocol.
I presume that the XJT module converts the Hub protocol into the SPORT protocol and so, the Taranis code reads only data based on SPORT. This seems to be what I experienced because I do not get the data even when I use a D serie Rx.

Mike explains that he made some developments to provide more flexibility for telemetry fields (scaling,..) for some hardware. Is it already decided if this would be available in the same for Taranis or could it be that another solution would be implemented for Taranis?

Anyway, I presume, it will not be in release 2.0.

In the meantime, is it a solution to transmit and play a value (other than Altimeter) with a unit equal to "meter"?
The only one I see, is to change a wav file according to the unit of another field or to modify myself the code of the Taranis (what I would avoid because I try to stay as standard as possible).

Thanks in advance for reply.

[Kilrah]

I presume that the XJT module converts the Hub protocol into the SPORT protocol and so, the Taranis code reads only data based on SPORT.

Exact.

Is it already decided if this would be available in the same for Taranis or could it be that another solution would be implemented for Taranis?

On 2.0 it will be possible to take telemetry values as source for inputs, and apply the scaling options that go with it. The output of that is however intended to go back into the control domain, i.e. as a -100/+100% range with no unit. There are no plans to include units.
A lua script could however do anything you want, it's precisely there so that you can code complex functionality without needing to touch opentx code and deviate from standard.

In the meantime, is there a solution to transmit and play a value (other than Altimeter) with a unit equal to "meter"?

I don't see any others than what you mentioned.
It would however be easy to add the Dist "remote control" to the SPORT code, if you do have a go just submit it and it can be included in the main FW.

[mstrens]

A lua script could however do anything you want, it's precisely there so that you can code complex functionality without needing to touch opentx code and deviate from standard.

It would however be easy to add the Dist "remote control" to the SPORT code, if you do have a go just submit it and it can be included in the main FW.

Probably, the best solution would be to use the flexibility provided by lua.
It would then probably be possible to calculate the difference of altitude between X seconds on the TX side instead of on the sensor side making this information available for all vario ant not only for OXS.
Then, there is no need to add Dist to the SPORT code.

I would like to start learning Lua.
I had already a small look at the offcial lua web site.
Still I presume that there is need for some documentation in order to use lua on openTx.
I did not find such a documentation.
Is it available somewhere?
Does some script examples exist yet?
If not, will this documentation be available as soon as release 2.0 will be offcially released (in a few days ?)

Michel.

[Kilrah]

There will hopefully be a couple of samples and basic doc available, yes.

[bgbrik]

Hi again. Have now used opensensor loads, plus made some for club members - works great but today when in a thermal it suddenly flicked to negative height, is there a height limit caused my say the numbers rolling over or is it just a glitch in my Vario. See attached log. Thanks again for your support

[mstrens]

Hi again. Have now used opensensor loads, plus made some for club members - works great but today when in a thermal it suddenly flicked to negative height, is there a height limit caused my say the numbers rolling over or is it just a glitch in my Vario. See attached log. Thanks again for your support

That is really strange!
Normally there is no height limit foreseen in the program OXS (at least at a value that could be reached by a RC plane). Altitude is defined in centimeter as int32 an so it could keep a value of 2147483648 cm

I have no explanation.

Did you use the latest version of OXS (r204) openxsensor?

[Kilrah]

And what radio, what firmware and what version?

[bgbrik]

I guess I'm a bit out of date
vario is at R194 (I think, is there any why to determine the version number from any of the files?)
Taranis is X9D V1.1.02
I'll do a bit of updating (is there a change log somewhere of what changes in each version?)
Thanks

[mstrens]

I guess I'm a bit out of date
vario is at R194 (I think, is there any why to determine the version number from any of the files?)
Taranis is X9D V1.1.02
I'll do a bit of updating (is there a change log somewhere of what changes in each version?)
Thanks

For OXS, there has been quite many changes in the program but not all of them are documented in a log.
Best is to have a look at the explanation in the file xos_config.h.
Main changes are:
- support SPORT and Hub protocols
- selection of data to be transmitted (and optional scaling + offset)
- can read and transmit up to 6 voltages (+ current)
- can transmit RPM (if connected to a RPM sensor)
- better vario sensitivity
- vertical speed can be transmitted as analog signal too (on A1 or A2).

For Taranis, I think there is a log of changes here
https://github.com/opentx/opentx/releases