search

EdgeTX / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio
https://edgetx.org
GNU General Public License v2.0
1.59k stars 338 forks source link

Companion: Hardware definition errors after converting between transmitters #5602

Open RC-SOAR opened 2 weeks ago

RC-SOAR commented 2 weeks ago

Is there an existing issue for this problem?

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 2024-10-10_144346

Expected definitions: 2024-10-10_143500

RC-SOAR commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

elecpower commented 1 week ago

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.