Companion: Hardware definition errors after converting between transmitters

[RC-SOAR]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Companion

Current Behavior

When using a profile for the TX16S, the hardware assignments are incorrect after importing a setup for the X9D. [edit: also affects other source/target combos, see comment below)

See first screenshot. Also, 'S2' in mixer sources in the X9D are incorrectly translated to '6POS' for the TX16S (they should remain as S2).

Expected Behavior

The hardware assignments for the TX16S should be as shown in the second screenshot

Steps To Reproduce

1. Using Companion 2.10.4, create a setup using a profile for the X9D and save
2. Switch to a profile for the TX16S
3. Open the previously saved setup

Version

2.10.4

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

Windows

OS Version

Windows 10

Anything else?

Hardware definitions after conversion from X9D to TX16S

Expected definitions:

[RC-SOAR]

I've just done some more tests to determine the extent of the issue. It seems it also affects conversion from Zorro to TX16S. To reproduce,

1. Open the following minimalist setup for the Zorro into Companion, with a profile for the TX16S
2. Look at Radio settings > Hardware. Note how hardware assignments are incorrect, and some controls are named '000'. ETX_Controls_Zorro.etx.txt

These conversions work fine in 2.9.4, so it seems to be a new issue. I've not had an opportunity to test other combinations of source/dest.

[RC-SOAR]

Just a gentle bump!

Appreciate the hard work involved in tracking and dealing with problems, but I hope this issue can be escalated as it will prevent the use of many third party templates e.g. from RC Settings.

(For now, the workaround I've recommended for my own users is to do the conversion in Cpn 2.9.)

[elecpower]

Don't bump too hard or it might fall off my todo list 😁

[elecpower]

Explanation: In the yml files pots are referenced by their pot number eg P1 and not by their label eg S1. Thus why x9d+ P2:S2 Pot with Detent and P3:S3 None converts to tx16s P2:6POS Pot with Detent and P3:S2 None respectively. Also why the mix line references 6POS. The conversion only tests whether the destination radio cannot support the source radio hardware. If the source is 6POS and the destination is Pot with Detent the destination will be set to None and any references in for example mixer lines will also be set to None.

With ETX supporting over 40 radios across a growing list of manufacturers that can install hardware of their choosing and label each at their discretion attempting to convert based on the label is no guarantee either albeit it would work in this specific use case.

v2.9 did have some hard coded conversion mappings but these were removed in 2.10 as they did not align with the new flexible architecture.

I hate to say this, since it would likely fall on me, but due to the number of variables, the conversion process probably needs to move to a wizard approach such that the pilot can configure the radio to radio mappings pots, switches, etc before models and settings conversion.

[RC-SOAR]

Quick update: I've updated my templates to mitigate the effects of this and other conversion issues. All controls and switches - including FM switches etc - used by the template are now 'soft', and assigned in a dedicated block of Inputs. So any conversion issues are confined to these inputs, where they are easy to spot and correct.