-
-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Companion: Hardware definition errors after converting between transmitters #5602
Comments
I've just done some more tests to determine the extent of the issue.
These conversions work fine in 2.9.4, so it seems to be a new issue. |
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.) |
Don't bump too hard or it might fall off my todo list 😁 |
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. |
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
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:
The text was updated successfully, but these errors were encountered: