Thread Tools
Sep 11, 2020, 12:29 AM
OpenTX core team
3djc's Avatar
Quote:
Originally Posted by chillly
OpenTX 2.3.9-otx on a Radiomaster TX16S with a Flysky x6b receiver (FlSky2A, PPM, IBUS)

RSSI is still showing as '--' on the main screen.

In the model settings->TELEMETRY->Sensors:
-I can see the 4 rssi-like sensor values, and they are all live/active [RQly, RSSI, RNse, RSNR].
-RSSI-Source, says '(default)' and I can't change it.

If I open Companion, I can change the 'default' value. I tried setting it to 'RQly (internal)' but it made no difference, still showing '--' on the main screen.

Am I missing a step or missing the point or missing the boat?
What are you talking about with your '--' ?? Any photo or something, because by default RSSI is only displayed in the radio signal bar, and that never displays '--'
Sign up now
to remove ads between posts
Sep 11, 2020, 12:54 AM
Registered User
mpjf01's Avatar
There is a thread for it and better to discuss there.

It is not a surprise to me to find that subscribers to an OpenTx thread would like to continue to be able to use it on new transmitters. Whether that's a general feeling across the entire potential customer base remains to be seen.
Sep 11, 2020, 01:18 PM
Registered User
Quote:
Originally Posted by 3djc
What are you talking about with your '--' ?? Any photo or something, because by default RSSI is only displayed in the radio signal bar, and that never displays '--'
Ah sorry, still trying to get my bearings on what's what. So it looks like what I'm referring is just from a 'widget'. A widget called "Show It All" (https://rc-soar.com/opentx/lua/showitall/index.htm). It has two entries "RSSI: --" and "RxBatt: --", and the '--' is the 'no value' placeholder ("TxBatt: 7.4" is above it). This is the default widget on the TX16s it seems. So I looked at the lua and it looks like it calls 'getValue' to get those two values from "RxBt" and "RSSI".

The sensors I actually want are "A3" (my vBat telemetry sensor) and "RQLy" (the nice rssi sensor value). Although a sensor 'RSSI' does exist, even though it's not what I want, but it doesn't show up in the widget, always staying '--', so not really sure how it works yet.

So I'm still trying to figure things out, but this helps. I'm not sure what kind of values 'getValue' can retrieve - can it refer to a sensor, or maybe I have to make an input/mixer/output or something. I'm super new to this and not really sure what I'm doing as you can see.
Sep 11, 2020, 01:57 PM
Registered User
Pittyplatsch's Avatar
sorry, but its working at the TX16S....see the Pic, RSSI from a S8R

Name: 20200911_205442.jpg
Views: 78
Size: 1.53 MB
Description:
Sep 11, 2020, 02:31 PM
Registered User
Quote:
Originally Posted by Pittyplatsch
sorry, but its working at the TX16S....see the Pic, RSSI from a S8R

Attachment 14039195
Yeah thanks, that's it. The S8R is a FrSky, right? I'd imagine it has to do with the telemetry from my FlySky being different. Once I figure out how scripts work I might be able to get it switched around.

Someone pointed out that i do get 5 bars, so the actual RSSI the radio is using seems to be working, it's just that widget.
Sep 12, 2020, 06:44 AM
Registered User
I life in the EU (Germany) and have the T12+. I now want to setup a model using the FrSky R-Xsr as a receiver. Which type of 'external TX module' should I set it up with in Companion?
Can I run it with the number of channels reduced to drop latency?

Thanks!
Sep 12, 2020, 10:41 AM
Registered User
Hobby4Life's Avatar

An almost desperate request to fix the following in Companion


When moving models back and forth from my x12 to x10 and visa versa..

Everytime I have to manually re configure the LS, RS, S1 and S2 pots.
I cant imagine that would be hard to fix for the devs..

A fix would really be apreciated

Name: Schermafdruk 2020-09-12 17.37.12.png
Views: 34
Size: 73.0 KB
Description:
Sep 12, 2020, 11:20 AM
Reality: What a concept!
Miami Mike's Avatar
I played with that on Companion and didn't see any problem with S1 or S2, but I did see that LS and RS from an X10 get converted to L1 and L2 for an X12, and if you then manually change those back to LS and RS they get altered in some undecipherable way when converting back from X12 to X10, instead of retaining their LS and RS settings.
Latest blog entry: I'll be glad when this is over.
Sep 12, 2020, 11:39 AM
I don't want to "Switch Now"
pmackenzie's Avatar
Quote:
Originally Posted by Hobby4Life
When moving models back and forth from my x12 to x10 and visa versa..

Everytime I have to manually re configure the LS, RS, S1 and S2 pots.
I cant imagine that would be hard to fix for the devs..

A fix would really be apreciated

Attachment 14041639
What would be nice would be some sort of user defined configuration file, so you could tell companion what substitutions to make when going from one radio type to another.
Sep 12, 2020, 12:21 PM
Reality: What a concept!
Miami Mike's Avatar
That would be a good idea. It could be a modified version of the Hardware tab on the Radio settings page of each otx file, where each specific control could be assigned to a unique general label shared across all radio models, such as "Pot #1", etc. But if that ever happened I'm sure it wouldn't be until Companion version 3.0 or later.

I think what we have here though, is a bug that needs to be corrected.
Latest blog entry: I'll be glad when this is over.
Sep 12, 2020, 12:35 PM
Registered User
Hobby4Life's Avatar
Quote:
Originally Posted by pmackenzie
What would be nice would be some sort of user defined configuration file, so you could tell companion what substitutions to make when going from one radio type to another.
+1 on that, That would be an even greater addition to OTX than only fix this.
Sep 14, 2020, 03:08 AM
Registered User
Quote:
Originally Posted by pmackenzie
What would be nice would be some sort of user defined configuration file, so you could tell companion what substitutions to make when going from one radio type to another.



I'd similar ideas some weeks ago, but i'm afraid a "complete" solution must have more functionality.

a)
in case you want something like a conversion table for switches & pods:
what, if you want to convert from X12 to xlite?
You can't define a one by one mapping because the xlite doesn't have enought switches / pods

i guess, the only way would be to define mappings for primary-function switches & pods.
The number of mappings must not exceed the number of pods / switches of the "minimum equipped" transmitter

You would have to implement a "shadow table" containing the "lost" inputs to be backwards compatible.
This table should deliver standard values (-1024...1024), so that an input, mixer, ls.... etc definition knows what value should be "delivered" even in case of missing hardware without compromising the programming/functionality of the model.

b)
i didn't work out the szenario how to handle this "workflow" in case the user wants to append another conversion for a third tx.
the easiest way would be to suppress this


c)
Conversion of switches, pods or inputs in general only is one part of the story
Another one is the definition / configuration of widgets for the horus series on the one side and telemetry / mixer scripts for the other transmitters on the other side.
So i would even like to see something which i would name "templates" :
definition files, transmitter type specific, which represent an overlay which you can load into an existing model definition and replaces or add the existing widget / telemetry / mixer script definition


All in all i would say it represents a huge amount of work.
Don't know if it's justified by the benefits.
But maybe it's worth to open a feature request.


At the moment my personal solution is:

- define as much as possible of standard functionality in global functions

- differentiate between
primary ( like pods for flap adjustment, safety and motor switches etc..)
and secondary (like switches for announcements, not very important mixer activation)
...inputs

>> put all secondary functionality in a (tx specific) mixer script, same naming for all TX's, so you don't have to deal with
"switch/input migration" between different kind of transmitters

- direct definition/use of switches and pods is only allowed in input lines
all other usage (in LS/SF/Mixer/FM config) will be derived directly or indirectly by using LS definitions from this input lines

so, in case of migration, you do only have to customize these few input lines.

regards
Last edited by strgaltdel; Sep 14, 2020 at 03:25 AM.
Sep 14, 2020, 03:34 AM
Registered User
probably this picture is more understandable

Name: TX conversion.png
Views: 104
Size: 25.8 KB
Description:
Sep 14, 2020, 12:32 PM
Reality: What a concept!
Miami Mike's Avatar
Quote:
Originally Posted by strgaltdel
probably this picture is more understandable
Not really, but it is very neat and colorful.
Latest blog entry: I'll be glad when this is over.
Sep 14, 2020, 12:39 PM
Registered User
Hobby4Life's Avatar

OTX v2.3.10


A dropdown list with the standard inputs, outputs, mixers, pots, switches etc etc .. is sufficient.
Slightly better than just "???" and then not be able to select anything anymore. thats "???"


Let's wait and see what the Dev's came up with :-)
Name: otx2310.png
Views: 63
Size: 7.7 KB
Description:
Last edited by Hobby4Life; Sep 15, 2020 at 01:35 AM.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion OpenTX Discussion Thread RC Grouper Radios 1619 Aug 09, 2020 01:20 PM
Discussion Pixhawk 2 (un)official discussion thread Rusty105 Multirotor Drone Electronics 211 Aug 15, 2019 05:54 PM
Discussion Official OpenTX version 2.2.3 Discussion Thread RC Grouper Radios 32 Jun 11, 2019 08:59 AM
Discussion Official Drone Registration Discussion Thread **Discussion Here** bansheerider Model Aircraft & Drone Advocacy 4320 Dec 07, 2017 01:53 AM
Yippee! Official Portal 2 Discussion Thread Miami Mike Chit Chat 9 May 02, 2011 08:19 AM