RSSI Telemety Source

[ghost]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

Whenever something changed in my telemetry the RSSI telemetry source gets lost and on the field, I cannot select it - I can only do this in the Companion and go to tlemetry and select "RSSI()". Not being able to select this in the TX ends in repeating "RSSI critical" voice alarms, which leads to switching it off - bad idea.

Describe the solution you'd like

Being able to use the same dropdown menu in the TX that I can use to select RSSI telemetry source in the telemetry menu.

Describe alternatives you've considered

Set it in the Companion - but on the field useless.
Switch Voice alarms off

Additional context

No response

[raphaelcoeffic]

Do you mean when you reset/re-discover the sensors? If yes, this is the way it is. We have plans to change that, but this current limitation has been there since ever.

[ghost]

Yes - Oh, okay, thanks. I thought it could be a good addition to future releases to have that selection option implemented if it is not too much effort.

[raphaelcoeffic]

Sure, I have that on my long-term TODO list, but it's going to be tough... All the sensors are addressed by IDs which are based on discovery order....

[raphaelcoeffic]

Or is this issue about selecting a specific sensor as the source for "RSSI Warnings"?

[ghost]

Yes, it is - since the RSSI() source seems to change from time to time while fidling with the order and names in Companion and re-discovery - although it always has the same ID. Perhaps we are talking about an issue rather than feature request. It is no big deal though, just wanted to mention it and see if there's a change on the road ahead. Once I have all things done in my telemetry, it does not get lost at all. Is there anything I can do?

[Eldenroot]

This is a valid report. There is same ticket. Missing feature from opentx ;)

#1260

[raphaelcoeffic]

the RSSI() source seems to change from time to time while fidling with the order and names in Companion and re-discovery - although it always has the same ID

What do you mean with "it changes" then? I'm really lost. It may be instructive to see the model file before and after the change.

[ghost]

I mean when I change anything in telemetry (not in the RSSI value), or with cabelling then the RSSI Source switches to NULL and that triggers events in the alarming. I had this now two times and only recognize this on the field. Does that make it clear?

[icebreaker-ch]

I had the same problem today on the field. The affected model was imported from OpenTX and the RSSI Source got lost somehow. Alarms all the time. I had to disable all telemetry alarms to get rid of it. I was not able to fix it on the field. Even deleting all sensors and a new discovery, or a re-Binding of the receiver didn't help.
At home, using the the EdgeTX Companion I found the option RSSI Source. In OpenTX, the RSSI Source can be changed in the transmitter without any problems. Why is this problem unsolved for such a long time?
Here the screenshots of EdgeTX and OpenTX for the Telemetry screens:

[mha1]

pfeerick edit: for some reason the link didn't work for me, this seems to be the discussion in question

According to this discussion the option that is
missing for color LCD radios was originally implemented for other requirements which in the end didn't materialize. It should have been deleted, now it is cause for misunderstanding. As it is used now setting rssi source to values other than default is only somewhat useful in a scenario with two concurrently operating FrSky modules with both providing RSSI info (ID F101). But setting rssi source to values other than default has side effects due to the well know index based telemetry access in OTX and ETX. Once rssi Source was set to non default either in OTX before conversion or in ETX Companion every change to the list of telemetry sensors, eg delete/discover sensors the index of RSSI might change leading to the permanent telemetry low/critical warnings (this is quite similar to the effect of changing indexes to widgets). With no means to re-adjust the telemetry source on color LDC radios the user is stuck at this point.

The question is if this setting is needed at all. Concurrently operating two FrSky module is a rare corner case. All other scenarios with one external or internal module operating don't need any rssi source settings as the default handles RSSI values associated with the module correctly. If a user really wants to concurrently operate two FrSky modules setting default will still take both modules RSSI values in account. The lower RSSI value of both modules will be used to generate low/critical warnings. This is the same behavior as having any two modules operating concurrently in ETX. So there is really no need to fiddle with rssi source. But why do some users change rssi source? Most likely because it's confusing and the behavior is not documented at all.

There is ways to solve this:

1. Workaround, open model.yml file and edit label rssiSource to read "rssiSource: none". This sets the default setting.
   Pros: easy workaround, no coding necessary
   Cons: it's a non-worthy hack, users shouldn't have to edit .yml files

2. The obvious solution is to implement the same UI as it already exits for b&w radios. This doesn't change the necessity to re-adjust rssi source after changes to the telemetry list.
   Pros: same behavior as OTX and ETX b&w radios
   Cons: UI implementation of a flawed setting which shouldn't be used in 99.9% of all use case anyway

3. Force rssi source to default at model load if not already set to default
   Pros: solves 99.9% the problem, consistent with other two module operation scenarios in ETX
   Cons: Users wanting to operate two FrSky modules concurrently are not able to choose a specific module as RSSI source
   I doubt the cons will ever be relevant.

3a: As an extension to 3. the rssi source settings option should also be deleted from b&w radios and companion for consistency reasons.
Pros: as in 3. plus consistency between all ETX gui types and ETX companion
Cons: as in 3.

My preference is 3a. I offer to implement 3. or 3a.

[icebreaker-ch]

Thank you very much for this comprehensive answer. I have a much better understanding of the problem now,
Obviously, I unintentionally changed the RSSI-Sources in some model-settings in the OpenTX configurations and transferred them to EdgeTX.
In the meantime, I checked and edited all my model yml-files on my EdgeTX radio to have the RSSI-Source set to "none" (default).
I think, the configuration options in EdgeTX Companion, the Radio and the yml-Files should be consistent. If yo delete the setting options as described in 3a, would you also delete it in the Companion and remove it from the yml-Files? So for now, I would prefer option 2 to be consistent or completely give up the possibility to choose the RSSI-Source and always use the default.

[mha1]

"...or completely give up the possibility to choose the RSSI-Source and always use the default."

This is what I had in mind with 3a.

[icebreaker-ch]

...In this case, Solution 3a is absolutely ok for me (and probably 99.9 % of the users)

[mha1]

@pfeerick I'd appreciate your feedback. And for the records: there is a workaround for users caught in the rssiSource trap when migrating from OTX to ETX on color radios. Edit modelxx.yml, find the rssiSource: entry and change it to rssiSource: none.

[pfeerick]

My take based on what I'm reading from that discussion from discord, and from the discussion here is that it is regretted that the option was ever added as it was done on the promise of features that never eventuated, and has simply led to confusion. So I would agree with 3a's take... reset it to the default (if I understand correctly, dump the setting entirely), and rip it out of the B&W and companion UIs.

If there is an edge case that makes sense, well, someone can open an issue so we know it might actually be a desirable option to have in a future version.

FYI, don't hurry on this one, don't really intend to include it in 2.9, so leave it a week or so before doing the PR if you still want to do it ;)

[mha1]

Aye, Aye, Captain